Subject: Re: Section 6.4. Filehandle recovery for Migration or Replication

From: Spencer Shepler <[email-masked]>
Date: Wed, 05 Jan 2000 15:23:42 -0600

Dave,
  So based on your comments below, you are proposing that
in the event of a migration or replication event volatile 
filehandles will be invalid when presented to the new server?
This approach, you state, will avoid the problem the new server
will have in providing the correct FHEXPIRED error to the
client when the old volatile filehandle is presented to the
new server.
  This approach will disallow a server from providing volatile
filehandles in the read-only replication case.  I can imagine
that a set of servers could provide read-only service to a
file system while using volatile filehandles.  The server may
be implemented to use the pathname as the volatile filehandle
and assuming that the servers are the same implementation
and the same filesystem name space is being presented, volatile
filehandles can be used.
  I agree that there is an issue with a client presenting an
old filehandle and the server not being able to provide the
correct error (FHEXPIRED or STALE).  There may be a method
to extend the fh_expire_type attribute to let the client know
if the server can provide the correct interpretation of the
volatile filehandle or if the client should consider the
volatile filehandle invalid on the migration/replication event.
  Is it worth the effort to do this or do we believe that in the case
where servers know about and will transfer the filehandle 
contents that persistent filehandles will be used?

Spencer

"Noveck, Dave" wrote:
> 
> 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.

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 05 Jan 2000 15:46:40 -0600

On second thought....

Let's take your suggestion Dave and state that for volatile
filehandles during a migration or replication event, the
filehandle is considered to be invalid or to have expired
on the m/r event.  In the future, if it is found that there
are server implementations that provide the correct volatile
filehandle transition, then we can use minor versioning to
extend the fh_expire_type attribute definition to include
the new/extended semantics.

This implies that the FH_VOL_MIGRATION bit of fh_expire_type
should be removed.

Thoughts?

Spencer

---

From: Mike Eisler <[email-masked]>
Date: Wed, 5 Jan 2000 14:12:10 -0800 (PST)

> From: "Noveck, Dave" <[email-masked]>
> To: "[email-masked]'" <[email-masked]>
> Subject: Section 6.4.  Filehandle recovery for Migration or Replication
> Date: Tue, 28 Dec 1999 14:23:35 -0800
[...]
>    presented; the client will need to recover the filehandles

The above paragraph should be struck, because it conflicts with 
the intent of FH3_VOL_MIGRATION bit.
 
> and the format of filehandles has got to be one of them.

I beleive the current specification covers this.
The FH4_VOL_MIGRATION bit in the mandatory  fh_expire_type is
the way that the server tells the client whether the file handle is good
through a migration. If FH4_VOL_MIGRATION or FH4_VOLATILE_ANY are set,
the client knows it must not expect the file handle to work after
a migration.

Two server's don't have to agree on the format of file handles to allow
migration when volatile file handles are used. The NFS client side failover
feature of Solaris 2.6 and onward proves this.

> Date: Wed, 05 Jan 2000 15:46:40 -0600
> From: Spencer Shepler <[email-masked]>
[...]
> This implies that the FH_VOL_MIGRATION bit of fh_expire_type

Well, we spent lots of time getting to the current FH4_* set of bits,
and I expect that if FH_VOL_MIGRATION is removed now, we'll simply
cover old ground. To summarize that old ground, FH_VOL_MIGRATION is
needed mostly to hande the case when two servers each support persistent
file handles, but during a migration, persistence is lost.