On Mon, Sep 16, 2002 at 10:57:52AM +0100, Erik Erskine wrote:
> I've got a problem with disk space being reported differently by du and df.
>
> df is showing the root filesystem to be 98% full. It was reporting 100%
> a few days ago but everything remained running.
>
> Filesystem 1k-blocks Used Available Use% Mounted on
> /dev/md0 365492 336502 10120 98% /
>
> However, du -x reports a different figure, 82Mb, which is what I would
> expect:
>
> 12 /lost+found
> 2420 /bin
> 10605 /boot
> 82 /dev
> 2455 /etc
> 57628 /lib
> 1 /opt
> 8040 /root
> 2355 /sbin
> 1 /tmp
> 4 /mnt
> 83604 /
Possible explanations:
- Deleted files that are still open; as the files are marked as
deleted, they won't show up in directory listings (and hence: du
wouldn't find them), but they still occupy disk space. E.g. if you
'rm' a file that is still being written to. Partial solution:
truncate the file before deleting it.
- Things hiding under mount-points
>
> The machine is running woody, kernel 2.4.18. The root partition is
> ext2. It has two identical disks, all partitions are raid 1 across the
> two disks. It boots off a custom made CD.
>
> I've got /usr, /home and /var mounted on different partitions. One
> thought I had was I'm mounting these directories over the top of
> something else, ie that there are files in the /home directory on root
> before I mount, and these are now inaccessible. Is there any way to
> find this out without unmounting? The machine is a production server
> and also co-hosted so I'd like to avoid having to take it down.
debugfs should be able to help with diagnostics here (read-only mode by
default). It can list deleted entries in a directory.
If you *do* find any big files hiding under the mountpoints, you
probably have umount the mountpoint to remove the files via e.g. rm. I
wouldn't trust debugfs in read-write mode on a currently mounted
filesystem....
<span memory="vague, unsure">
ISTR that there is a "feature" of the kernel-based NFS server; exporting
e.g. / would only export that mountpoint. If e.g. /tmp was a separate
filesystem, nfs clients would still see /tmp on the parent file system
(hopefully empty, but...).
But it's quite a while ago I last used the kernel-based NFS server...
The user-space nfs server should not exhibit this. Or the kernel-based
nfs server may now be fixed in that regard. YMMV
If you are running the kernel-based nfs server, then this might be handy
for peeking under mountpoints...
</span>
Please take any advice with adequate amounts of salt.
--
Karl E. Jørgensen
karl@jorgensen.com
www.karl.jorgensen.com
==== Today's fortune:
Journalism is literature in a hurry.
-- Matthew Arnold
Attachment:
pgp2aqcDRfAkR.pgp
Description: PGP signature