xfs
[Top] [All Lists]

Re: du vs. ls

To: pille <pille+xfs+mailinglist+sgi@xxxxxxxxxxxx>
Subject: Re: du vs. ls
From: Brian Foster <bfoster@xxxxxxxxxx>
Date: Fri, 04 Jan 2013 15:18:00 -0500
Cc: xfs@xxxxxxxxxxx
In-reply-to: <50E71D1F.3040103@xxxxxxxxxxxx>
References: <50E6F6D4.5090407@xxxxxxxxxxxx> <20130104161449.GA25093@xxxxxxx> <50E71D1F.3040103@xxxxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0
On 01/04/2013 01:19 PM, pille wrote:
....
> On 01/04/2013 05:14 PM, Matthias Schniedermeyer wrote:
>> This fixes itself over time.
>> Either do enough IO that the cache of the copy gets reused or umount or 
> 
> i cannot understand that. does a already written file gets reorganized
> due to high I/O, because we've got that periodically.
> 

No, it just means that XFS allocates extra blocks beyond the end of the
file as the file is extended. Start a streaming write and do a 'watch
"du file; ls -l file"' to see how the file size and space used increase
differently.

Typically this extra space is simply trimmed off when the file is
closed, but it can hang around as an optimization if a file is opened,
written and closed frequently. If the optimization occurs, the extra
space is not trimmed off until the inode is reclaimed from cache.

Note that in upcoming kernels (3.8 I believe), we have also added a
background scanner (controlled via
/proc/sys/fs/xfs/speculative_prealloc_lifetime) that checks for such
(non-dirty) files every 5 minutes and trims off the space.

Brian

> cheers
>   pille
> 
> _______________________________________________
> xfs mailing list
> xfs@xxxxxxxxxxx
> http://oss.sgi.com/mailman/listinfo/xfs
> 

<Prev in Thread] Current Thread [Next in Thread>