df not truly reporting disk free space, why?
I am still trying to figure out a problem that I ran into this past week with gdm, nothing has shown up in the logs...anyway, I'm wondering about disk free space because I get a warning during boot about it.
Just the other day I deleted a directory with 160 MB of files in it. Since then, I expected there to be a decent amount free, but this is only partially reflected in the df run: Filesystem 1K-blocks Used Available Use% Mounted on /dev/hda1 3826552 3620832 11336 100% / Now, you can see that at least 160 was freed since the other day, because 3826552 - 3620832 = 205720 (which should be around 205 MB). For a ~4 GB partition, this is about 5 percent. However, df is reporting only 11 MB free, and that the partition has 100% in use. Rpmdrake 9.0 (mandrake 9.0 tool) reports 200 free though. Why is df falsely reporting the amount in use (100%), and the amount available (11336)? |
By default, the ext2 filesystem reserves 10% of the disk space on a
partition for root, and df knows to ignore that 10%. I don't know what Rpmdrake uses, but it looks like that tool doesn't respect the reserve. You want to reserve SOME space for root so you can save yourself if you have a problem, but IMHO 10% of a 40G drive is excessive. Check out the man page for tune2fs. |
Why does it reserve anything?! :)
I have 256 MB of RAM and nearly as large of swap partition...bad Linux! :) But, seriously, is there anyway I can prevent this? Surely it does not need 256 MB + ~256 MB + 10% of 4 GB. Feeling like I'm dealing with Windows and its swap file in the same partition... |
Moses told you how to fix it ;) You should read up on the man page for tune2fs, here's the chunk you'll wanna look for probably:
Quote:
|
As for your swap, if you don't want to use that much swap space, and believe it's just "worthless" then you can add that back into your "pool" of HD space. You'll need to resize your partition with something like Parted, but if you feel it's worth it, go for it.
Cool |
Actually, the reason it reserves it is because if some user
happened to have write permission on your root partition (say they could write to /tmp), and they filled your partition with junk (say music or pr0n), then root would still have a way to log in. If the root partition didn't have any space reserved for root, then root couldn't log in and fix the problem. This provides root with the ability to write important files when your users have "filled" the disk. Not a bad thing. You really should NOT reduce the reserved space to nothing, as you can get into trouble, and since you're already down to 160 M from 4G, I'd say you may need it. |
Actually, I'm using ext3. Is tune2fs safe to use on ext3 (it mentions ext3 in various spots in the man page)? Also, based on math, it doesn't seem like 10% is in reserve, maybe 5%. Is there a way to verify that? I do not see any options to show the current settings in the man page.
Thanks for all the info. |
Ext3 is ext2 with -j or journaling. You can (usually) use ext2 tools on ext3. So tune2fs is just fine for you.
As for listing: tune2fs -l <device> Here's what my /dev/hda5 reported: Code:
root@masterc:~# tune2fs -l /dev/hda5 Reserved block count: 83638 That shows the reserve. Cool |
I may have been in error about the 10% reserve as default, it was
some time ago, but could have been changed by the developers due to disk space becoming so plentiful. 1-3% (40-120 MB) should be just fine for recovery situations on your partition, and you could probably even get away with less, though I caution against it. |
All times are GMT -5. The time now is 04:36 AM. |