On Nov 30, 2007, at 5:04 PM, Chris Wedgwood wrote: On Fri, Nov 30, 2007 at 04:36:25PM -0600, Stephen Lord wrote: Looks like the readdir is in the bowels of the btree code when filldir gets called her
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 pro
On Nov 30, 2007, at 5:04 PM, Chris Wedgwood wrote: On Fri, Nov 30, 2007 at 04:36:25PM -0600, Stephen Lord wrote: Looks like the readdir is in the bowels of the btree code when filldir gets called her
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 pro
The current readdir implementation deadlocks on a btree buffers locks because nfsd calls back into ->lookup from the filldir callback. The only short-term fix for this is to revert to the old ineffic
This seems to work really well here. This should probably be submitted for inclusion stable-2.6.24. Perhaps a version with the #if 0 [...] stuff dropped? (I'm happy to send a patch for that if you pr
On Sun, 25 Nov 2007, Christoph Hellwig wrote: This patch does exactly that and reverts xfs_file_readdir to what's basically the 2.6.23 version minus the uio and vnops junk. Thanks, works here too (wi
Christoph Hellwig wrote: The current readdir implementation deadlocks on a btree buffers locks because nfsd calls back into ->lookup from the filldir callback. The only short-term fix for this is to
I've been giving the fix some QA - that change appears to have caused a different regression as well so I'm holding off for a little bit until we know what the cause of the other regression is before
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
I see it for fairly small directories. Larger than what you can stuff into an inode but less than a block (I'm not checking but fairly sure that's the case). Can you explain why the offset is capped
The current readdir implementation deadlocks on a btree buffers locks because nfsd calls back into ->lookup from the filldir callback. The only short-term fix for this is to revert to the old ineffic
This seems to work really well here. This should probably be submitted for inclusion stable-2.6.24. Perhaps a version with the #if 0 [...] stuff dropped? (I'm happy to send a patch for that if you pr
On Sun, 25 Nov 2007, Christoph Hellwig wrote: This patch does exactly that and reverts xfs_file_readdir to what's basically the 2.6.23 version minus the uio and vnops junk. Thanks, works here too (wi
Christoph Hellwig wrote: The current readdir implementation deadlocks on a btree buffers locks because nfsd calls back into ->lookup from the filldir callback. The only short-term fix for this is to
I've been giving the fix some QA - that change appears to have caused a different regression as well so I'm holding off for a little bit until we know what the cause of the other regression is before
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
I see it for fairly small directories. Larger than what you can stuff into an inode but less than a block (I'm not checking but fairly sure that's the case). Can you explain why the offset is capped