Yesterday I did not manage to login from the graphical surface. A small window popped up saying: "no space for X-server". I logged in recovery mode and the "df" command showed the system partition was full. I've deleted log files, but no success. Actually, "df" showed a considerable difference (several hundred Megabytes) between the number of available and used blocks, but still 0% free.

Thus, after searching Internet I found the command "sudo tune2fs -m0 /dev/sda6". This helped. After rebooting the PC was working as usual. However, I tested again with "df" and it showed 73% in use. This means the system reserve space was 27% before! But who has set up this unusual high value? Not me, because I saw the "tune2fs" command first time now. Is there any other program, which arbitrary changes the system reserve space? Or perhaps this was already set up when Linux was installed, several years ago? Why an installation reserves 27% of disk space (the system partition is 40GB)?

Another question: I also tried to start up the Linux box from a live Linux pendrive. This happened flawlessly, but after the login I had no access to the old Linux' system partition. It has not succeded to mount that, although all other harddisk partitions were correctly mounted and accessible. What could be the reason for this? Perhaps, because the partition directory ("/") is the same as the live Linux system directory? What to do in this case? This means one can not delete unused files from the system using a live Linux disk?

Thanks,

John Brass

When you boot from a live image, you can mount the partition at a different place in your filesystem, such as under /mnt. Just be sure you are looking at the correct partition, since drive letters can change at each boot.

You might have deleted log files that were still opened by the system which does not show as free until you reboot or stop /restart the process that uses the log file. You also might not see any free space % until you go below 95% used i.e. below reserved space of 5%.

What command are you using to mount the problematic root filesystem? It's been too long since I've booted off a USB drive or CD as a rescue device so I'm unsure why the hard disk root filesystem didn't get mounted but I strongly suspect that it's because you already had a root filesystem (on the USB drive) mounted and the system basically responded "Uh... no."

I would likely try something like:
You need to determine "<disk><part#> using "lsblk -f" since the drive letters will be different when you've booted from the USB drive. Then you can "cd" to "/mnt" and perform whatever cleanup you need to do. What's filling up the disk? Hard to say without knowing what activity is taking place on the system.

You may have already been doing this but using "du" is where I'd begin:
The directory trees with the most disk use will be at the bottom of the list. "cd" into the ones using the most space and keep issuing "du -sk *" commands. Eventually you should find a directory using a lot of space and it'll jog your memory about some activity that is running, a cron job that's generating a ton of output, some process that's supposed to be cleaning up after itself but actually isn't, whatever.

Slight aside: another handy thing Linux allows is to add a label to filesystems. That makes using many tools like "lsblk" and even "mount" a bit easier to use. Example to label "/" as "rootfs", simply:
Future "lsblk -f" commands will show that "rootfs" label in the LABEL column. You can also use the labels in your /etc/fstab entries. See the appropriate manpages for the details.

HTH...

Thanks for the answers. Actually I did not try to mount the partitions as the live Linux performed an automount - just not the system partition. I simply did not try with the /dev name.

Well, now I'm happy with the working Linux box, I do not try it until the next failure. :-))

By default Ext3/ext4 reserve 5% of the total space for root user. This allows the system/root process to continue working even after you get to 0% free space as a user. If you set this value to 0 (for your root partition) then when you run out of space again the entire system will crash when processes can't write to the disk. It is recommended that you leave a little bit of space as reserved to avoid this scenario. If 5% is too high then you can reduce it to a lower percentage.

I don't see the downside of removing the reserved space for disks/partitions other than the root partition and have been doing that on all my systems for a few years now without issues.

Also, ncdu is extremely useful in finding files that are using up your storage space.

Seems odd to have a relative percentage rather than an absolute value, and 5% seems like it comes from before GB/TB disks - even 1% of a modern disk would be excessive for the purpose of allowing root user to recover a system.

However, a quick search suggests that, if performance matters, it may be worth increasing that percentage of reserved space to prevent performance degradation that can occur as disks fill up.

Yeah, this is from before the days of multi-gigabyte/terabyte disks. Which is why I always suggest (amongst other reasons) that you should have the root partition on a separate partition (15-30GB depending on how much software you anticipate installing) and keep the data partition separate. That way you can remove the reserved blocks on the data partition and leave them on the root partition.

This percentage thing is quite annoying in all things. At work we had a server with a multi-terabyte disk and the system was set to alert when the free space dropped below 30%. (Standard monitoring rule) so the alert would be raised even when we had more than 300 GB free... Ended up changing the rule to alert after the available space was less than a fixed size.