Re: [nfsv4] Review of 3530bis "Multi-Server Namespace" Chapter

[Spencer Shepler <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Trond Myklebust
> Sent: Thursday, October 21, 2010 12:28 PM
> To: James Lentini
> Cc: Robert Thurlow; [e-mail]
> Subject: Re: [nfsv4] Review of 3530bis "Multi-Server Namespace" Chapter
> 
> On Thu, 2010-10-21 at 15:07 -0400, James Lentini wrote:
> >
> > On Wed, 13 Oct 2010, Thomas Haynes wrote:
> >
> > > Rob and Dave,
> > >
> > > There is a question for each of you below.
> > >
> > >
> > > On Sep 22, 2010, at 6:31 PM, James Lentini wrote:
> > >
> > <snip>
> > >
> > >       For the write-verifier class in Section 7.7.7, Section 7.9.1
> > >       recommends assuming file system instances are of a different
> > >       class in the case of a failover. Is there a recommendation for
> > >       the NFS4ERR_MOVED case? I realize that the recommendations in
> >             ^^^^^^^^^^^^^
> >             referral
> >
> >
> > To clarify my question: Is there a recommendation for the
> > write-verifier class in the referral case?
> >
> > The "general" rules for the handle class, fileid class, and change
> > class cover the replication, migration, and referral cases. Since
> > those rules immediately precede the write-verifier rules, the omission
> > of a referral case jumped out at me.
> >
> > I expect the recommendation would be for the client to treat the
> > referral source and referral target as being in different
> > write-verifier classes given that the write-verifier class doesn't
> > apply to the referral case, but the text doesn't say that.
> 
> Given that a referral takes you from one filesystem to a different
> filesystem, it seems to me that you cannot possibly find yourself in the
> situation described in RFC5661 Section 11.7.8.
> 
> Write verifier equivalence is really only relevant if you are talking
> about something like the following type of server: a clustered filesystem
> which is such that a write to a file on one cluster node is atomically
> written to some kind of shared page cache and is guaranteed not to get
> lost if that node crashes/reboots.
> In that case, you can access the file through one of the other nodes,
> issue the COMMIT, and Bob's your uncle...

Could an example be a multi-homed server that is migrating
clients from one interface to another for either load-balancing
or a scheduled service window?

Spencer