On Wed, Oct 29, 2008 at 05:00:14AM +0100, Nick Piggin wrote: > On Wed, Oct 29, 2008 at 02:16:45PM +1100, Dave Chinner wrote: > > FWIW, the core issue here is that we've got to do the > > filemap_fdatawait() call in the ->fsync method because ->fsync > > gets called before we've waited for the data I/O to complete. > > XFS updates inode state on I/O completion, so we *must* wait > > for data I/O to complete before logging the inode changes. I > > think btrfs has the same problem.... > > Interesting. Does that mean you can do without the final filemap_fdatawait? We could, yes. > Can you do the first fdatawait without i_mutex held? I don't see why not - I/O completion is only touching the XFS inode. XFS has it's own inode locks for I/O and inode exclusion, and the mapping tree lock protects the tree walk that the fdatawait is doing... > There was some talk IIRC about moving all this logic into the filesystem > to provide more flexibility here. If there is still enough interest, > we should get that moving... It would simplify some of the code in XFS, that's for sure ;) Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
