From mboxrd@z Thu Jan  1 00:00:00 1970
From: jmk@plan9.bell-labs.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] 9P to 9P2000 migration path
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Message-Id: <20010202013127.9CEED199D5@mail.cse.psu.edu>
Date: Thu,  1 Feb 2001 20:31:24 -0500
Topicbox-Message-UUID: 564e0962-eac9-11e9-9e20-41e7f4b1d025

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