Subject: RE: Minutes from nfsv4 WG meeting @ 52nd IETF (Salt Lake City)

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 9 Jan 2002 12:16:05 -0800

Unless I'm missing something, it seems your approach would
deal with renames that happened after the migration event,
but be exposed to the effects of renames of open files
that happened before the migration event.

Suppose I open A.  Get back handle X and stateid S.

Another client renames A to be B and renames C to be
A.

Migration.  Client references A using handle X and gets
NFS4ERR_MOVED.  He then gets the new location of the fs.

Client has prevously determined that the handles for
the fs are volatile on migration so he doesn't use
them.  Instead ...

He does a lookup of A.  He gets handle Y, which does not
designate the same file as was designated by handle X
before (because of the renames).

He then does an open claim-previous specifying Y and
gets back stateid T.  Everything is great except he has
wrong file opened.

The reason that open claim-previous takes a handle rather 
than a directory handle and a filename is to avoid the
problem of connecting to the wrong files when renames
occur.  Since we would have to get the new handle using 
the unreliable name, re-opening after migration would be
exposed to that very problem.

I think some sort of grace period is essential to make this
problem tractable, but I believe that you need some sort
of mapping facility that allows the client to convert 
old handles to new ones, without depending on name lookup,
which may do the wrong thing, from the client's point of
view.

-----Original Message-----
From: Brent Callaghan [mailto:[email-masked]]
Sent: Tuesday, January 08, 2002 9:04 PM
To: [email-masked]
Subject: Re: Minutes from nfsv4 WG meeting @ 52nd IETF (Salt Lake City)

"Noveck, Dave" wrote:
> 
> 
> > Brian Carpenter questioned the interest in this work given
> > the low turnout at the WG meeting.  Brian Pawlowski pointed
> > out that the meeting did not represent those on the mailing
> > list, and suggested that Rob solicit mailing list
> > participants to help with replication/migration work.
> > Brian Carpenter asked about support in the NFSv4 protocol
> > to handle a replication/migration event, e.g. what happens
> > to filehandles?  Brian Pawlowski responded that this support
> > has already been designed into the protocol.
> 
> The matter is addressed but what is in V4 is probably not
> adequate for use by disparate servers participating in filesystem
> migration using this protocol.  If something else is needed,
> it could be added in a minor version of V4.
> 
> If the filehandles are persistent, the current model is that
> they stay the same upon migration.  This was intended for
> migration among homogeneous servers using a private protocol
> and agreeing among themselves on the format of handles.
> 
> This isn't a very good fit for heterogenous migration.  The
> only way to use it would be for all participating servers to
> agree on an initial unique id at the front of all handles subject
> to migration and then maintaining mapping table so that the new
> server can respond to old handles using the unqiue id in front
> to recognize old handles.  This table would have to be persistent
> and maintained as long as the old handles were considered valid.
> 
> Another option are handles that are volatile at migration.  This
> has the basic problem that rebinding to expired volatile handles
> is name-based and that there are situations in whch the client
> doesn't know the current name of the file.  He might be unable
> to find a file that has the name he knows or he might find one
> which is not the file he had opened.  That makes migration something
> that may or may not work from the applicaion point of view, rather
> than something that can be relied on.

Though hopefully a migration event will be more controlled than
the open slather of a fully volatile server operating continuously.
The filehandles need be "volatile" only for the duration of migration.

So, for instance, the migration servers could apply a "grace"
period that gives clients a chance to replay pathnames and
acquire new filehandles when the migration is complete.

Still no absolute guarantee of safety - but it's close.

	Brent

---

From: Brent Callaghan <[email-masked]>
Date: Wed, 09 Jan 2002 14:17:24 -0800

> NFS4ERR_MOVED.  He then gets the new location of the fs.

How about a grace period that freezes name changes
before the migration event ?

> which may do the wrong thing, from the client's point of

I'd prefer we find a way to avoid mapping tables.  A mapping
table has the potential to be huge, expensive to create, 
and it has to be kept somwhere.  It could turn into another
.nfsxxx problem.

Still hoping we can come up with a migration/replication
protocol that's popular independently of NFSv4.

	Brent