Re: Is may be a bug...

[Bob Proulx]

James Youngman wrote:
> Sébastien Jallot wrote:
> > 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
>
> [...nice explaination...]
>
> 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.

I think you have the problem.  The -x will be important in many
cases.  And of course your observation about the two commands
measuring different things in different ways is right on.

> 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.

On Debian systems with the 'autofs' package installed the package
default /etc/auto.master looks like this:

  #/var/autofs/misc       /etc/auto.misc

Note that it is commented out by default.
And /etc/auto.misc contains the following examples:

  kernel          -ro                    ftp.kernel.org:/pub/linux
  boot            -fstype=ext2                            :/dev/hda1
  removable       -fstype=ext2,sync,nodev,nosuid          :/dev/hdd
  cd              -fstype=iso9660,ro,sync,nodev,nosuid    :/dev/hdc
  floppy          -fstype=auto,sync,nodev,nosuid          :/dev/fd0

If someone were to activate that example as written they could easily
have another filesystem mounted there or perhaps even the kernel.org
kernel!  (Personally I never use that particular configuration.)

> 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.

A very common case when log files are written by long running daemons
to /var/log/somewhere and the user decides to delete the file thinking
that would free up the disk space.  But as you describe the filesystem
is a garbage collected system and the disk blocks are only freed when
they are no longer referenced.  The user is often surprised to find
that the disk space was not freed up.  In this case it is better to
truncate the file first, say with ": > file", instead of deleting the
file.

Bob