From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <14ec7b180904201428v1fc0845ayb042b6aa628e17cc@mail.gmail.com> References: <5d375e920904200758m1a1a96den579673e107b57b19@mail.gmail.com> <7c22175ab60f8a5ae2cf894d462b29e5@9netics.com> <3e1162e60904201118u18e8846bkbfec62e561a15a91@mail.gmail.com> <3e1162e60904201155l2b29c0b7ge248c36f82f7324@mail.gmail.com> <3e1162e60904201317v4d50be85x4597a1a6a3123959@mail.gmail.com> <3e1162e60904201418g54ba56f4pbf8fc31bf95a9d81@mail.gmail.com> <14ec7b180904201428v1fc0845ayb042b6aa628e17cc@mail.gmail.com> Date: Tue, 21 Apr 2009 09:19:47 +0100 Message-ID: From: roger peppe To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Plan9 - the next 20 years Topicbox-Message-UUID: ec480d7c-ead4-11e9-9d60-3106f5b1d025 2009/4/20 andrey mirtchovski : >> 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...