On Mon, Mar 17, 2003 at 09:33:00AM +1000, Warren Toomey wrote:
>On Sun, Mar 16, 2003 at 06:00:13PM -0500, Rob Clark wrote:
>> i.e.,
>> # du -kx / | sort -nr | head -20
>> 45959 /
>> ...
>>
>> # df
>> Filesystem 1K-blocks Used Avail Capacity Mounted on
>> /dev/ad0s1a 128990 105842 12830 89% /
>
>I can think of two issues here.
>
>1. du adds up the file sizes and gives you a result in 1K units. But,
> each file actually takes up an integral number of fragments. If your
> / fragment size is, say 4K, and you have a whole heap of small files,
> then du will report a total size which is much less than df.
I'm not sure about this one. du accumulates {stat(2)}.st_blocks which
is described as the actual number of 512-byte blocks allocated to a
file.
>2. You have a process running that has an open file descriptor to a file
> on / which has been unlinked (e.g rm'd). The process is still using
> the file, but the name no longer exists, and so du or ls won't show it.
> To test this, reboot the system and see if the disk space goes up.
This is fairly common. ports/sysutils/lsof can tell you if there are
unlinked files open (by the missing name). Some system utilities
create files in /tmp and then unlink them while they're open for
security.
I can think of a few others:
3. You have a lot of file (actually filesystem block) allocation and
freeing on a soft-updates system. It takes softupates 30-60 seconds
to return freed blocks back to the free list. If there's a lot of
file creation/deletion you can quickly run out of space.
4. You've mounted a filesystem over a non-empty directory. Eg you were
using /tmp in single-user mode and forgot to empty it before going
to multi-user mode with /tmp on a different filesystem.
My bet is 2 or 3.
Peter
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
