Re: [9fans] 9P to 9P2000 migration path

Re: [9fans] 9P to 9P2000 migration path

[jmk]

On Mon Jan 29 00:20:33 EST 2001, cross@math.psu.edu wrote:
> In article <20010128192407.7C8F3199EF@mail.cse.psu.edu> you write:
> >That sort of thing.
> >
> >The necessary hooks for protocol versioning is provided by the
> >"version" message.
>
> I'm guessing it's easy for a file server to detect an old protocol
> client (Tversion won't be the first message sent from an old 9p client,
> as old 9p doesn't have Tversion.  Any connection starting out this way
> won't be the new protocol).
>
> I was reading the file server paper again today while I was on the
> train, and one thing I noticed is that the disk-resident directory
> entry contains the 28 byte file name in a fixed width field.  It would
> seem that if the restriction on file name length is being removed from
> the protocol, a similar change must be taking place in the file
> server.  If this is the case, then the question becomes, ``how does one
> migrate data off of disk on an old file server and onto a new one?''
> Also, if the disk resident data structure is changing, is this a good
> time to move the length field to a vlong?
>
> 	- Dan C.
>

Yes, the disc-resident directory structure will change. I have a 4-step
or so plan on how to do this, of which I've implemented step 1 (I'm probably
in trouble because I haven't done any work on steps 2-4 for the past month).
The new structure will have a 64-bit length field.

I'd say more but some parts are still in flux.

--jim

Re: [9fans] 9P to 9P2000 migration path

[Dan Cross]

In article <20010202013127.9CEED199D5@mail.cse.psu.edu> you write:
>Yes, the disc-resident directory structure will change. I have a 4-step
>or so plan on how to do this, of which I've implemented step 1 (I'm probably
>in trouble because I haven't done any work on steps 2-4 for the past month).
>The new structure will have a 64-bit length field.
>
>I'd say more but some parts are still in flux.

If this is the case, then one suggestion is to reserve 32 bits after
each timestamp on disk.  Then, should it ever come to pass that times
change to 64 bit integers, one needn't change the layout of data on
disk except to start using those 32 bits....

	- Dan C.

Re: [9fans] 9P to 9P2000 migration path

[Dan Cross]

In article <20010128192407.7C8F3199EF@mail.cse.psu.edu> you write:
>That sort of thing.
>
>The necessary hooks for protocol versioning is provided by the
>"version" message.

I'm guessing it's easy for a file server to detect an old protocol
client (Tversion won't be the first message sent from an old 9p client,
as old 9p doesn't have Tversion.  Any connection starting out this way
won't be the new protocol).

I was reading the file server paper again today while I was on the
train, and one thing I noticed is that the disk-resident directory
entry contains the 28 byte file name in a fixed width field.  It would
seem that if the restriction on file name length is being removed from
the protocol, a similar change must be taking place in the file
server.  If this is the case, then the question becomes, ``how does one
migrate data off of disk on an old file server and onto a new one?''
Also, if the disk resident data structure is changing, is this a good
time to move the length field to a vlong?

	- Dan C.

Re: [9fans] 9P to 9P2000 migration path

[rob pike]

> What is the migration strategy for 9P to 9P2000? Is
> there consideration given to operating a network in
> mixed mode (9P/9P2000) and what it would take to
> do so? Is there a provision for protocol versioning?

A great deal of agonizing and very little decisiveness went into
resolving this issue.  The current situation is to have the physical
(main, worm-based) file servers honor both protocols, but to have the
CPU and terminal kernels talk only the new one (and of course
old ones talk only the old one).  Thus both old and new
systems can coexist.  We have a program that can be interposed into a
conversation to let a new kernel talk to an old service, but
translating client new protocol to server old protocol.  This is
sufficient, for example, to let the new kernel boot from the existing
binary of disk/kfs.  Over time, we will translate the applications to
use the new protocol only.

That sort of thing.

The necessary hooks for protocol versioning is provided by the
"version" message.

-rob

[9fans] 9P to 9P2000 migration path

[Fariborz 'Skip' Tavakkolian]

This is great news; Thanks for including us early
on this. There is always a risk of getting bogus
feedback because the nuances may be missed.
The next question may be one of those :-)

What is the migration strategy for 9P to 9P2000? Is
there consideration given to operating a network in
mixed mode (9P/9P2000) and what it would take to
do so? Is there a provision for protocol versioning?

Thanks.