Precisions wanted on OP_WRITE with a stateid whose bits are all set to zero

[J. Bruce Fields]

On Tue, Jul 15, 2008 at 04:03:39PM +0200, DENIEL Philippe wrote:
> Hi to all,
> 
> in RFC3530, on page 220-221 (describing OP_WRITE4), I can see
> 
>      For a WRITE with a stateid value of all bits 0, the server MAY allow
>        the WRITE to be serviced subject to mandatory file locks or the
>        current share deny modes for the file.  For a WRITE with a stateid
> 
>     --- (page 221 begins here)
> 
>        value of all bits 1, the server MUST NOT allow the WRITE operation to
>        bypass locking checks at the server and are treated exactly the same
>        as if a stateid of all bits 0 were used.

Note you may want to search through the spec for other occurrences of
"all bits"--other places have a more complete explanation.

> Are NFSv4 clients from the linux kernel subject to perform WRITE with 
> such 'all 0' or 'all 1' stateids ? (I am running a Fedora 9 with updated 
> kernel 2.6.25.9-76 as client).
> The situation is a bit confusing to me: should a 'all 0 stateid' write 
> bypass all locks and shares or just locks and respect shares.

My understanding:

Ordinary advisory locks never have any affect on read or write.

*Mandatory* locks and share reservations are always respected, and IO
with the special (all-0 or all-1) stateid's never bypasses them, with
one single exception: the server may optionally allow a READ with an
all-1's stateid to bypass mandatory locks and share reservations.

> I do not 
> clearly understand the difference between a 'all 1' stateid and a 'all 
> 0' stateid as well. Should these special values mean that the last 
> stateid (the one from the last OP_OPEN) is to be used instead, this 
> value would be kind of "jokers" ?

No.  The all-1 or all-0 IO operations are treated as if the caller held
no locks at all.

The only difference between all-1 and all-0 is as above: READs with
all-1 stateid's may optionally be allowed to bypass mandatory locks and
share reservations, and the same isn't true in the all-0 case.

--b.

> 
> Thank you for helping me, I feel a bit lost on this point (in fact I 
> discovered that in the 'all 0 stateid case', my server systematically 
> return 10023 aka NFS4ERR_STALE_STATEID which is clearly a very bad idea: 
> the client loops on the OP_WRITE and the only way to put the NFSv4 
> client in a correct state again is to reboot it....)
> 
>     Philippe
> _______________________________________________
> NFSv4 mailing list
> NFSv4 at linux-nfs.org
> http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4