Re: Issues with delalloc->real extent allocation

[bpm@sgi.com]

Hey Dave,

On Sat, Jan 15, 2011 at 10:55:49AM +1100, Dave Chinner wrote:
> On Fri, Jan 14, 2011 at 03:43:34PM -0600, bpm@sgi.com wrote:
> > It also presents a
> > performance issue which I've tried to resolve by extending
> > xfs_probe_cluster to probe delalloc extents-- lock up all of the pages
> > to be converted before performing the allocation and hold those locks
> > until they are submitted for writeback.  It's not very pretty but it
> > resolves the corruption.
> 
> If we zero the relevant range in the page cache at .aio_write level
> like we do with xfs_zero_eof or allocate unwritten extents instead,
> then I don't think that you need to make changes like this. 

Ganging up pages under lock in xfs_page_state_convert (along with
exactness in xfs_iomap_write_allocate) was needed to provide exclusion
with block_prepare_write because zeroing isn't done in the case of
written extents.

Converting from delalloc->unwritten has the advantage of
__xfs_get_blocks setting each buffer 'new' when you write into the page,
so the zeroing is done properly even if you convert the entire extent to
unwritten in xfs_vm_writepage instead of just the part you're going to
write out.  However, when converting from unwritten->written in the
completion handler you still need to convert only the part of the extent
that was actually written.  That might be a lot of transactions in
xfs_end_io.

> > There is still the issue of crashes...  This could be solved by
> > converting from delalloc to unwritten in xfs_page_state_convert in this
> > very exact way and then to written in the io completion handler.  Never
> > go delalloc->written directly.
> > 
> > I have not had luck reproducing this on TOT xfs and have come to realize
> > that this is because it doesn't do speculative preallocation of larger
> > delalloc extents unless you are using extsize... which I haven't tried.
> 
> Have a look at the dynamic speculative allocation patches that just
> went into 2.6.38 - I'm very interested to know whether your tests
> expose stale data now that it can do up to an entire extent (8GB on
> 4k block size) of speculative delalloc for writes that are extending
> the file.

8GB, Eek!

-Ben

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs