From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Eckhardt To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <19449.1125421653.1@piper.nectar.cs.cmu.edu> Date: Tue, 30 Aug 2005 13:07:33 -0400 Message-ID: <19450.1125421653@piper.nectar.cs.cmu.edu> Subject: [9fans] Re: some Plan9 related ideas Topicbox-Message-UUID: 81ac8fbe-ead0-11e9-9d60-3106f5b1d025 > '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