Re: [9fans] Re: some Plan9 related ideas

[Francisco Ballesteros <nemo@lsub.org>]

We added two (library) calls readf and writef that perform file I/O
besides resolving the name. We found ourselves calling them a lot, because
in many cases it's very convenient. They would be
an opportunity to "batch" walk/open/read(s)/clunk, which happen
a lot. However, this would require changing the kernel (even more than we
did for Plan B).

I think the man page is at http://planb.lsub.org/magic/man2html/2/readf

We would be very interested on implementing this change for Plan 9
because we found
that the main problem we have in Plan B
is  the latency accessing the various file servers,
because of the addition of the individual RPC  turn around times.

Any thought on this? 

On 8/30/05, Dave Eckhardt <davide+p9@cs.cmu.edu> wrote:
> > 'Tailcall optimizations' for filesystems with other mounted
> > filesystems
> 
> In Plan 9 all mounts are done at the client side, so this
> wouldn't be an optimization--it's the only case.
> 
> > * Macro messages
> > Lightweight clients (such as microcontrollers) that communicate
> > with a fileserver using 9P protocol over flaky radio connections
> > would benefit from being able to compose several messages (eg:
> > OPEN+READ+CLUNK) together a a single macro packet.
> 
> 9P runs over TCP, so I don't think there's a packet-boundary
> problem here.  Getting a client to send the three messages
> at once would seem to be the problem, since at present the
> open() system call won't complete until the 9P message gets
> its reply... there isn't an open()+read()+close() system
> call.  And you'd probably need to reinvent or clone existing
> work on batch RPC's to do things like fill the result of the
> OPEN into the subsequent READ request.
> 
> > Also if in most cases, the number of operations performed
> > during the time a file is open are small, it limits the number
> > of open files and corresponding the state that needs to be
> > stored for fids.
> 
> Collecting or finding somebody else's data on that "if" might
> be a good first step.
> 
> Dave Eckhardt
>