On Thu, Jan 08, 2015 at 04:24:48AM -0800, Christoph Hellwig wrote: > > This patchset passes xfstests and various benchmarks and stress > > workloads, so the real question is now: > > > > What have I missed? > > > > Comments, thoughts, flames? > > Why is this done in XFS and not in generic code? We might be able to do that. Indeed, if the concept is considered sound, then this was the next question I was going to ask everyone. I just don't know enough about other filesystem locking to be able to say "this will always work", hence the wide distribution of the RFC. Different filesystems have different locking heirarchies, and so there may be some are not able to use this technique (cluster/network fs?).... In the end, however, the main reason I decided on doing it in XFS first was things like that swap extent operation that requires us to lock multiple locks on two inodes in a specific order. We already have all the infrastructure in XFS to enforce and *validate at runtime* the specific lock ordering required, so it just made it a no-brainer to do it this way first. We also have several entry points in XFS that don't go through the VFS that needed this page fault serialisation and they currently only use XFS internal locks to serialise against IO. Again, doing it in XFS first is the easy-to-validate solution. 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
