Freeing up space on the OS partition (RAIDar 4.2.28, ReadyNAS Ultra 2)

[chaug]

From time to time (very rarely) my OS partition fills up to 100% causing all kinds of issues. Usually, the reason are some log-files that just became too big or too many. Once I had to move the CrashPlan cache to another partition. Once I cleared out stuff, the partiction usage was down to 30-40 percent again. But this time, I seem to be stuck at just under 80% and I can't figure out where all that junk might be . Or alternatively, why I suddenly need so much more space. 

The problem is, I'm not a linux expert and I don't know exactly which directories are actually located on the OS partition. So far I have checked the following:

/var

/usr

/etc

/tmp

And I cleared all logs and obviously unnecessary files, but that doesn't seem to be enough.

What might I be missing?

Christoph

So every time I find myself trying to figure out, which directories are actually on the OS partition so that I can target these (obviously, I'm not a linux/debian expert). 

[chaug · Accepted solution]

Okay, so thanks to mdgm's assistance, it turns out that the files that were clogging up the OS partition were in /mnt/NAS2 where I had mounted another volume and to which Crashplan was writing its backup archives. The problem was that for mysterious reasons that volume disappeared from /etc/fstab and was no longer mounted. And as a result, Crashplan was writing to /mnt/NAS2 as a directory in the OS partition. I would never have thought that it is possible to write to /mnt/NAS2 when the volume is not mounted  but apparently it is just an ordinary directory in those conditions. 

In order to prevent that in the future, I am now mounting that external volume under the data partition instead of the OS partition,

[StephenB]

I'd look in frontview and its subfolders next.

If you enter 

cd //

ls -al

Then any folder that has a -> /c/... is a link to the data volume and can be ignored.  You can also ignore c

[mdgm-ntgr]

You can use e.g. the du command to see how much is used by a directory.

For example I may use commands such as

# du -csh /var

# du -csh /var/log/*

Most things under /var are on the root partition but if you have ftp enabled then the mounts under /var/ftp will be pointing to the data volume.

The locations you mentioned are the main ones to look at. Usually, but not always the culprit would be under one of those.

[chaug]

Aah, I should have guessed that everything that is nt /c/ would be the OS partition. Now I know. Thanks StephenB.

frontview is only 14 MB. 

Will keep looking, but maybe that's just how much space the OS needs. Though I do seem to remember that it was much less last time I checked.

mdgm, yes, I have used du quite a bit, but du -h --max-depth=1

 just gives me 

16K ./lost+found
20K ./home
1.9T ./mnt
524K ./dev
0 ./sys

 And then it becomes unresponsive and doesn't complete properly.

[mdgm-ntgr]

The root usage shouldn't really get above 30 to 40%. The 4GB of space is way more than enough.

Keep looking.

Don't look at /dev  /proc  /sys or /run

The problem won't be in one of those directories. It will be in one of the others.

[mdgm-ntgr]

You have a mount for another NAS, showing a data volume that is 100% full. You shouldn't fill a data volume that full.

/usr/local/crashplan is using up 474MB. You may wish to move this to the data volume and create a symlink.

[chaug]

This is driving me insane. Since you looked at the files, the OS partition has filled up to 100% again and I managed to get it down to 96% by deleting som stuff here and there, but none of the deleted files were recently added so they can't have been the cause of the partition filling up.

The stuff in /usr/local/crashplan is also not new. I have had crashplan running like this for years. - Yes, crashplan tends to eat some space over time due to its autoupdate funtion so I sometimes clean out the leftover files from the update processes, but that has been done already so there is no more stuff to delete. Even if I moved the whole thing to another partition as you suggest, I would only gain another 10 percent or so.

It's a mystery to me where this pile of data is hiding. Here are the sizes of all directories over 10 MB (excluding /dev  /proc  /sys and /run, which I did not look at according to the instructions above): 

/usr = 779MB

/var = 163 MB

/etc = 190 MB (most of this space is used by /etc/frontview/addon/bin/EJRE/ejdkl.8.0_51)

/frontview = 14 MB

/opt = 28MB

/lib = 74 MB

I took a closer look at /usr:

/usr/lib = 247 MB

/usr/local = 271 MB

/usr/share = 137 MB

But even if I deleted all files in these branches, I would still not be at 30 or 40 percent.

All the branch sizes come from du -h

What else could I do?

[chaug · Accepted solution]

Okay, so thanks to mdgm's assistance, it turns out that the files that were clogging up the OS partition were in /mnt/NAS2 where I had mounted another volume and to which Crashplan was writing its backup archives. The problem was that for mysterious reasons that volume disappeared from /etc/fstab and was no longer mounted. And as a result, Crashplan was writing to /mnt/NAS2 as a directory in the OS partition. I would never have thought that it is possible to write to /mnt/NAS2 when the volume is not mounted  but apparently it is just an ordinary directory in those conditions. 

In order to prevent that in the future, I am now mounting that external volume under the data partition instead of the OS partition,

[JennC]

Hello chaug,

We’d greatly appreciate hearing your feedback letting us know if the information we provided has helped resolve your issue or if you need further assistance. 

If your issue is now resolved, we encourage you to mark the appropriate reply as the “Accept as Solution” so others can be confident in benefiting from the solution. 
 
The Netgear community looks forward to hearing from you and being a helpful resource in the future!
 
Regards,