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. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
