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.
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
by id - which is what it does most of the time for resolving nfs handles
anyway. Should be more efficient than the current scheme.
Just rambling, not a single line of code was consulted in writing
You want to make a big fat btree directory for testing this stuff.
Make sure it gets
at least a couple of layers of node blocks.
On Nov 30, 2007, at 1:22 AM, Timothy Shimmin wrote:
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 revert to the old inefficient
Probably why Steve did this: :)
date: 2001/03/15 23:33:20; author: lord; state: Exp; lines: +54 -17
Change linvfs_readdir to allocate a buffer, call xfs to fill it, and
then call the filldir function on each entry. This is instead of
filldir deep in the bowels of xfs which causes locking problems.
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/
[Index of Archives]
[Video 4 Linux]
[Linux for the blind]