Thank you so much for your kindly help.<br><br clear="all">best regards,<br>
韩竹(Zhu Han)<br>
<br><br><div class="gmail_quote">On Wed, May 9, 2012 at 6:31 AM, 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:25:05PM +0800, Zhu Han wrote:<br>
> On Tue, May 8, 2012 at 1:47 PM, Dave Chinner <<a href="mailto:david@fromorbit.com">david@fromorbit.com</a>> wrote:<br>
><br>
> > On Tue, May 08, 2012 at 01:10:55PM +0800, Zhu Han wrote:<br>
> > > On Tue, May 8, 2012 at 12:40 PM, Dave Chinner <<a href="mailto:david@fromorbit.com">david@fromorbit.com</a>><br>
> > wrote:<br>
> > > > 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>><br>
> > > > wrote:<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<br>
> > next<br>
> > > > > > close(fd) occurs on the file or the inode is removed from the<br>
> > 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>
> > > > The removal is conditional on how many times the fd has been closed<br>
> > > > with dirty data on the inode.<br>
> > > ><br>
> > > > > The only way I found to remove the extra blocks is truncate the file<br>
> > to<br>
> > > > its<br>
> > > > > real size.<br>
> > > ><br>
> > > > 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>
> > ><br>
> > > Our distributed system depends on the real length of files to account the<br>
> > > space usage.<br>
> ><br>
> > That's ..... naive. It's never been valid to assume that the file<br>
> > size is an accurate reflection of space usage, especially as it will<br>
> > *always* be wrong for sparse files. In the same light, you also<br>
> > cannot assume that it is an accurate reflection for non-sparse files<br>
> > because we can do both explicit and speculative allocation beyond<br>
> > EOF which only du will show. Not to mention that metadata is not<br>
> > accounted in the file length, and that can consume a significant<br>
> > amount of space, too.<br>
> ><br>
> > > This behavior make the account inaccurate.<br>
> ><br>
> > The block usage reported by XFS is both accurate and correct. The<br>
> > file size reported by XFS is both accurate and correct. You're<br>
> > "account inaccuracy" is assuming that they are the same. Perhaps you<br>
> > should be using quotas for accurate space usage accounting?<br>
> ><br>
> > Anyway, if you really want to stop speculative delayed allocation<br>
> > beyond EOF, then use the allocsize mount option to control it.<br>
> ><br>
><br>
><br>
> Thanks for help.<br>
><br>
> I can control the size of pre-allocation, so no data are written beyond the<br>
> pre-allocated block range, so no speculative allocation is triggered.<br>
> Besides it, our system can sync the accurate space usage of mount point<br>
> periodically.<br>
><br>
> Can you give any hints about the most lightweight approach to get the<br>
> accurate block usage of whole file system?<br>
<br>
</div></div>If you are just after the whole filesystem, then statfs(2) will give<br>
you blocks used and free. If you are after a finer breakdown, then<br>
quotas are probably what you want - they can be used for accounting<br>
separately to the space limiting enforcement. Hence you get<br>
accurate, up-to-date per user, group or project space accounting<br>
without actually limiting space usage at all.<br>
<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>