Re: Section 6.4. Filehandle recovery for Migration or Replication

New Message Reply About this list Date view Thread view Subject view Author view Attachment view

From: Spencer Shepler (shepler@eng.sun.com)
Date: 01/05/00-03:23:42 PM Z 

Message-ID: <3873B65E.C366C81C@eng.sun.com>
Date: Wed, 05 Jan 2000 15:23:42 -0600
From: Spencer Shepler <shepler@eng.sun.com>
Subject: Re: Section 6.4.  Filehandle recovery for Migration or Replication


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.

New Message Reply About this list Date view Thread view Subject view Author view Attachment view

This archive was generated by hypermail 2.1.2 : 03/04/05-01:47:57 AM Z CST