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 > _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
