RE: 2.6.28-rc3 truncates nfsd results

["Doug Nazar" <nazard@dragoninc.ca>]

> From: J. Bruce Fields [mailto:bfields@fieldses.org]
> Anyone know where to find the best documentation of the vfs_readdir
> semantics?  I obviously didn't understand it as well as I should.

Hmm.... I seem to remember a conversation about readdir from Al awhile back. Looking....

Here it is:
http://kerneltrap.org/mailarchive/linux-fsdevel/2008/8/12/2903744

Maybe that will help. 

> > The computers showing the issue are not using dir_index. This causes
> > ext3 to read a block at a time, which then means we can end up with
> > buf.full==0 but not finished reading the directory. Before 8d7c4203,
> > we'd always get called again because we never set nfserr_eof which
> > papered over it.
> 
> OK, so if I'm understanding you correctly: there was also (as of
> c002a6c797 "Optimise NFS readdir hack slightly"?) a performance
> regression which could force the client to do more round trips to the
> server to read the whole directory?

>From what I could see yes. On an empty directory there would actually be two readdir 
requests both with eof not set. On a full directory when the sending buffer was full,
func() would return NFS4ERR_TOOSMALL and nfsd_buffered_read would return success. After 
c002a6c797 "Optimise NFS readdir hack slightly", I ended up with buf.used=912, 
buf.full=0 & offset=4096 so we would finish the while loop with a small output buffer, 
eof not set. The client then makes another request and continues so long as forward 
progress was made. After 8d7c4203c6 "nfsd: fix failure to set eof in readdir in some situations"
it would force eof for any small buffer causing the client to terminate the request.

Commit look fine and sure add my signed-off-by. Not sure if we got *all* the bugs but the way 
I see it, every bug is a chance to learn <g>