Re: [nfsv4] 3530bis Issue 39: Clarification on renewing sequence IDs

[Trond Myklebust <[e-mail]>]

So, I don't think that SEQ_STATUS_LEASE_MOVED should be the last word on
this process.

SEQ_STATUS_LEASE_MOVED has the same scalability problems that
NFS4ERR_LEASE_MOVED does: if the server is exporting 1000 or so volumes,
and one of them moves, it has to check every time a client sends a
SEQUENCE op (i.e. pretty much every COMPOUND) if that client has
completed its search for the absent volume. Furthermore, it will be
receiving a bunch of new RPC requests as the clients all probe 1000
volumes for the absent one.

NFSv4.1 has solved the problem of callbacks by means of the session
backchannel. Why can't we now solve the problem of LEASE_MOVED by adding
a CB_LEASE_MOVED operation which reports not only that a filesystem is
missing, but also identifies which filesystem (e.g. by including the
fsid)?

Cheers
  Trond

On Sun, 2010-11-07 at 01:04 -0500, [e-mail] wrote:
> I agree with Trond's argument as to seqid, i.e. that you should
> increment the seqid in the case of NFS4ERR_LEASE_MOVED.
> 
> NFS4ERR_LEASE_MOVED was buried at a cross-roads in RFC5661, but there we
> have SEQ_STATUS_LEASE_MOVED so we don't need it.
> 
> If you bury it in RFC3530bis, you do have to have some way to deal with
> the issue of letting the client find out that there is a migrated lease.
> Otherwise, there is an unbounded period in which the new server will not
> hear from the client and the client's open files could be lost.
> 
> The alternative to the monstrous hack would be to require the server to
> simulate a reboot.  The client would see a STALE client or stateid error
> and then he would go through the reclaim sequence for both any migrated
> and non-migrated fs's.   That seems harder to make happen than
> LEASE_MOVED, as monstrous as it is.
>  
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Trond Myklebust
> Sent: Friday, November 05, 2010 9:59 AM
> To: Robert Thurlow
> Cc: NFSv4
> Subject: Re: [nfsv4] 3530bis Issue 39: Clarification on renewing
> sequence IDs
> 
> On Thu, 2010-11-04 at 15:57 -0600, Robert Thurlow wrote:
> > Robert Thurlow wrote:
> > > Hi folks,
> > > 
> > > This is issue 39 from 
> > > http://github.com/loghyr/3530bis/blob/master/tasklist.txt.
> > > 
> > > In implementing NFSv4 migration support, we believe that
> > > MOVED and LEASE_MOVED need to be added to the list of errors
> > > in 8.1.5 which do NOT result in incrementing the open owner
> > > or lock owner sequence ID.  The goal is to make the sequence
> > > ID readily calculable for both the client and the destination
> > > server after the migration has occurred.
> > > 
> > > On the 3530bis call, this appeared exactly backwards to some
> > > others - that since a completely gross error had not occurred,
> > > we should increment the sequence ID and the client and the
> > > destination server should know to expect that when they interact
> > > after a migration.  I do not know this issue well enough to
> > > properly defend a position, so please reply with your reasoned
> > > opinion :-)
> > 
> > I don't think this has had a response.  If you disagree with
> > the wording change, now is the time to say so.
> 
> As stated on the confcall, I strongly disagree with this change w.r.t.
> NFS4ERR_LEASE_MOVED. The operation that resulted in a
> NFS4ERR_LEASE_MOVED cannot be safely replayed if the sequence id has not
> been bumped.
> 
> The point is that NFS4ERR_LEASE_MOVED is an error that depends on the
> state of a _different_ filesystem. It does not even pertain to the
> actual state you are trying to modify (and is a monstrous hack). Worse
> yet, that error condition can be cleared at any time with no
> consequences for the stateids held by the client, so unlike
> NFS4ERR_BAD_STATEID or NFS4ERR_BAD_SEQID, there is no ordering w.r.t.
> the operation that you are retrying.
> 
> IOW: if the error condition happens to get cleared between two replays
> of the operation, the client may end up getting 2 conflicting replies
> (one NFS4ERR_LEASE_MOVED, the other being a change of state on the
> server). Which one does it choose?
> 
> So how about counter-proposal: we bury NFS4ERR_LEASE_MOVED at a
> cross-roads with a stake through its heart, and promise never to mention
> it again except when the kids need scaring to bed...
> 
> Trond
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4
> 

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
[e-mail]
www.netapp.com