On Mon, Dec 15, 2003 at 08:34:16AM -0800, Jonathan Stone wrote:
> 
> ... All well and good, but I'm not sure it addresses the fundamental
> issue with NFS: namely, the large latency * bandwith product means NFS
> may want more read-ahead than is `reasonable' for a general
> filesystem.

the read ahead code in general needs more work, I've said this all along.
I only worked on it enough to achieve close to the theoretical maximum
throughput with the hardware I had available at the time, ie. the same
as the pre-UBC code did.  it's dirt simple right now, and it works
well enough for many people.  I'd be happy to see it improved, though.


> David Reese checked our CVS logs and found that our sys/nfs/nfs_bio.c
> *used* to have a read-ahead loop like the one I posted a few days
> back; but chs was removed it in rev 1.53->1.64.
> 
> Is it really true that UBC/UVM means filesystems cannot do read-ahead
> on their own? If not, why not put back the NFS VREG readahead?
> (and if it is, why not fix that?)

currently all read ahead is initiated out of the page-fault handler
(ie. VOP_GETPAGES()), but changing that need not be hugely complicated.
what needs to happen is for the read ahead initiation to be separated
from page-fault resolution, and for both read() and non-read() page-faults
to initiate appropriate read ahead.  the only thing that's really missing
is for the page-fault code to have some way of knowing whether it should
do read ahead, ie. whether or not it's due to a fault on the UBC mapping.

-Chuck