On Tue, Apr 21, 2009 at 1:19 AM, roger peppe <rogpe...@gmail.com> wrote:
> 2009/4/20 andrey mirtchovski <mirtchov...@gmail.com>: > >> with 9p, this takes a number of walks... > > > > shouldn't that be just one walk? > > > > % ramfs -D > > ... > > % mkdir -p /tmp/one/two/three/four/five/six > > ... > > % cd /tmp/one/two/three/four/five/six > > ramfs 640160:<-Twalk tag 18 fid 1110 newfid 548 nwname 6 0:one 1:two > > 2:three 3:four 4:five 5:six > > ramfs 640160:->Rwalk tag 18 nwqid 6 0:(0000000000000001 0 d) > > 1:(0000000000000002 0 d) 2:(0000000000000003 0 d) 3:(0000000000000004 > > 0 d) 4:(0000000000000005 0 d) 5:(0000000000000006 0 d) > > that depends if it's been gated through exportfs or not > (exportfs only walks one step at a time, regardless of > the incoming walk) > > i'm sure something like this has been discussed before, > and this idea somewhat half-baked, but one could get > quite a long way by allowing the notion of a sequence > of related 9p actions - if one action fails, then all subsequent > actions are discarded. > > one difficulty with using multiple concurrent requests > with 9p as it stands is that there's no way to force > the server to process them sequentially. fcp works > because the reads it sends can execute out of order > without changing the semantics, but this only works > on conventional files. > > suppose all 9p Tmsgs were given an sid (sequence id) > field. a new 9p message, Tsequence, would start > a sequence; subsequent messages with the same sid > would be added to a server-side queue for that sequence > rather than being executed immediately. > > the server would move sequentially through the queue, > executing actions and sending each reply when complete. > the sequence would abort when one of: > a) an Rerror is sent > b) a write returned less than the number of bytes written > c) a read returned less than the number of bytes requested. > > this mechanism would allow a client to "program" a set of > actions to perform sequentially on the server without > having to wait for each reply in turn, i.e. avoiding the > usual 9p latency. > > some use cases: > > the currently rather complex definition of Twalk could > be replaced by clone and walk1 instead, as > in the original 9p: {Tclone, Twalk, Twalk, ...} > > {Twrite, Tread} gives a RPC-style request - no need > for venti to use its own protocol (which i assume was invented > largely because of the latency inherent in doing two > separate 9p requests where one would do). > > streaming - send several speculative requests, and keep > adding a request to the sequence when a reply arrives. > still probably not as good as straight streaming TCP, > but easier than fcp and more general. > > there are probably lots of reasons why this couldn't > work, but i can't think of any right now... > Roger... this sounds pretty promising. 10p? I'd hate to call it 9p++.