Subject: RE: questions/comments on draft-ietf-nfsv4-rfc3010bis-02-04.txt

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 21 Aug 2002 11:48:17 -0700

> Regarding,
> 
>    The server must be able to distinguish the following situations and
>    return the error as specified:
> 
>    o    The stateid was generated by an earlier server instance (i.e.
>         before a server reboot).  The error NFS4ERR_STALE_STATEID should
>         be returned.
> 
>    o    The stateid was generated by the current server instance but the
>         stateid no longer designates the current locking state for the
>         lockowner-file pair in question (i.e. one or more locking
>         operations has occurred).  The error NFS4ERR_OLD_STATEID should
>         be returned.
> 
>         This error condition will only occur when the client issues a
>         locking request which changes a stateid while an I/O request
>         that uses that stateid is outstanding.
>
> So which op, the I/O or the locking op gets the error?

The IO, if it was issued with the then-current stateid and is processed by
the server after the locking op has changed the stateid.

> And why should any error be returned at all?

The error is returned because the stateid passed is incorrect.

An example of where this is valuable is the case in which you have a lock,
and are doing a WRITE, which is retransmitted, one or more times.  Once
you get back the reply to the WRITE (one of them anyway), you issue a
LOCKU, while there might be other instances of the WRITE in the network.
If it is a bad thing to process those laggard writes following the LOCKU
(and maybe a LOCK from someone else) that you'd like to protect against,
and I think it is, then returning OLD_STATEID in this case provides exactly 
that protection.

---

From: Mike Eisler <[email-masked]>
Date: Wed, 21 Aug 2002 16:21:42 -0700

> and I think it is, then returning OLD_STATEID in this case provides exactly

Interesting. This seems to take us down the slippery slope of
fully sequenced RPC that goes beyond just locking operations.
On the other hand, even with NFSv[23], clients are doing synchronous
IO when advisory locking is on, so there is already an expectation
of reduced IO throughput when locking is enabled.

Still, in the past, we've relied on the duplicate request
cache to catch dangling writes, and operational experience
for the past 15 years or so says it works fine.
I think returning _OLD_STATEID on
an I/O ought to be a server implemention choice.

	-mre