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