Subject: [nfsv4] Semantics of mandatory byte-range locking

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 12 Sep 2006 12:25:59 -0400

So I have a question about people's interpretation of the semantics of
mandatory byte-range locking in RFC3530.  The existing text is ambiguous
on some points and I'd like to see if there is a consensus on what it
does/should mean.  Of course, I would expect that to affect what we
write in the v4.1 draft but that isn't the main focus of my question.  I
really want to see if there is a common interpretation for RFC3530.
 
So the ambiguity arises because in some places the stateid is presented
as a shorthad way of indicating the owner or owners making a request and
in other places as designating a specific set of locks and there are
case where these two different ways of thinking about stateid's lead to
different results.  Here's an example.
 
Openowner O1 opens file F for write and gets stateid S(O1).  Openowner
O2 opens file F for write and gets state stateid S(O2).
 
Lockowner L gets an exclusive lock on range 0-999 presenting S(O1) and
getting back S(L1).
 
Lockowner L gets an exclusive lock on range 1000-1999 presenting S(O2)
and getting back S(L2).
 
Now a write is done to byte 0 of the file and the stateid is S(L2).
What happens?
 
a) The write is accepted because the stateid indicates that the open is
O2 (an open for write so OK) and the lockowner is L (so the owner has a
lock for the byte-range in question), and so everything is OK.
 
b) The write is rejected because the set of locks denoted by S(L2) do
not include the lock for the range 0-999, thus making that lock a
conflicting lock which prevents the write from being acted on.
 
I'm interested in all opinions on this but I'm going to give particular
attention to comments like "I implemented x) on my server" and "I have a
client that depends on the server doing x)".
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4