Re: [9fans] Do we have a catalog of 9P servers?

[sqweek <sqweek@gmail.com>]

On Wed, Nov 12, 2008 at 1:50 PM, erik quanstrom <quanstro@quanstro.net> wrote:
>> protocol itself. The problem is it forces the server and client to
>> synchronise on every read/write syscall, which results in terrible
>> bandwidth utilisation. Unless we see some remarkable improvements in
> [...]
>>
>>  I'm sure I've missed something, but readahead is safe for all these
>> constructs except event files, where if you readahead (and get data)
>> but the client closes the file before actually read()-ing the buffered
>
> unfortunately, client caching is problematic.
>
> the open research question is, how to make latency the
> domain of the file server(s) and not of the application.

 I don't think that is possible without the current set of
syscalls/algorithms... Currently we have this (where time is measured
in one-way trips across the network):

0: the client calls pread()
0: devmnt sends a Tread to the server
1: server recieves Tread
1: server sends Rread
2: client recieves Rread
2: pread() returns

 You can't do any better than this if the server is involved, so what
saving is there to be made aside from:

0: the client calls pread()
0: devmnt notices it has the requested data cached
0: pread() returns

 devmnt doesn't have to be the one to choose what to cache, I suppose.
You could have the file server readahead safely, at the cost of having
to teach devmnt (and clients in general) to deal with unsolicited
messages from file servers, and be careful about rate limiting...

 The only other way around the problem I can see is an alternate set
of syscalls (or library calls, but either way you'd need to rewrite
anything that uses read()).
-sqweek