Subject: RE: [nfsv4] Locking Sematics

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 15 Mar 2005 06:57:55 -0500

> What kind of locks are you referring to here? For byte range locks, this
> is exactly how the server currently implements them.

Are you referring to,

> > One way to implement the read and write locks on the server side would
> > be to implement read locks as shared locks and write locks as exclusive
> > locks. That is, any number of clients can take a read lock on a given
> > range and only 1 client can take a write lock on a given range. 

In which case no surprise.  

But what about the rest of that paragraph,

> > In this
> > model, only write operations are prevented in presence of conflicting
> > locks 

Are you saying you do prevent writes if there is an overlap with a
byte-range lock?  I hadn't heard that anybody was doing that yet.  I was
supposing that that might be disruptive for people expecting the NLM
behavior (byte-range locking and IO don't interact).  From one version
of the Linux fcntl man page I see that mandatory locking is a mount
option but this doesn't fit v4 very well since there is no way for
the client's choice to be communicated to the server.

The paragraph says "conflicting locks" but doesn't say what locks
conflict.  Clearly exclusive locks conflcit with a write but I would
expect shared locks to conflict with a write as well.

> > and read operations always go through.

One would normally expect that if you want to have mandatory locking
there has be some way to exclude reads.  Why wouldn't an exclusive 
byte-range lock exclude reads, if it is going to prevent conflicting
IO? 

> > This is my understanding
> > of the POSIX model from the fcntl man page. 

There are I guess many versions of the fcntl man page.  The ones I've
looked at don't say much on this issue.  Could we have a quote that
addresses the issue of what are considered IO conflicts? 

> For Windows SHARE locks, OTOH, you cannot do this, since that would
> conflict with byte range locks, and could cause deadlocks for clients.  

I'm unclear what the "this" that you cannot do is.  Also by "Windows
SHARE locks" are you referring to soemthing actually in Windows or
to the v4 share reservations in open modeled on Windows?

-----Original Message-----
From: Trond Myklebust [mailto:[email-masked]]
Sent: Monday, March 14, 2005 10:45 PM
To: Syam Pannala
Cc: [email-masked]
Subject: Re: [nfsv4] Locking Sematics

må den 14.03.2005 Klokka 18:09 (-0800) skreiv Syam Pannala:
> Hi,
> 
> One way to implement the read and write locks on the server side would
> be to implement read locks as shared locks and write locks as exclusive
> locks. That is, any number of clients can take a read lock on a given
> range and only 1 client can take a write lock on a given range. In this
> model, only write operations are prevented in presence of conflicting
> locks and read operations always go through. This is my understanding
> of the POSIX model from the fcntl man page.

What kind of locks are you referring to here? For byte range locks, this
is exactly how the server currently implements them.
For Windows SHARE locks, OTOH, you cannot do this, since that would
conflict with byte range locks, and could cause deadlocks for clients.

Cheers,
  Trond
-- 
Trond Myklebust <[email-masked]>

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

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

---

From: Trond Myklebust <[email-masked]>
Date: Tue, 15 Mar 2005 09:47:58 -0500

> > is exactly how the server currently implements them.

Yes.

> the client's choice to be communicated to the server.

You'd have to ask the original poster, but I assume that if you want to
use POSIX locks in order to implement share locks/reservations, then the
locking would be done by the _server_, not the client.

> to the v4 share reservations in open modeled on Windows?

I mean v4 share reservations, which are modelled on Windows' "share
locks", and are for all intents and purposes identical to the latter.

We know that on Linux, at least, Samba emulates share locks by using a
"special" mode on the flock() (i.e. BSD - not POSIX) locks. They have
create a LOCK_MAND option which is documented as being a "mandatory
flock". From the source comments:

/**
 *      sys_flock: - flock() system call.
 *      @fd: the file descriptor to lock.
 *      @cmd: the type of lock to apply.
 *
 *      Apply a %FL_FLOCK style lock to an open file descriptor.
 *      The @cmd can be one of
 *
 *      %LOCK_SH -- a shared lock.
 *
 *      %LOCK_EX -- an exclusive lock.
 *
 *      %LOCK_UN -- remove an existing lock.
 *
 *      %LOCK_MAND -- a `mandatory' flock.  This exists to emulate Windows Share Modes.
 *
 *      %LOCK_MAND can be combined with %LOCK_READ or %LOCK_WRITE to allow other *      processes read and write access respectively.
 */
asmlinkage long sys_flock(unsigned int fd, unsigned int cmd)
...

Of course, there is still no VFS support for doing an atomic
open(O_CREATE) + set a LOCK_MAND lock, so this mechanism still is not a
perfect match for the Windows open() specs (and those same atomicity
requirements exist for NFSv4). However if you are exclusively accessing
the filesystem via Samba, then the latter can provide the atomicity
guarantees.

Note also that this works well in conjunction with byte range locks
(which use posix locking), since on Linux, the flock() and posix locks
are transparent to one another.

Cheers,
  Trond