Re: Use of READDIRPLUS on large directories

[NeilBrown <neilb@suse.de>]

On Thu, 17 Mar 2011 13:44:53 -0400 "J. Bruce Fields" <bfields@fieldses.org>
wrote:

> On Thu, Mar 17, 2011 at 11:55:22AM +1100, NeilBrown wrote:
> > Strangely, when I try NFSv4 I don't get what I would expect.
> > 
> > "ls" on an unpatched 2.6.38 takes over 5 seconds rather than around 4.
> > With the patch it does back down to about 2. (still NFSv3 at 1.5).
> > Why would NFSv4 be slower?
> >  On v3 we make 44 READDIRPLUS calls and 284 READDIR calls - total of  328
> >        READDIRPLUS have about 30 names, READDIR have about 100
> >  On v4 we make 633 READDIR calls - nearly double.
> >        Early packed contain about 19 name, later ones about 70
> > 
> > Is nfsd (2.6.32) just not packing enough answers in the reply?
> > Client asks for a dircount of 16384 and a maxcount of 32768, and gets
> > packets which are about 4K long - I guess that is PAGE_SIZE ??
> 
> >From nfsd4_encode_readdir():
> 
> 	maxcount = PAGE_SIZE;
> 	if (maxcount > readdir->rd_maxcount)
> 		maxcount = readdir->rd_maxcount;
> 
> Unfortunately, I don't think the xdr encoding is equipped to deal with
> page boundaries.  It should be.

Bah humbug.
NFSv3 gets it right - it just encodes into the next page and then copies back.

Sounds like a simple afternoon's project .... now if only we could find
someone with a simple afternoon :-)
Getting a realistic upper limit on the size of the reply (which is more
variable for v4 than for v3) would be the only tricky bit..
Though nfsd4_encode_fattr looks fairly idempotent, so you could just
try to encode and if it doesn't fit:
  allocate next page
  encode into there
  copy some into previous page
  copy rest down.

NeilBrown