[9fans] 9p2010

[9fans] 9p2010

[erik quanstrom]

it occurred to me yesterday morning that the problem with
a bundle of 9p requests is that 9p then no longer maps directly
to system calls.

with 9p2000, if you want to do a Tread, it's pretty clear that
one needs to read(2); traditiona syscalls map directly to 9p.

not so when bundles/sequences are introduced.  how does a
user program generate an arbitrary bundle?  can programs
use bundles at all without being rewritten?

- erik

Re: [9fans] 9p2010

[roger peppe]

2009/4/23 erik quanstrom <quanstro@quanstro.net>:
> it occurred to me yesterday morning that the problem with
> a bundle of 9p requests is that 9p then no longer maps directly
> to system calls.
>
> with 9p2000, if you want to do a Tread, it's pretty clear that
> one needs to read(2); traditiona syscalls map directly to 9p.

true, but it is a one-to-many mapping - for instance, a single call to
open may generate an arbitrary number of 9p messages.

> not so when bundles/sequences are introduced.  how does a
> user program generate an arbitrary bundle?  can programs
> use bundles at all without being rewritten?

this is an interesting question.

as a starting point, i'd envisaged simply changing the existing
system calls to do sequences.

in inferno, where it's easy to add system calls, it would be
straightforward, i think, to add some additional system-level primitives,
(e.g. readfile) that took advantage of sequencing.
but that is cheating really - ideally you'd want a user-level
interface to this functionality.

the difficulty with creating the interface is that a 9p call
must be separated into two parts - the sending of the
parameters and the retrieving of the results.

for a low level 9p interface, i'd imagined something like
the following interface (in pseudo limbo):

Sequence: adt {
	queue: fn(seq: self ref Sequence, m: Tmsg, tag: any);
	wait: fn(seq: self ref Sequence): (any, Tmsg, Rmsg);
	cont: fn(seq: self ref Sequence);
	flush: fn(seq: self ref Sequence);
}

queue adds a new message to the sequence (with an arbitrary
tag to attach to the result of the call). wait waits for the next
reply to come in and returns the tag, the originating tmsg and the
reply. cont continues executing a sequence after it has
been aborted due to error (this will resend tmsgs). flush aborts
the sequence.

so this is ok when dealing with 9p or the dev interface directly, but
won't work so well
with higher level calls. it would be nice for a user-level program to
be able to string together an arbitrary sequence of system calls
into a sequence, but i'm not sure what a decent interface would look like.
(something like the above Sequence adt, but with a system call description
instead of Tmsg and a system call result instead of Rmsg, perhaps,
although it's not clear what a "system call description" would look like,
or how easy it would be to split system calls)

the control flow is not straightforward (or perhaps it is - it's the kind
of thing that might just have a nice elegant solution lurking there somewhere).

something to think about.

Re: [9fans] 9p2010

[erik quanstrom]

> as a starting point, i'd envisaged simply changing the existing
> system calls to do sequences.
>
[...]
>
> Sequence: adt {
> 	queue: fn(seq: self ref Sequence, m: Tmsg, tag: any);
> 	wait: fn(seq: self ref Sequence): (any, Tmsg, Rmsg);
> 	cont: fn(seq: self ref Sequence);
> 	flush: fn(seq: self ref Sequence);
> }

this is significantly more complicated than syscalls.

- erik

Re: [9fans] 9p2010

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 954 bytes --]

On Thu, Apr 23, 2009 at 10:28 AM, erik quanstrom <quanstro@quanstro.net>wrote:

> > as a starting point, i'd envisaged simply changing the existing
> > system calls to do sequences.
> >
> [...]
> >
> > Sequence: adt {
> >       queue: fn(seq: self ref Sequence, m: Tmsg, tag: any);
> >       wait: fn(seq: self ref Sequence): (any, Tmsg, Rmsg);
> >       cont: fn(seq: self ref Sequence);
> >       flush: fn(seq: self ref Sequence);
> > }
>
> this is significantly more complicated than syscalls.
>
> - erik
>

Are we doing all of this to defeat the conveniences we get from the
statefulness of 9p?  Would a stateless 9p-like protocol be better (no
walks)?  Is a stateless 9p really HTTP?  :-)

If those are all yeses, are we re-inventing the wheel?  Or does 9p or some
derivative really have to get used everywhere? :-)

I mean if we figure this out, great, but if not, I think we're still ok,
just can't use 9p right?  :-)

[-- Attachment #2: Type: text/html, Size: 1440 bytes --]

Re: [9fans] 9p2010

[Fco. J. Ballesteros]

But if you do that (send sequences from userl-level)
you must interpret your namespace yourself. When I tried to
detect how to bundle calls for plan b, a problem I had was
namec. For me it's still not clear how to detect cleanly
`what to batch', even if you change the source for the
program doing I/O to help there, because of the mount
table.


>  From: rogpeppe@gmail.com
>  To: 9fans@9fans.net
>  Reply-To: 9fans@9fans.net
>  Date: Thu Apr 23 19:26:06 CET 2009
>  Subject: Re: [9fans] 9p2010
>
>  2009/4/23 erik quanstrom <quanstro@quanstro.net>:
>  > it occurred to me yesterday morning that the problem with
>  > a bundle of 9p requests is that 9p then no longer maps directly
>  > to system calls.
>  >
>  > with 9p2000, if you want to do a Tread, it's pretty clear that
>  > one needs to read(2); traditiona syscalls map directly to 9p.
>
>  true, but it is a one-to-many mapping - for instance, a single call to
>  open may generate an arbitrary number of 9p messages.
>
>  > not so when bundles/sequences are introduced.  how does a
>  > user program generate an arbitrary bundle?  can programs
>  > use bundles at all without being rewritten?
>
>  this is an interesting question.
>
>  as a starting point, i'd envisaged simply changing the existing
>  system calls to do sequences.
>
>  in inferno, where it's easy to add system calls, it would be
>  straightforward, i think, to add some additional system-level primitives,
>  (e.g. readfile) that took advantage of sequencing.
>  but that is cheating really - ideally you'd want a user-level
>  interface to this functionality.
>
>  the difficulty with creating the interface is that a 9p call
>  must be separated into two parts - the sending of the
>  parameters and the retrieving of the results.
>
>  for a low level 9p interface, i'd imagined something like
>  the following interface (in pseudo limbo):
>
>  Sequence: adt {
>  	queue: fn(seq: self ref Sequence, m: Tmsg, tag: any);
>  	wait: fn(seq: self ref Sequence): (any, Tmsg, Rmsg);
>  	cont: fn(seq: self ref Sequence);
>  	flush: fn(seq: self ref Sequence);
>  }
>
>  queue adds a new message to the sequence (with an arbitrary
>  tag to attach to the result of the call). wait waits for the next
>  reply to come in and returns the tag, the originating tmsg and the
>  reply. cont continues executing a sequence after it has
>  been aborted due to error (this will resend tmsgs). flush aborts
>  the sequence.
>
>  so this is ok when dealing with 9p or the dev interface directly, but
>  won't work so well
>  with higher level calls. it would be nice for a user-level program to
>  be able to string together an arbitrary sequence of system calls
>  into a sequence, but i'm not sure what a decent interface would look like.
>  (something like the above Sequence adt, but with a system call description
>  instead of Tmsg and a system call result instead of Rmsg, perhaps,
>  although it's not clear what a "system call description" would look like,
>  or how easy it would be to split system calls)
>
>  the control flow is not straightforward (or perhaps it is - it's the kind
>  of thing that might just have a nice elegant solution lurking there somewhere).
>
>  something to think about.

Re: [9fans] 9p2010

[roger peppe]

2009/4/23 Fco. J. Ballesteros <nemo@lsub.org>:
> But if you do that (send sequences from userl-level)
> you must interpret your namespace yourself. When I tried to
> detect how to bundle calls for plan b, a problem I had was
> namec. For me it's still not clear how to detect cleanly
> `what to batch', even if you change the source for the
> program doing I/O to help there, because of the mount
> table.

i guess that the current design of the walk message
shows what can be batched, but i agree, the
mount table is at the core of the issue.

i wonder how many things would break if plan 9 moved to
a strictly name-based mapping for its mount table...

Re: [9fans] 9p2010

[Roman V. Shaposhnik]

On Thu, 2009-04-23 at 18:53 +0100, roger peppe wrote:
> i wonder how many things would break if plan 9 moved to
> a strictly name-based mapping for its mount table...

What exactly do you mean by *strictly* ?

Thanks,
Roman.

Re: [9fans] 9p2010

[roger peppe]

2009/4/26 Roman V. Shaposhnik <rvs@sun.com>:
> On Thu, 2009-04-23 at 18:53 +0100, roger peppe wrote:
>> i wonder how many things would break if plan 9 moved to
>> a strictly name-based mapping for its mount table...
>
> What exactly do you mean by *strictly* ?

i mean using pathnames rather
than using qids. "strictly" because a hybrid
approach may be possible.

doing this would mean that, for instance,

  bind -a /foo/bar /tmp/a
  mv /tmp/a /tmp/b
  ls -l /tmp/b

would not list the contents of /foo/bar.

what else might break?

Re: [9fans] 9p2010

[Eric Van Hensbergen]

Another alternative (maybe this has already been mentioned -- I
haven't been closely following the thread) -- is to integrate the
caching into a cache file system.  That way you get the advantage for
static files (and static file systems) where you have the least
opportunity to shoot yourself in the foot by prefetching or making
assumptions.  No new system calls, no necessary changes to the
libraries.

      -eric


On Thu, Apr 23, 2009 at 12:22 PM, roger peppe <rogpeppe@gmail.com> wrote:
> 2009/4/23 erik quanstrom <quanstro@quanstro.net>:
>> it occurred to me yesterday morning that the problem with
>> a bundle of 9p requests is that 9p then no longer maps directly
>> to system calls.
>>
>> with 9p2000, if you want to do a Tread, it's pretty clear that
>> one needs to read(2); traditiona syscalls map directly to 9p.
>
> true, but it is a one-to-many mapping - for instance, a single call to
> open may generate an arbitrary number of 9p messages.
>
>> not so when bundles/sequences are introduced.  how does a
>> user program generate an arbitrary bundle?  can programs
>> use bundles at all without being rewritten?
>
> this is an interesting question.
>
> as a starting point, i'd envisaged simply changing the existing
> system calls to do sequences.
>
> in inferno, where it's easy to add system calls, it would be
> straightforward, i think, to add some additional system-level primitives,
> (e.g. readfile) that took advantage of sequencing.
> but that is cheating really - ideally you'd want a user-level
> interface to this functionality.
>
> the difficulty with creating the interface is that a 9p call
> must be separated into two parts - the sending of the
> parameters and the retrieving of the results.
>
> for a low level 9p interface, i'd imagined something like
> the following interface (in pseudo limbo):
>
> Sequence: adt {
>        queue: fn(seq: self ref Sequence, m: Tmsg, tag: any);
>        wait: fn(seq: self ref Sequence): (any, Tmsg, Rmsg);
>        cont: fn(seq: self ref Sequence);
>        flush: fn(seq: self ref Sequence);
> }
>
> queue adds a new message to the sequence (with an arbitrary
> tag to attach to the result of the call). wait waits for the next
> reply to come in and returns the tag, the originating tmsg and the
> reply. cont continues executing a sequence after it has
> been aborted due to error (this will resend tmsgs). flush aborts
> the sequence.
>
> so this is ok when dealing with 9p or the dev interface directly, but
> won't work so well
> with higher level calls. it would be nice for a user-level program to
> be able to string together an arbitrary sequence of system calls
> into a sequence, but i'm not sure what a decent interface would look like.
> (something like the above Sequence adt, but with a system call description
> instead of Tmsg and a system call result instead of Rmsg, perhaps,
> although it's not clear what a "system call description" would look like,
> or how easy it would be to split system calls)
>
> the control flow is not straightforward (or perhaps it is - it's the kind
> of thing that might just have a nice elegant solution lurking there somewhere).
>
> something to think about.
>
>

Re: [9fans] 9p2010

[Steve Simon]

> ...integrate the
> caching into a cache file system

this was discussed at one of the iwp9s I believe.

Ok, a thought experiment.

Extend fossil so that you can attach to objects of the form
fs.changes (e.g. main.changes or other.changes). Open a known file
here (e.g. /update) and you will receive a message when any file in
main (or other in the above example) filesystem is modified. The message
should probably be a dirstat structure and a flag indicating weather
the file itself has changed or only the dirstat.

The client could also read from the file /score and would
get a venti score for the watched filesystem every time
a snap is taken.

To allow the system to synchronise after a period of disconnection
the client could write a venti score to /score before opening /update
to indicate that it needs to catch up the changes since this score's
creation.

It would allow cfs to serve up local files with the knowledge that
the remote server contains the same file and so cfs would feel much
mor responsive.

Batched 9p messages would improve the performance further, of course.
You could teach the cache client to use batched 9p from the begining,
and end up with somthing similar to nemo's octopus.

Note, the files I am describing are those served by fossil, so, by
definition they are disk files, and thus they are cacheable.
This is not a solution for virtual files.

I'am sure there are problems with the above, but you get the idea.

-Steve

Re: [9fans] 9p2010

[Gary Wright]

On Apr 23, 2009, at 12:26 PM, erik quanstrom wrote:
> with 9p2000, if you want to do a Tread, it's pretty clear that
> one needs to read(2); traditiona syscalls map directly to 9p.

It seems to me that the syscall interface is by design different than
the 9p2000 api:

- most syscalls map to a sequence of 9p2000 messages (allocate a new
fid, walk to the named resource, open/stat/remove)
- open files are represented by file descriptors, not 9p2000 fids
- file descriptors map to fids in a n -> 1 relationship
- file descriptors maintain a current offset
- other than fids associated with file descriptors, the only other fid
associated with a process is the current working directory (i.e. you
can't cache the result of a Twalk other than via the current working
directory)
- there is no direct access to Twalk
- the semantics of a process namespace is a non-trivial multiplexing
of several 9p2000 namespaces

I was reading through the source of exportfs the other day and it
struck me that there was quite a bit of work involved in mapping
incoming 9p2000 messages into syscalls within the process namespace
(e.g., fids vs file descriptors, qid clashes).