On 11/26/02 18:56, Alan Jackson wrote: > I'm at my wit's end. A runaway vim process filled up my disk, and I can't > figure out *where*. I had cleared space a few days ago, and then it filled up > again, when I found and killed the gvim zombie. I get quite different > answers from different tools as well : > > df tells me I've used 36 Gbytes, that is, the whole disk. > Filesystem 1k-blocks Used Available Use% Mounted on > /dev/hdb1 38464340 36316120 194316 100% /home > > But when I try to find where it has gone with du, > > du -k /home yields : > > 5708312 . > > total kb, or 6 Gb. Where is the other 30?
================================ Here's some info on du/df from Sun support site - sunsolve. While it is from Sun, I believe the explanations are applicable. This is supposed to be an open link on sunsolve. Contact me if it's not. WHITE PAPER ID: 26928 SYNOPSIS: du and df Differences (originally published 8/91) DETAIL DESCRIPTION: http://sunsolve.Sun.COM/private-cgi/retrieve.pl?type=0&doc=fwpaper%2F26928&display=plain ============================================== This one may not be in an open area, so including it here http://sunsolve.Sun.COM/private-cgi/retrieve.pl?type=0&doc=infodoc%2F4083&display=plain INFODOC ID: 4083 SYNOPSIS: ADMIN UFS: du and df show different results DETAIL DESCRIPTION: The following infodoc/SRDB assumes a PATH variable that contains /usr/sbin and /usr/bin. For commands or files that normally exist outside of these common directories, full paths are specified. Why "du" and "df" report different totals of used disk space? SHORT ANSWER There are 3 reasons why du and df can show different answers: 1. Inconsistent fileystem requiring fsck(1m). 2. Process with open file which does not exist in filesystem. 3. Mount point directory contains data. LONG ANSWER Before going into detail for the 3 possibilities, it is important to recognise how du and df obtain their answers: . du "walks" the filesystem (like "find" command would), checking the size of each file in turn, and keeping track of the total. . df makes a system call to the filesystem itself and requests a number of details, one of which is the current disk space used. (it gets the info directly from the superblocks of the filesystem). 1. Inconsistent fileystem requiring fsck(1m). If the filesystem becomes corrupt/inconsistent for some reason, it is quite likely that du and df will differ. What can be seen by a process looking at the filesystem (ie du), does not match up with the view the filesystem itself has (ie what will be returned to the querying df process). Corrupt/inconsistent filesystems should be repaired using fsck(1m). 2. Process with open file which does not exist in the filesystem directory structure. This scenario commonly occurs when some process keeps writing to a file (usually a logfile) and a sysadmin deletes the file in panic to prevent the filesystem from filling up. But the offending process keeps running and the space is not freed (the process keeps the file open). The disk blocks associated with a file are actually deleted and made available for reuse when the last "reference" to the file is removed. When a Unix process opens a file, the reference count to that file is incremented. Subsequently, if the file itself is removed from the filesystem, the data blocks remain in use until the process closes the file, either explicitly with close(2), or implicitly when the process dies. Under these conditions, du will be unable to "see" the file in the filesystem (it was rm'd from the dir. structure), and therefore will not count its size, but df (in getting the answer from the filesystem itself) "knows" the file still exists. When the process closes the file (explicitly, or implicitly when the process either quits or is killed, or the machine is rebooted), the disk blocks will return to the freelist and du and df will agree. Actually it is the unmount and remount of the filesystem that fixes this problem. But obviously if some process has an open file on the filesystem, it will be impossible to unmount the filesystem (device busy). See infodoc 17720 for additional info on the above scenario. 3. Directory mount point containing data. As filesystems are mounted on top of directories, if a directory mount point contains data, the du process will be unable to see this data (seeing only the mounted filesystem), but the underlying filesystem will still keep track of this data, consequently df will report the extra disk space in use. Unmounting the filesystem will reveal the data. However, if the mounted filesystem is being used by running processes it will not be possible to unmount it. Either identify and kill the processes (fuser(1m), etc), or reboot (possibly in single user mode) to check the mount point directory. Keywords: troubleshooting, error, failure, file, system, full, discrepancy Note: This document contains info previously available in SRDB 13165 (step 3 above) APPLIES TO: OS File System ========================================== This one as well... http://sunsolve.Sun.COM/private-cgi/retrieve.pl?type=0&doc=infodoc%2F17734&display=plain INFODOC ID: 17734 SYNOPSIS: How to illustrate how 'du' and 'df' may not match. DETAIL DESCRIPTION: The 'du' and 'df' command sometimes do not match. One of the reasons this occurs is that an opened file was removed from the system, but the process that had the file opened is still running. Many people do not believe this. The following steps quickly illustrate this phenomenon. 1. Create a file of a substantial size to make the 'df' output change. For example # df -kl . Filesystem kbytes used avail capacity Mounted on /dev/dsk/c0t0d0s0 1091719 613356 423778 60% / # # mkfile 100m bigfile # df -k . Filesystem kbytes used avail capacity Mounted on /dev/dsk/c0t0d0s0 1091719 715828 321306 70% / 2. Begin a process which "opens" the file. # cat >> bigfile This 'cat' command will sit there forever. Just leave it alone. The file "bigfile" is now opened. If you have 'lsof' installed (lsof is a neat freeware program which lists opened files), you can see that the file 'bigfile' is opened. 3. In another window, remove the file. # rm bigfile 4. Check the size of the filesystem. Notice that the space has NOT be reclaimed. # df -k . Filesystem kbytes used avail capacity Mounted on /dev/dsk/c0t0d0s0 1091719 715828 321306 70% / 5. Stop the 'cat' program (by pressing ^C in that window). Now that the program has stopped, you can see that the space has finally been reclaimed. # df -kl . Filesystem kbytes used avail capacity Mounted on /dev/dsk/c0t0d0s0 1091719 613356 423778 60% / APPLIES TO: Operating Systems/Solaris/Solaris 2.x, AFO Vertical Team Docs/UNIX ATTACHMENTS: ============================================= -jhb- _______________________________________________ Linux-users mailing list [EMAIL PROTECTED] Unsubscribe/Suspend/Etc -> http://www.linux-sxs.org/mailman/listinfo/linux-users
