]> pilppa.com Git - linux-2.6-omap-h63xx.git/commit
Fix nfsd truncation of readdir results
authorDoug Nazar <nazard@dragoninc.ca>
Wed, 5 Nov 2008 11:16:28 +0000 (06:16 -0500)
committerJ. Bruce Fields <bfields@citi.umich.edu>
Sun, 9 Nov 2008 20:15:50 +0000 (15:15 -0500)
commitb726e923ea4d216027e466aa602d914e4b4a63af
treecb28235201c56c6637692efc8dcffca76fa5865e
parentd7dc61d0a70371b1c6557ea8ffbc60fff94c8168
Fix nfsd truncation of readdir results

Commit 8d7c4203 "nfsd: fix failure to set eof in readdir in some
situations" introduced a bug: on a directory in an exported ext3
filesystem with dir_index unset, a READDIR will only return about 250
entries, even if the directory was larger.

Bisected it back to this commit; reverting it fixes the problem.

It turns out that in this case ext3 reads a block at a time, then
returns from readdir, which means we can end up with buf.full==0 but
with more entries in the directory still to be read.  Before 8d7c4203
(but after c002a6c797 "Optimise NFS readdir hack slightly"), this would
cause us to return the READDIR result immediately, but with the eof bit
unset.  That could cause a performance regression (because the client
would need more roundtrips to the server to read the whole directory),
but no loss in correctness, since the cleared eof bit caused the client
to send another readdir.  After 8d7c4203, the setting of the eof bit
made this a correctness problem.

So, move nfserr_eof into the loop and remove the buf.full check so that
we loop until buf.used==0.  The following seems to do the right thing
and reduces the network traffic since we don't return a READDIR result
until the buffer is full.

Tested on an empty directory & large directory; eof is properly sent and
there are no more short buffers.

Signed-off-by: Doug Nazar <nazard@dragoninc.ca>
Cc: David Woodhouse <David.Woodhouse@intel.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
fs/nfsd/vfs.c