OP_LOCK4: question about open_to_lock_owner4::lock_seqid

[J. Bruce Fields]

On Thu, Jul 03, 2008 at 11:14:33AM -0400, Rick Macklem wrote:
> [good stuff snipped]
> > My opinion is that clients should send 0, and servers should ignore it.
> > The linux server currently ignores it (and I run newpynfs with
> > noLOCK8C....).
> > 
> > This was discussed before (google for "relax new lock seqid check") but
> > I can't find a definitive conclusion.
> 
> One minor nit Bruce. If the server chooses to accept a non zero initial value
> for lock_seqid, it sets the initial lock_seqid to that value instead of 0.
> (So, it ignores it for the test, but uses it for the initial value, I think?)
> 
> I vaguely recall that at least one client out there uses non-zero initial
> values, but I'm not sure.

I remember catching some bugs in the linux client when it accidentally
failed to initialize its seqid in some cases (on state recovery, I
think?) but that's the only case I recall.

It looks from the discussion like the AIX server does enforce the
requirement that the initial seqid be zero.

--b.

> Note also, that lock_seqid has nothing to do with lock_stateid.seqid (the one
> in the lock stateid). There have been several threads on the ietf mailing list
> for nfsv4 on what to do with the lock_stateid.seqid and it changes for 4.1.
> (For 4.0, I believe the client always considers it opaque and replies with
>  whatever the server sent, so the server has some flexibility w.r.t. what it
>  does. Generally, the server is to increment it each time the state associated
>  with the stateid changes. A server can reply NFS4ERR_OLD_STATEID if it gets
>  a lock_stateid.seqid that is not the current value, but that seemed to cause
>  unnecessary grief for some clients, so I believe most servers no longer bother
>  to do that, at least for the Read, Write, Setattr Ops cases.)