aboutsummaryrefslogtreecommitdiff
path: root/README
diff options
context:
space:
mode:
authorDoug Nazar <nazard@dragoninc.ca>2008-11-05 06:16:28 -0500
committerJ. Bruce Fields <bfields@citi.umich.edu>2008-11-09 15:15:50 -0500
commitb726e923ea4d216027e466aa602d914e4b4a63af (patch)
treecb28235201c56c6637692efc8dcffca76fa5865e /README
parentd7dc61d0a70371b1c6557ea8ffbc60fff94c8168 (diff)
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>
Diffstat (limited to 'README')
0 files changed, 0 insertions, 0 deletions