Subject: Section 6.4. Filehandle recovery for Migration or Replication

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 28 Dec 1999 14:23:35 -0800

I'm wondering whether the second paragraph of this section
is really what we want to say.  Right now, it says:

   The same is true for a file system which is made up of volatile
   filehandles.  In fact, in this case the client should expect that the
   new server will return NFS4ERR_FHEXPIRED when old filehandles are
   presented; the client will need to recover the filehandles
   appropriately.

This formulation places on the new server the responsibility of
recognizing handles generated by the old server, at least to the
point of reporting FHEXPIRED.  Normally, a server creates
filehandles and it is the only one who needs to understand 
their format.

Clearly, migration in the case of persistent filehandles has
got to be an exception to this.  In that case, two servers have
got to agree on lots of things (all outside the scope of nfs v4)
and the format of filehandles has got to be one of them.

I hadn't expected that those using volatile filehandles and 
particularly those doing replication using volatile filehandles
would be prepared for the same degree of integration.

As this paragraph is now written, if two servers which are
provided a replicated file system are using the volatile form 
of filehandles layed out in section 4.2.4, they would have to,

     Precisly agree on the position of the boot time field.

     Agree on the interpretation of the boot time field.

     Take special measures to make sure that two servers
     involved in replication do not have the same boot time
     value.

If some of these weren't done, a secondary server might think
that a filehandle generated by a primary was non-expired with
unpleasant results.  Servers could avoid this in other ways
such as perpending a server-id to the filehandle to create a
global handle space, but this all involves at least some level
of agreement among the servers about the form of filehandles.

I had originally intended something a little different.  I was
thinking that at the time of migration or replication-associated
retargetting, volatile filehandles would expire as part of the
transfer, obviating any need for the new server to recognize 
handles generated by an old one, unless the servers signed up 
for that complexity by using migration together with persistent
filehandles.

I think what is written there now can be made to work but I'm
wondering whether replication would be more useful if it had
an implementation that involved less inter-server co-ordination.
I don't think that making this change would significantly
add to client complexity.