[opensuse] df says partition is 100% full, but du shows only 20% is used
I have a machine here where df shows a mount point being 100% full. However, when you do a du -h it shows that only 1.1G of the 5G is being used. How can I make sure that df is reporting accuratly? -- I say never be complete. I say stop being perfect. I say let's evolve. Let the chips fall where they may. -Fight Club -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Wednesday 03 June 2009 09:59:09 pm Ben Kevan wrote:
I have a machine here where df shows a mount point being 100% full. However, when you do a du -h it shows that only 1.1G of the 5G is being used. How can I make sure that df is reporting accuratly?
Check Trash Can, and see then df and du. -- Regards, Rajko http://news.opensuse.org/category/people-of-opensuse/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Wednesday June 3 2009, Ben Kevan wrote:
I have a machine here where df shows a mount point being 100% full. However, when you do a du -h it shows that only 1.1G of the 5G is being used. How can I make sure that df is reporting accuratly?
They report different things. Df looks at file system-wide index information that the file system keeps track of during ongoing operations. Du traverses the directory structure from the starting point(s) you specify as arguments and adds up the space used by each file it encounters. If you really do start du at the root of a file system and it has access to all the directories it encounters (guaranteed only if run as root), then it is accurate, with one possible exception: If a file is "sparse" (regions that have never been explicitly written but only seeked over during writing) it will over-report usage based on the file's size under the assumption that ever logical sector of the file occupies a physical sector on the disk. If there are no sparse files, du sees the whole file system and there's a discrepancy w.r.t. df, then there could be some form of corruption in the file system, as unlikely as that is in practice. The most likely source of discrepancy is that you're not really applying du to the entire file system (a generalization of Rajko's suggestion). Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Wed, 03 Jun 2009 21:44:20 -0700, Randall R Schulz
On Wednesday June 3 2009, Ben Kevan wrote:
I have a machine here where df shows a mount point being 100% full. However, when you do a du -h it shows that only 1.1G of the 5G is being used. How can I make sure that df is reporting accuratly?
They report different things. Df looks at file system-wide index information that the file system keeps track of during ongoing operations. Du traverses the directory structure from the starting point(s) you specify as arguments and adds up the space used by each file it encounters.
If you really do start du at the root of a file system and it has access to all the directories it encounters (guaranteed only if run as root), then it is accurate, with one possible exception: If a file is "sparse" (regions that have never been explicitly written but only seeked over during writing) it will over-report usage based on the file's size under the assumption that ever logical sector of the file occupies a physical sector on the disk.
If there are no sparse files, du sees the whole file system and there's a discrepancy w.r.t. df, then there could be some form of corruption in the file system, as unlikely as that is in practice.
The most likely source of discrepancy is that you're not really applying du to the entire file system (a generalization of Rajko's suggestion).
Randall Schulz
But a 4GB difference in reporting? That's massive.. When I get into work i'll check the trash, but I think someone may have moved a file that was open by an app. So it may still be loaded in the write buffers. I did lsof +L1 <directory> and noticed a file marked <deleted> that was 0 bytes. Thanks for the explination Randall and Rajko -- I say never be complete. I say stop being perfect. I say let's evolve. Let the chips fall where they may. -Fight Club -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Thursday June 4 2009, Ben Kevan wrote:
...
But a 4GB difference in reporting? That's massive.. When I get into work i'll check the trash, but I think someone may have moved a file that was open by an app. So it may still be loaded in the write buffers. I did lsof +L1 <directory> and noticed a file marked <deleted> that was 0 bytes.
That reminds me... A file can be "removed" (its directory entry(ies) unlinked) and du will be unable to find it, but if it was open at the time all those links were deleted the file will continue to exist, occupy space and be fully usable by any process(es) with a descriptor leading to that file. Only once all such references (in the form of open file descriptors) in running processes are closed will the space occupied by the file on disk disappear. Df will always reflect the true existence of such files (*) (the space they occupy) while du has no way of including them in its usage total. (*) I'd call them zombies—the term fits—but that word already has meaning: A process that has exited but whose parent process has not yet issued the "wait" call that returns the child process' exit status to the parent.
...
Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Thursday 04 June 2009 08:33:53 am Randall R Schulz wrote:
A file can be "removed" (its directory entry(ies) unlinked) and du will be unable to find it, but if it was open at the time all those links were deleted the file will continue to exist, occupy space and be fully usable by any process(es) with a descriptor leading to that file. ...
Df will always reflect the true existence of such files (*) (the space they occupy) while du has no way of including them in its usage total.
That is the explanation, and the reason for runlevel 1 as administrative runlevel. -- Regards, Rajko http://news.opensuse.org/category/people-of-opensuse/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Randall R Schulz wrote:
(*) I'd call them zombies—the term fits—but that word already has meaning: A process that has exited but whose parent process has not yet issued the "wait" call that returns the child process' exit status to the parent.
Randall Schulz
In my shop, we hit this problem from time to time, and we have spontaneously and informally begun to refer to them as "zombie files", with no further definition given or needed. Yes indeed, the term fits... Dan Goodman -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (4)
-
Ben Kevan -
Dan Goodman -
Rajko M. -
Randall R Schulz