[lug] du vs df

[Jeffrey S. Haemer]

Here's a pretty good
list<http://linuximagination.blogspot.com/2010/10/du-and-df-show-different-results-after.html>of
possible reasons.

The one Jose alludes to is because of last-close semantics: If I have a
file open, and you remove it, the name (just an entry in a directory) goes
away, but the file itself (the inode and its associated space) is still
there until I close it.  Until I close it, df, which sees what the kernel
sees, still knows the file is taking up space. In contrast, du, which only
looks at files with names, doesn't.

This is occasionally useful. If your program opens a file, then immediately
removes it,
you're left with a file that only that program can access, which persists
until you close it or your program terminates. Of course, if the file grows
without bound your popularity may drop at the same rate as free-space on
the disk.


On Mon, Mar 11, 2013 at 1:49 PM, Jose Castilleja <tilleja at gmail.com> wrote:

> From my own experiences, this was because a java process was not releasing
> deleted file space right away.  I did an lsof to help identify this.
>
> Jose
> On Mar 11, 2013 1:47 PM, "Michael J. Hammel" <mjhammel at graphics-muse.org>
> wrote:
>
>> I ran into an interesting problem today.  We have hg configured on
>> a /home partition and a user was reporting out of disk space when using
>> it.  I checked with df -m and sure enough the partition was full.
>>
>> So I figured someone screwed up and filled up their home directory with
>> junk.  I did a du -sm /home and found only about 40% of the partition
>> size of data.  Du reported plenty of disk space.  df said the partition
>> was full.  I don't expect them to be identical, just close.  du was 60%
>> less than df (roughly) on a partition with about 220GB of total space.
>>
>> I'm assuming this was some kind of sparse file, though I'm not clear why
>> it showed itself on /home.  /home is just for user data, including our
>> mercurial and internal web repositories.
>>
>> While researching this a bit, I watched as df showed the partition being
>> cleared of the extra usage.  Lots of space being freed up very fast.  du
>> still showed the same thing.
>>
>> Any thoughts on what could make df think the partition was full but du
>> not think that?  I'm trying to figure out what got us into that
>> situation to begin with.  I suppose I could move the scm and web stuff
>> to another partition but I'd like to know *how* this all came about.
>>
>> One possible event during this was a junior engineer was running a find
>> on the entire filesystem looking for files with IP addresses in them
>> (the boss asked if we logged web accesses, and that was his first idea
>> to find out.  He has been properly flogged.).  I suppose if he was
>> saving the output to a file, then deleted the file while the process
>> ran, something bad might have happened.  Even that seems a bit of a
>> stretch.
>>
>> Other than that, I'm not clear what might have been running to cause
>> this.
>>
>> --
>> Michael J. Hammel <mjhammel at graphics-muse.org>
>>
>> _______________________________________________
>> Web Page:  http://lug.boulder.co.us
>> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
>> Join us on IRC: irc.hackingsociety.org port=6667 channel=#hackingsociety
>>
>
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: irc.hackingsociety.org port=6667 channel=#hackingsociety
>



-- 
Jeffrey Haemer <jeffrey.haemer at gmail.com>
720-837-8908 [cell], http://seejeffrun.blogspot.com [blog],
http://www.youtube.com/user/goyishekop [vlog]
*פרייהייט? דאס איז יאַנג דינען וואָרט.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20130311/0a654c0f/attachment.html>