2009/4/20 andrey mirtchovski <mirtchovski@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...