So I'd say I have a moderate knowledge of linux and there's not much I can't figure out with some time on google. Really don't know where to look for this, though. This started to occur after my box took a small brownout hit and I've already run fsck with zero errors so I'm not sure what to check next.
thekid:/var/log/fsck# df -h Filesystem Size Used Avail Use% Mounted on /dev/hda1 6.5G 6.1G 0 100% /
Only / is affected, all my other mounts still behave normally. Any help is welcome, as right now I can't run a whole lot due to zero space in /var and /tmp :(
23 Jun, 2008, David Haley wrote in the 4th comment:
Votes: 0
It could be that you're using a filesystem that has enough overhead that storing 6.1G of files requires 0.4G of overhead, accounting for the missing 400MB.
It could be that you're using a filesystem that has enough overhead that storing 6.1G of files requires 0.4G of overhead, accounting for the missing 400MB
Thanks! Not quite what my problem ended up being, but it got me in the right direction for googling when I was otherwise lost. 5% of disk space is by default reserved for root so you can't mistakenly fill your whole drive and cause problems, so that's where my 400mb went. Tested with tune2fs -m 0 /dev/hda1 and it reported space normally, so I just moved it back now that I know whats going on :)
David's comment was my first thought too but I hadn't said anything because I was thinking that was dealt with at the partition level by fdisk and such and didn't get taken into account by the df command. It's good to know what the case turned out to be as well, now I'll know for future reference for myself too.
Kiasyn's command produced interesting results for me on my desktop.. guess I've got some electronic spring cleaning to do.. :lol:
Only / is affected, all my other mounts still behave normally. Any help is welcome, as right now I can't run a whole lot due to zero space in /var and /tmp :(