Re: Is may be a bug...

[James Youngman]

On Fri, Mar 04, 2005 at 11:26:52AM +0100, S?bastien Jallot wrote:
> Hi,
> Here is what I get about my /var partition :
> 
> tom:/var# du -sh /var
> 40M     /var

> tom:/var# df -h /var
> Sys. de fich.         Tail. Occ. Disp. %Occ. Mont? sur
> /dev/sda6             2,8G  2,6G   30M  99% /var
> 
> Debian 3.1


The two tools measure different things, and do so in different ways.
One would not necessarily expect these two figures to be the same.
"du" adds the total number of blocks occupied by the various files you
specify.  This includes indirect blocks etc.  The third column of the
"df" output is gathered from filesystem summary information.  This
takes into account some things that "du" cannot, for example files
that have been deleted but are atill open, journal inodes, and so
forth.  

On a system rather like yours I get a result from "du" and "df" which
is not quite the same: -

orbital:~# LC_ALL=fr_FR du -hxcs /var
732M    /var
732M    total
orbital:~# LC_ALL=fr_FR df -hP /var
Sys. de fich.         Tail. Occ. Disp. %Occ. Mont        sur
/dev/mapper/mirror-var 1008M  764M  194M  80% /var
orbital:~# cat /etc/debian_version
3.1

Note here I used the "-x" option to du to prevent it crossing
filesystem boundaries (to get a result as similar as possible to the
result of df).  You might want to try using "-x" to stop "du"
traversing into other filesystems.

However, I would say that it is unusual to see such a large
difference.  There are only two obvious ways I can think of to get
this effect.  The first is that perhaps you have a filesystem mounted
on top of a subdirectory of /var which does not contain very much,
while the mount point within /var itself contains a lot of data which
is now "hidden" by the new mouned filsyetem.  In other words If you
have 1Gb of data in /var/foo and then mount an emptp filesystem on
/var/foo, then "df /var" will show that space as used even though "du"
will never be able to find the files taht have used the space.  The
second way in which this might have happened is that you have one or
more large files which used to exist on /var but have now been
unlinked.  The files still exist because they are open (a process is
using them) but since the files no longer have names, "du" cannot see
them.

To illustrate the above, I can articificially reproduce a similar
effect by mounting a filesystem on /var/lib (on my system that's where
most of the data in /var is, because I have a separate
/var/cache/apt): -

orbital:~# ( LC_ALL=fr_FR; export LC_ALL; set -x; du -hxs /var; df -Ph /var; 
mount /dev/hdg3 -t ext3 /var/lib; du -hxs /var; df -Ph /var; umount /dev/hdg3 )
## Results before (as above)
+ du -hxs /var
732M    /var
+ df -Ph /var
Sys. de fich.         Tail. Occ. Disp. %Occ. Mont        sur
/dev/mapper/mirror-var 1008M  764M  194M  80% /var
+ mount /dev/hdg3 -t ext3 /var/lib

## Results after mounting a new filesystem to "hide" the contents of /var/lib
+ du -hxs /var
209M    /var
+ df -Ph /var
Sys. de fich.         Tail. Occ. Disp. %Occ. Mont        sur
/dev/mapper/mirror-var 1008M  764M  194M  80% /var
+ umount /dev/hdg3

(The "##" comments in the above were added manually)

You will see from the above that the summary information for use of
space on /dev/mapper/mirror-var still shows 764MiB as being used, even
though those files are no longer visible to "du".

So without knowing more about your system I can't tell you exactly why
what you are seeing is so very different between "du" and "df" -
beyond the usuall small differences as in my first example, but there
are a number of reasons why this could be the case.

I hope this has helped.  

James.