Subject: RE: [nfsv4] Locking Sematics

From: Syam Pannala <[email-masked]>
Date: Tue, 15 Mar 2005 14:09:35 -0800 (PST)

Hi,

My wording was inexact and caused some confusion. Sorry about that.

I am looking to implement mandatory (not advisory) locking on the
server side. In addition, I am only referring to byte range locks (or
record locks) and not share reservations. My understanding of the fcntl
man-page was wrong -- the man page seems to talk only about advisory
locking[see PS].

What I am looking to implement is along the lines of my first model.
That is, NFS V4 READ locks would be considered shared locks. Any number
of lock owners can take a shared lock on a given range. NFS V4 Write
locks would be exclusive -- exactly one lock on a given range and it
would conflict with shared locks also. And WRITE operations would
conflict with both shared(READ) and exclusive(WRITE) locks in the
range. OTOH, READ operations would not conflict with either shared or
exclusive locks and hence will not fail because of locking.

This is very similar to Mike's email below, except the WRITE operation
would also be in the picture. In addition, locking would be mandatory
and not a mount option.

Would such a model have problems with interoperability?

Thanks,
Syam

PS: The phrase from the fcntl man page that I had in mind was

"Any number of processes may hold a read lock (shared lock) on a file
region, but only one process may hold a write lock (exclusive lock). An
exclusive lock excludes all other locks, both shared and exclusive."
[Linux fcntl man page --
http://www.die.net/doc/linux/man/man2/fcntl.2.html ]

--- Mike Eisler <[email-masked]> wrote:
> I interpreted Syam's question to be completely
> about advisory byte range locks, and not Windows style
> share reservations.
> 
> Thus, I think the question boils down to what
> are read and write byte range locks (which RFC 3530
> mostly refers to), and do they have the semantics of
> shared and exclusive locks (which the RFC makes a
> handful of references to). However, the RFC doesn't
> clearly state that read locks are shared locks,
> and write locks are exclusive locks, though one
> can make such an inference from:
> 
>     A lock may not be granted while a READ or WRITE operation using
> one
>     of the special stateids is being performed and the range of the
> lock
>     request conflicts with the range of the READ or WRITE operation. 
> For
>     the purposes of this paragraph, a conflict occurs when a shared
> lock
>     is requested and a WRITE operation is being performed, or an
>     exclusive lock is requested and either a READ or a WRITE
> operation is
>     being performed.  A SETATTR that sets size is treated similarly
> to a
>     WRITE as discussed above.
> 
> We (the authors of the RFC) assumed that
> read locks are shared locks, and write
> locks are exclusive locks, and further that
> shared locks do not conflict with shared locks
> but do conflict with exclusive locks. Exclusive
> locks conflict with exclusive locks and shared locks.
> Again, such an inference can be drawn from the above
> passage. Given Syam's question, obviously we could have
> been clearer.
> 
> 
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nfsv4
> 

__________________________________ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/ 

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

---

From: David Robinson <[email-masked]>
Date: Tue, 15 Mar 2005 16:54:52 -0600

> man-page was wrong -- the man page seems to talk only about advisory

The mandatory locks in NFSv4 map closer to Windows mandatory
record locks than what exists in most Unix-like OSes.

> Would such a model have problems with interoperability?

I think you are in agreement with the semantics with the
acquiring and managing of the locks (shared & excl)
but it is unclear from your statements if the interaction
with the READ and WRITE ops.

Any READ or WRITE operation will succeed if there is no
record lock held by anyone.

A WRITE operation can only succeed if the stateid in that
operation is the result of a lock_owner having acquired
an exclusive record lock.

A READ operation can only succeed if the stateid in that
operation is the result of a lock_owner having acquired
an exclusive or a shared record lock.

It is a two phase process, the LOCK operations govern which
locks you can acquire, shared or exclusive, and hand back
a stateid. That stateid is used to communicate on the I/O
request which locks have been acquired and the server allows
or denies based on that state.

	-David