(in)appropriate uses for MAXBSIZE

[Bruce Evans]

On Wed, 14 Apr 2010, Rick Macklem wrote:

> On Wed, 14 Apr 2010, Bruce Evans wrote:
> [stuff snipped]
>> 
>> Indeed, I was only caring about a LAN environment.  Especially with
>> LANs optimized for latency (50-100 uS), nfs performance is poor for
>> small files, at least for the old nfs client, mainly due to close to
>> open consistency defeating caching, but not a problem for bulk transfers.
>
> And I'll admit I was thinking that for a low latency LAN, a large read/write 
> RPC wouldn't have a negative impact, but it sounds like
> you've found 16Kb to be optimal for this case.

I'll try to find old benchmark results or repeat the benchmarks.

> For NFSv4, if the client has a delegation for the file, it doesn't
> have worry about close/open consistency, so there is some hope w.r.t.
> small files for this case.

Do you have benchmarks?  A kernel build (without -j) is a good test.
Due to include bloat and include nesting bloat, a kernel build opens
and closes the same small include files hundreds or thousands of times
each, with O(10^5) includes altogether, so an RPC to read attributes
on each open costs a lot of latency.  nfs on a LAN does well to take
only 10% longer than a local file system on a LAN and after disabling
close/open constency takes only about half as much longer, by reducing
the nomber of RPCs by about a factor of 2.  The difference should be
even more noticable on a WAN.  Building with -j reduces the extra
length by not stalling the whild build waiting for each RPC.  I probably
needed it to take only 10% longer.

Bruce