<br><div class="gmail_quote">On Tue, May 8, 2012 at 12:40 PM, Dave Chinner <span dir="ltr"><<a href="mailto:david@fromorbit.com" target="_blank">david@fromorbit.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Tue, May 08, 2012 at 11:24:52AM +0800, Zhu Han wrote:<br>
> On Tue, May 8, 2012 at 7:59 AM, Dave Chinner <<a href="mailto:david@fromorbit.com">david@fromorbit.com</a>> wrote:<br>
><br>
> > On Mon, May 07, 2012 at 08:44:17PM +0800, Zhu Han wrote:<br>
> > > Seems like xfs of CentOS 6.X occupies much more storage space than<br>
> > desired<br>
> > > if fallocate is used against the file. Here is the step to reproduce it:<br>
> ><br>
> > You test case is not doing what you think it is doing.<br>
><br>
> Thanks for pointing it out.<br>
><br>
> > > By the way, is it normal when the file is moved around after the<br>
> > > preallocated region is filled with data?<br>
> > ><br>
> > > $ uname -r<br>
> > > 2.6.32-220.7.1.el6.x86_64<br>
> > ><br>
> > > $fallocate -n --offset 0 -l 1G file ---->Write a little more data than<br>
> > > the preallocated size<br>
> > ><br>
> > > $ xfs_bmap -p -vv file<br>
> > > file:<br>
> > > EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET<br>
> > > TOTAL FLAGS<br>
> > > 0: [0..2097151]: 2593408088..2595505239 21 (29420144..31517295)<br>
> > > 2097152 10000<br>
> > ><br>
> > > $ dd if=/dev/zero of=/tmp/file bs=1M count=1026 conv=fsync<br>
> ><br>
> > That does a truncate first, removing all the preallocated space. Use<br>
> > conv=notrunc to avoid this. Hence the space allocated by this<br>
> > new write is different to the space allocated by the above<br>
> > preallocation. The file has not been moved, the filesystem just did<br>
> > what you asked it to do.<br>
> ><br>
> > ><br>
> > > $ xfs_bmap -p -vv file<br>
> > > file:<br>
> > > EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET<br>
> > > TOTAL FLAGS<br>
> > > 0: [0..4194303]: 2709184016..2713378319 22 (23101408..27295711)<br>
> > > 4194304 00000<br>
> ><br>
> > And so now you've triggered the speculative delayed allocation<br>
> > beyond EOF, which is normal behaviour. Hence there are currently<br>
> > unused blocks beyond EOF which will get removed either when the next<br>
> > close(fd) occurs on the file or the inode is removed from the cache.<br>
> ><br>
><br>
> Close(fd) should be invoked before dd quits. But why the extra blocks<br>
> beyond EOF are not freed?<br>
<br>
</div></div>The removal is conditional on how many times the fd has been closed<br>
with dirty data on the inode.<br>
<div class="im"><br>
> The only way I found to remove the extra blocks is truncate the file to its<br>
> real size.<br>
<br>
</div>If the close() didn't remove them, they will be removed when the<br>
inode ages out of the cache. Why do you even care about them?<br></blockquote><div><br>Our distributed system depends on the real length of files to account the space usage. This behavior make the account inaccurate. <br>
<br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
Cheers,<br>
<br>
Dave.<br>
--<br>
Dave Chinner<br>
<a href="mailto:david@fromorbit.com">david@fromorbit.com</a><br>
</div></div></blockquote></div><br>