Subject: Re: Raising NFS parameters for higher bandwith or "long fat pipe"
To: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
From: Jonathan Stone <jonathan@dsg.stanford.edu>
List: tech-net
Date: 12/13/2003 17:35:46
>i guess you're looking at wrong place.
>see genfs_getpages, which issues read-ahead.
>it isn't a very clever strategy, but i think it works fine
>for dumb sequential reads like "dd if=..".

No, in fact it doesn't work fine, it works very badly: that is the
problem.

Manuel Bouyer's message to tech-net shows very clearly that it doesn't
work fine.  It works correctly, but the performance is terrible.
Manuel's datapoints show NetBSD 1.6 NFS clients get little more than
*one-third* the read throughput that a Solaris NFS client gets from
the same (NetBSD) server.

I agree with Thor (and you?), in that going through getpages() for a
read, and therefore limiting read-ahead to a limit thats appropriate
for page-in, is a Bad Idea in general, and especially bad for
high-latency (high bandwidth*rtt) filesystems like NFS.



>> Below is an untested, almost certinaly broken, patch showing how
>> FreeBSD 4.x does NFS readahead. It' basically two chunks:
>
>yes, i agree it's broken. :-)
>we're not using traditional buffer cache interfaces for VREG's pages.

So how can we make it non-broken? Or is adding more readahead
here just not going to help an app doing dd= ... ?