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

[Trond Myklebust <[e-mail]>]

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

Cheers
  Trond