Subject: RE: Section 6.4. Filehandle recovery for Migration or Replicatio n

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 5 Jan 2000 13:51:13 -0800

>   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?

I'm proposing that the should not be presented to the new server
because the server may not be prepared to recognize them as
invalid, expired or anything else.  I'm supposing that the
client will look up the new file handles as if he had gotten
FHEXPIRED from the new server, without requiring the server
to actually return that.

> 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.

Right.

>   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 don't see that this would prevent that from working.  It would
force an extra filehandle expiration when switchover occurred.
In your scheme that wouldn't be required.

I was thinking more of a different case, in which you took what
were normally persistent filehandles and tried to accomodate 
read-only replication on top of the existing file system.  The
files would be marked as volatile only because they expire at
migration.

In that situation, two files with the same name would have very
different file handles when migrated and you are going to 
want to force expiration on switchover so that you use the 
names to find the new filehandles.  In this case, the issue
is whether the servers have to agree on some elements of
the interpretation of filehandles unless the client is 
allowed to assume that expiration occurred without getting
the FHEXPIRED error from the new server.

>   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.

You could do that.

>   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?

Don't know.  Based on the overwhelming lack of response so far,
maybe this isn't needed.  Personally, volatile filehandles,
cause a strong allergic reaction.