Does changing swap file size in that config file actually work? I’ve seen people in other threads saying the DroboFS doesn’t seem to touch its swapfile for apps at all (saying that maybe it’s reserved for NAS duties somehow…). If it’s confirmed to work, I’ll make this change tomorrow…
…as I’m currently having issues using the DroboFS as a crashplan destination (and the above may or may not help, but if anyone has experienced similar issues, let me know):
It seems to always want to “compact versions (deep)” everytime crashplan starts (takes about an hour to compact the inbound computer’s backup in question), then it just stops at 100% (stating < 1 minute remaining) as if it’s not finished, which is confirmed as the inbound computer’s progress notifier just says “maintaining backup files”. Sometimes if I leave it on for a few days, the inbound computer gets a chance to backup for an hour or two, then crashplan on the Drobo decides to go back into its maintenance cycle. There’s still around 80Gb to go, so two hours every couple of days isn’t exactly going to do it quickly…
Of note is I have maintenance times set to long values (i.e. only every 14 days for normal and 28 days for deep), to try to make sure it does this infrequently - although I suspect it never realises it’s finished, hence it just tries again and again.
Aside from the swap size (if it actually helps), anyone else have any ideas? I’ve not found any info on the crashplan site or forums, and I’m guessing they won’t be much help anyway as they probably wouldn’t support it on such low specced devices (and if that’s the reason for this issue, I doubt many people over at the forums will have seen the same problem).
Oh, and in any case - big thanks to Ricardo for all his work with DroboPorts
The Drobo itself is backing up to Crashplan central just fine :-)[hr]
^ for reference, although it seems to be using a lot of memory, it’s not using much CPU at the point it hangs:
485 1 root S N 654m353.8 0 6.2 /mnt/DroboFS/Shares/DroboApps/java7/bin/java -Dfile.encoding=UTF-8 -Dapp=CrashPlanService -DappBaseName=CrashPlan -Xms20m -Xmx512m -Djava.net.preferIPv4Stack=true -Dsun.net.inetadd
total used free shared buffers
Mem: 189028 186620 2408 0 4592
Swap: 262136 0 262136
Total: 451164 186620 264544
Hmm, actually, I’m now wondering if there’s a deadlock-type condition going on here (crashplan waiting for another process that needs more memory that it can’t get because crashplan has used it all).
Well, if anyone cares to comment or make suggestions, let me know