About 64-bit, that doesn't help us on our systems since Embedded Java only exists in 32-bit, right? 😕 So until that changes there's no point in being able to allocate more than the ~3700MBs right?
Crashplan support just confirmed that the linux version only runs on 32 bit.
Even with that restriction, the memory upgrade will still let me more than than double the 1536MB I was using before this issue started - which should keep me out of trouble for a while.
I don't know how well this will work, but I just moved /usr/local/crashplan to /c/.crashplan and then created a sym link to it:
ln -s /c/.crashplan /usr/local/crashplan
Crashplan seems to be working ok that way
I did the same thing for the /tmp dir, moved it to /c/.tmp/ and sym linked to it. That one I am not as confident I won't run into some strange problem sooner or later, but I'm trying it for a while.
This should prevent either /tmp nor /usr/local/crashplan from ever filling up the root partition again.
I don't know how well this will work, but I just moved /usr/local/crashplan to /c/.crashplan and then created a sym link to it:
ln -s /c/.crashplan /usr/local/crashplan
Crashplan seems to be working ok that way
I did the same thing for the /tmp dir, moved it to /c/.tmp/ and sym linked to it. That one I am not as confident I won't run into some strange problem sooner or later, but I'm trying it for a while.
This should prevent either /tmp nor /usr/local/crashplan from ever filling up the root partition again.
I moved the cache by changing my.service.xml (look for <cachePath>) but left the rest alone.
If /c/ couldn't be mounted you might have some issues running w/o /tmp. So I'm not confident in that one either.
Yea i put tmp back.. I will just live with that one. but having /usr/local/crashplan sym linked to somewhere under /c is fine by me and I won't have to worry at all about any of crashplan's caching, logs or other things. I think it works either way. Most of my other apps like plex and so forth all install under /c/. I think crashplan should have also.
There is supposedly a way to edit the run.conf file under /usr/local/crashplan/run/run.conf, and you can add a -D option to specify an alternate tmp file location for java to use while running crashplan. I tried it once, but didn't work and didn't have time to try further.
There is supposedly a way to edit the run.conf file under /usr/local/crashplan/run/run.conf, and you can add a -D option to specify an alternate tmp file location for java to use while running crashplan. I tried it once, but didn't work and didn't have time to try further.
Djava.io.tmpdir=/c/tmp
Something like that.
I tried that briefly when Crashplan ran out of memory a few months ago. At least I set up a crashtmp folder on C. But I must have undone it, because its not in run.conf. I wasn't seeing many files there anyway - and the real issue was crashplan restarting all the time, and failing to back up. Its resolved now (crashplan did take the support case even though I was running headless).
I see no risk to linking the main crashplan directory, and it also lets you look at the logs w/o needing ssh.
I suggest setting the retention for deleted files on CrashPlan central (instead of leaving it at the default "never"). Then try consolidating the archive to reduce the storage there. Deduplication memory requirements scale with the archive, not with the local store.
I also set deduplication to minimal and compression off. Not sure if that helps memory or not. You can't go above ~3.5 GB for crashplan, no matter how much memory you have in the NAS - it only runs on the 32 bit jvm.
I already put extra memory in my readynas just for crash plan and that eliminated any problems of running out of memory. The root partition filling up is a separate issue
crashplan doesn't directly, but java does, which is used to run crashplan. Java puts a tmp file of some kind into /tmp.
but as I said earlier there is supposedly a way to edit /usr/local/crashplan/run/run.conf and you can assign an alternate standard tmp file location to be used when crashplan is launched through java.
See this wki page about half way down under the section "waiting for backup"
But generally I think i agree, the big culprit here is the crashplan cache filling up the root partition very easily. Though when I was looking into this, my /tmp dir was full with 1.3GB worth of junk of some kind also, so I would like to understand more about how to keep my /tmp file empty or run some kind of cron job that will routinely clean it out, but I'm not sure how to do that safely.
I'm glad for you. mine was 1.3GB. I deleted everything in there already so I can't tell you what it was. But it was a lot of numbered stuff and could have been created by anythin
crashplan creates some kind of jna file when being launched with java, but its not clear to me now whether that was significant or something else was in my /tmp dir sucking space from root partition.
Its really unfortunate the readynas doesn't have some auto housekeeping job to keep /tmp cleared out because the root parition is really not that big. At the very least, on startup it would be a good idea to empty it.
especially for people who don't have SSH setup. Not only should it tell how much space is used by /tmp, but provide a button that can clear it on next reboot or something of this nature. Oh well...dreamin'
Great info there! I cant remember upgrading cralshplan on the Nas, but I definately think the OS partitin is full. I didnt manage to find how to reach through via tech support mode before, almost seemed like some magical stuff absolutely only available to Netgear tech support but the guide you posted should make it for me I think ☺ Just have to find the telnet password, there was a video on youtube about tech support mode and a password flashed by in the video, have to test if that works.
Thank you so much for your time, will update wirh progress and perhaps some more questions 😉
I had this problem a few months ago. After installing crash plan. Two culprits filled up the Os partition. One was /tmp dir was full of stuff. The other was due to a crash plan cache dir and since crash plan is located on /usr/local, that filled up the Os partition which is not very big. I solved my problem with ssh by emptying /tmp and by moving /usr/local/crashplan to /c/.crashplan and I put a sym link from /usr/local/crashplan to there. Problem gone, crashplan works great on my ultra ever since. At some point I also upgraded ram on ultra by replacing the simm with a bigger one, as crashplan is also a memory hog.
@Dewdman42 wrote: I had this problem a few months ago. After installing crash plan. Two culprits filled up the Os partition. One was /tmp dir was full of stuff. The other was due to a crash plan cache dir and since crash plan is located on /usr/local, that filled up the Os partition which is not very big. I solved my problem with ssh by emptying /tmp and by moving /usr/local/crashplan to /c/.crashplan and I put a sym link from /usr/local/crashplan to there. Problem gone, crashplan works great on my ultra ever since. At some point I also upgraded ram on ultra by replacing the simm with a bigger one, as crashplan is also a memory hog.
FWIW this particular failure could eventually fill the data partition also - crashplan keeps redownloading the failed update over and over.
Everyone should move the cache (which can be done with a config change, and doesn't need a symlink). Mine is ~1.8 GB - IMO too much for the OS partition..
Moving everything to the c (or \data in the case of OS6) works as long as the RAID volume is healthy. I chose not to do that myself.
