1

I am running Crunchbang, a Debian variant with OpenBox WM. I have deleted a large number of files via browsing in thunar file manager and pressing del key. They disappear from view. I then go to ~/.local/share/Trash/files/ and delete them there too. The filesystem still doesn't report the freed space though.

df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sdb5              61G   57G  371M 100% /
2
  • 1
    it seems that your /root is really heavy. isn't it the problem? Jul 7, 2013 at 16:51
  • no - I deleted 7 Gigs from my home and it shows as disappeared according to /home stat above but free space still isn't reporting it as released (only 378Meg free) so this is my question.
    – citronic
    Jul 7, 2013 at 16:58

4 Answers 4

1

I once had a similar issue trying to track down what was taking up space on my root partition but not being reported by Baobab, a disk usage analyzer. In the end I found the files in my the trash folder of the root user, /root/.local/share/Trash. The reason Baobab and other utilities wouldn't show these files is because I was running them as a non-root user and they didn't have the necessary permissions to read /root folder. A quick su allowed me to enter the necessary directory and rm * the files away.

1
  • You're right. Why are the files being sent to root Trash and not my logged in trash? I definitely deleted them as a non-privileged user.
    – citronic
    Jul 8, 2013 at 7:03
1

One possible reason, is that ext2/3/4 and other "Unix file-systems" reserves a certain amount of space for root - I believe the default is 5%. That way, the root-user and processes run by root still has room to maneuver, even when the system reports that the file-system is full and refuses to let normal (non-root) users write anything.

This is great for some file-systems - like / (root), /var and if you have everything on one filesystem... it may be less ideal for /home and /usr filesystems, which probably should have less reserved space (perhaps just 1% or none).

In any case, when commands like df reports "0 bytes free" and "100% used", that doesn't include these 5% reserved for root! So while normal users are blocked, the root-user and processes running as root, may continue to write - seemingly filling the partition above 100%.

This means that the disk is not as full as you may think... But it also means that deleting files may not have as much impact as you thought it would; simply because some of the files you've deleted are files written above the 100% full limit, and thus doesn't show-up with df afterwards.

So if your disk is 100GB effective space, df will show it as just 95GB. However, after you've filled these 95GB and df shows the disk as full and the system refuses normal users to write to it, root will still be allowed to write another 5GB. If you then clean-up and delete 10GB of files, df will ignore the 5GB that was reserved for root and only show 5GB (not 10GB) as being freed-up. So I assume that you've used some of the space reserved for root, so when you deleted 7GB, only 378MB was below the reserved limit.

You can use tune2fs to change how much space you want to reserve for root - it should be some though (put perhaps not as much as 5%). There are also options for mke2fs that allows you to set how much space to reserve in percent or bytes when first creating the filesystem (formatting the partition). 5% made more sense when the disks were smaller - with 500GB+ disks, 5% becomes a bit much.

1
  • Thanks for that. I've noticed further strange behaviour... to begin with it reported back as ~400meg free. then an hour or so later 500. Now it's over 600. Why is the free space being released gradually?
    – citronic
    Jul 7, 2013 at 20:35
0

you can run this command to see how much each directory take the space of your disk:

du -hc --max-depth=1

when you found the directory with weird size get into it, run this command and remove files that you do not need any more.

if found nothing interesting there run the command in / directory. post the output if needed.

You can use Bleachbit too, give it a try: Bleachbit

2
  • the dirs have been deleted so this command doesn't show anything ontoward.
    – citronic
    Jul 7, 2013 at 16:37
  • see edit please
    – citronic
    Jul 7, 2013 at 16:48
0

Well, it would be worth a try, so I thought I'd post it here:

# find /root/.local/share -name '*.trashinfo'

These are nasty critters. Personally, I encountered them when I started okteta (hex editor) in console mode and kio_trash flooded my terminal with lots of useless "info" about cannot stat: ... messages, i. e. not being able to find files (which I had deleted LONG ago). The "solution" was that it had persistently looked in $HOME/.local/share/Trash/info for .trashinfo files. When I did a full cleanup in that info directory, peace reigned on my linux box again. :) Whoever invented this nonsense, should be taser'ed.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .