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

From: [email-masked]
Date: Tue, 12 Sep 2006 16:25:42 -0400 (EDT)

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

I implemented b) on my server, but believe that a) is actually more
appropriate. (ie. compare "L" the lockowner for equality and not care
which stateid associated with "L" is used.) I coded this so long ago I have
no idea why I chose "a)".

As you might have guessed, I coded mandatory locking as an option in my
server and it hasn't really been tested.

rick

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Peter Varga <[email-masked]>
Date: Wed, 13 Sep 2006 09:08:56 -0400

Our server implements b).
 
The reason is that open and lock owners were distinguished in the first
place in order to support POSIX clients, in the sense that they need
different lock owners under the same open owner. Our code follows this
logic.
 
The main purpose of open/lock owners are to establish locks; if the lock
owner is the same, why have different open owners?
 
Peter

-----Original Message-----
From: Noveck, Dave [mailto:[email-masked]] 
Sent: Tuesday, September 12, 2006 12:26 PM
To: [email-masked]
Subject: [nfsv4] Semantics of mandatory byte-range locking

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.