df and du differences
 

Hi,
I'm just wondering how to make the df utility report the correct free space on a partition.
I recently freed up some space on one of my partitions by deleting a load of old mail messages.
The du utility reports only 172MB used out of 494MB whereas the df utility reports 425MB used out of 494MB!
I rely on the df -h as a quick check on disk space so it looks a little alarming at present, esp as a load of log files are stored on this partition.
Does linux have fragmentation issues similar to windows & if so is there a way I can 'reclaim' some of this lost space?
Do I have to worry about this or shall I just assume the du utility is reporting the correct disk usage and ignore the df utility from now on?
thanks,

are you sure the files aren't in a trash can somewhere?

yep sounds like the dreaded trash can.. I hate that thing.
If you deleted the files using gui, odds are they are in the trash and are still using space on your HD.

yeah i guess du and df are reporting things differently. might not be that though... worth checking out.....

have a look in /root

can you show the outputs??

Depending on the filesystem, there may be some room reserved exclusively for the root user.
Also, on a filesystem like reiserfs, there will be a journal which won't be counted by "du". Plus add things like the directories. You may try running "sync; sync" and recheck the results.

On my Dell laptop, I just installed SuSE linux. I have a partition mounted on /usr/local. There presently are not any files in it but 33M are being used according to "df".

If the --apparent-size option is used with the "du" command, then a text file that only contains the characters 'medmedia\n' will count as 9 bytes long, but may actually take up 1024 bytes. ( Some file systems will store such a file in the directory structure itself to save space. )

Also, if there are sparse files being used, the actual space being taken up on a drive will differ greatly from the reported file size normally reported by "du".

If the drive is failing, you may have a large number of blocks marked bad.

Are you sure you were not in a subdirectory on the partition. The "du" command will report the sizes of files below the directory you current are in, but not count files above it.

One other possibility is that you have been hacked, and a root kit is hiding the existance of files from the "du" command. If /var and /tmp are on their own partitions, are they mounted with the "noexec" option?

Trashcan?? I don't have a GUI!

Here is the result of the output:

# du -ch /var | grep total
176M total

# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda7 494M 404M 65M 87% /var

I have only shown the relevant info above, you can see that df reports 404M used while
du reports only 176M used. I have manually checked this as well & du appears to be reporting
a correct figure.

The trash bin is located in your home directory and not on other partitions.
Also, the contents of the Trashbin are counted by "du".

Run "du ~/" | grep "Trash" to see for yourself.
The files in ".local/share/Trash" will show up.

The /var partition will contain a large number of empty directories, which will occupy space on the hard drive, but not being files will not add anything to the results of "du". However, this would probably only account for a 1 MB discrepancy.

My /var directory has about 1300 directories and around 250 files under 100 bytes in length. How does yours compare?

Just tried that & came up with no occurrences of 'Trash' and 'trash' only around 4 occurrences with 48k max.

:scratch:

Try running a consistency check on your /var partition. Also scan for root kits. Most of things that I mentioned that can cause a discrepancy between du and df will cause du to be higher. Except for the --apparent-sizes option. Check if du is aliased. Also run du with the full pathname. Chehave the oposck the consistency of these commands. I.E. "sudo rpm -V coreutils"

What filesystem are you using. An ext filesystem may have too many blocks reserved. The reiserfs and ext3 filesystem might have a journal that is way to large. Could someone or something have run reiserfsck --badblocks with a badblocks file that marked most of your blocks as bad?

Given the huge difference between the two values, I keep coming up wondering about hacker/rootkit damage or a hardware problem with the drive. The /var parition is world writable, so that is where mischief usually starts.

OK, I'll try doing that, many thanks for your help

root's deleted items are in /root and the trash can may not actually be called "trash".

satinet, he is having a problem with the /var directory. It is on it's own partition. Root's trash bin if it exists will be in the /root directory on the (/) root partition. A user's will be in their home directory on the /home directory which often is in its own partition. The /var partition doesn't contain a trash bin. And the du command would still count any files in it. The trash bin is used by the KDE or Gnome window managers. The du and df commands are core utilities and will notice any files including the trash bin in the hidden .kde directory.

Putting an item in the trashbin will place it in ~/.local/share/trash/files/ and a .info file will be in ~/.local/share/trash/info/
If you log into KDE or Gnome as the root user (which would be a good thing), then these may not even exist.