On Tue, Nov 27, 2012 at 08:28:45AM +1100, Dave Chinner wrote: > We still need the iolock deep in the guts of the filesystem, though. I don't think we do. The only thing that comes close to it is xfs_swap_extents passing the XFS_IOLOCK_EXCL to xfs_trans_ijoin so that the transaction commit automatically unlocks it, but that can be trivially replaced with a manual unlock. > I suspect that if we are going to change the VFS locking, then we > should seriously consider allowing the filesystem to provide it's > own locking implementation and the VFS just pass the type of lock > required. Otherwise we are still going to need all the locking > within the filesystem to serialise all the core pieces that the VFS > locking doesn't serialise (e.g. EOF truncation on close/evict, > extent swaps for online defrag, etc). The VFS currently doesn't hardcode i_mutex for any data plane operations, only a few generic helpers do it, most notably generic_file_aio_write (which can be bypassed by using a slightly lower level variant) and __blockdev_direct_IO when used in DIO_LOCKING mode. -- 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
