On Fri, Nov 30, 2007 at 04:36:25PM -0600, Stephen Lord wrote: > Wow, was it really that long ago! > > Looks like the readdir is in the bowels of the btree code when filldir gets > called > here, there are probably locks on several buffers in the btree at this > point. This > will only show up for large directories I bet.
Chris saw it with block-form directories. I've verified it works fine with short-form directories, and the leaf code looks like it could happen aswell. I also remember gfs2 running into a similar problem. > The xfs readdir code has the complete xfs inode number in its hands at this > point > (filldir is not necessarily getting all the bits of it). All we are doing > the lookup > for really is to get the inode number back again so we can get the inode > and get the attributes. Rather dumb really. There has got to be a way of > doing a callout structure here so that the inode number can be pushed > through filldir and back into an fs specific call. The fs then can do a > lookup > by id - which is what it does most of the time for resolving nfs handles > anyway. Should be more efficient than the current scheme. Yes, a lot more efficient. But it means adding a new operation for use by the nfs server. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
