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++.
