From: Noveck, Dave (dave.noveck@netapp.com)
Date: 01/05/00-04:54:01 PM Z
Message-ID: <4080CE03B682D311B589009027C2286638D400@tahoe.corp.netapp.com> From: "Noveck, Dave" <dave.noveck@netapp.com> Subject: RE: Section 6.4. Filehandle recovery for Migration or Replicatio n Date: Wed, 5 Jan 2000 14:54:01 -0800 > > From: "Noveck, Dave" <dave.noveck@netapp.com> > > To: "'nfsv4-wg@sunroof.eng.sun.com'" <nfsv4-wg@sunroof.eng.sun.com> > > Subject: Section 6.4. Filehandle recovery for Migration or > Replication > > 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. > > The above paragraph should be struck, because it conflicts with > the intent of FH3_VOL_MIGRATION bit. > > > 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 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. Right now the spec says that FH4_VOLATILE_MIGRATION says the filehandle "may expire during file system migration". If the intent is that it "will expire", then we should say that. For FH4_VOLATILE_ANY, we may want to add something about always expiring at migration or simply allow FH4_VOL_MIGRATION to be set even if FH4_VOLATILE_ANY is set. > > 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. Right, but in that case the client is responsible for recognizing that expiration has happened and is not depending on the server to tell him. So, it seems that v4 should handle this the same way.
This archive was generated by hypermail 2.1.2 : 03/04/05-01:47:58 AM Z CST