From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <600308d60508301033589f9f55@mail.gmail.com> Date: Tue, 30 Aug 2005 19:33:27 +0200 From: Francisco Ballesteros To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] Re: some Plan9 related ideas In-Reply-To: <19450.1125421653@piper.nectar.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <19450.1125421653@piper.nectar.cs.cmu.edu> Topicbox-Message-UUID: 81b26984-ead0-11e9-9d60-3106f5b1d025 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?=20 On 8/30/05, Dave Eckhardt wrote: > > 'Tailcall optimizations' for filesystems with other mounted > > filesystems >=20 > In Plan 9 all mounts are done at the client side, so this > wouldn't be an optimization--it's the only case. >=20 > > * 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. >=20 > 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. >=20 > > 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. >=20 > Collecting or finding somebody else's data on that "if" might > be a good first step. >=20 > Dave Eckhardt >