On Tue, Aug 05, 2008 at 09:59:48AM +0100, David Woodhouse wrote: > On Tue, 2008-08-05 at 18:51 +1000, Dave Chinner wrote: > > On Mon, Aug 04, 2008 at 02:19:12AM -0400, Chuck Lever wrote: > > > So, the JFFS2 locking problem is a garbage-collection issue. I'm not > > > sure this is the case with other file systems like XFS and OCFS2. My > > > impression was that XFS had a transaction logging deadlock, > > > > Just to clarify - XFS has a directory buffer lock deadlock. That is, > > while reading the contents of the directory buffer it is locked to > > prevent modifications from occurring while extracting the contents. > > Looking up an entry in the directory also requires the directory > > buffer lock (for the same reason), so calling the lookup while > > already holding the directory buffer lock (i.e from the filldir > > callback) will deadlock. > > But if we had a ->lookup_locked() or ->lookup_fh() method which is > _guaranteed_ to be called from within your ->readdir(), you could manage > to bypass that locking and avoid the deadlock? I *think* it's possible. It's definitely in the realm of difficult because the buffer locks are a couple of layers removed from the directory code and both readdir and lookup assume exclusive access to the directory block. We'd probably have to introduce a directory buffer (dabuf) cache layer with it's own locking to allow multiple accessors to the buffer at the same time. Christoph might have some other ideas for this, but I think it's going to take significant surgery to implement a 'recursive lockless lookup' like this. The main problem you are going to have is finding someone who has the time to do the XFS work. If you only implement this lookup interface, then I'd say it's going to be some time before XFS would actually use it.... 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
