OP_LOCK4: question about open_to_lock_owner4::lock_seqid

[Rick Macklem]

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

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

rick