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

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: nfsv4-bounces@ietf.org [mailto:nfsv4-bounces@ietf.org] 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
nfsv4@ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4