Subject: Re: [nfsv4] OPEN_DOWNGRADE and posix byte range locking issue

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 19 Aug 2010 12:44:48 -0400

> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of Trond Myklebust
> > Sent: Wednesday, July 07, 2010 7:30 PM
> > To: [email-masked]
> > Subject: [nfsv4] OPEN_DOWNGRADE and posix byte range locking issue
> > 
> > Neither RFC3530, nor RFC5661 appear to list NFS4ERR_LOCKS_HELD as a
> > valid response when the client calls OPEN_DOWNGRADE.
> > 
> > The question is: what should the server then do if the NFS client holds
> > a WRITE_LT lock, but then asks for an OPEN_DOWNGRADE to
> > OPEN4_SHARE_ACCESS_READ. I understand that this is sanctioned in Windows
> > server environments, but it should definitely be forbidden in a POSIX
> > environment, and NFS4ERR_LOCKS_HELD would appear to fit the bill...

A bizarre variation: the linux server associates vfs opens with
stateid's.  Locks are performed on vfs opens, and the vfs will complain
if you attempt to close a file that still has locks associated with it.

The sequence

	open RW
	lock R
	open R
	open downgrade to R

would therefore be implemented at the vfs level as:

	open RW -> f
	lock R on f
	open R -> g
	close f

Oops.  We're stuck with ditching the lock (or erroring out) even though
it's still compatible with the new config option.

Well, I suppose this is my problem: either I should get a new vfs open
for the use of the lock, or represent the original RW open by two vfs
open's.

It's not something a unix-like client could do, I think, but I don't
think it's safe for me to assume I can reject it?

--b.

---

From: <[email-masked]>
Date: Fri, 20 Aug 2010 11:35:02 -0400

It isn't the server's problem.  There is no way the server has access to
the Vfs opens as visible objects or as having the assignment of locks to
such fine-grained opens.

I'm kind of thinking that this shows we (Bruce, me, and rest of the
working group) made a mistake in that sort of a design in which we do
not allow multiple distinguished open objects for a given fh-owner pair.
Anyway the problems that it caused are pretty minor and we don't know
what problems would have been generated with an alternate design.  I
think this is something to look at in NFSv5 or the next NFSv4.1-style
minor version, if any. 

-----Original Message-----
From: J. Bruce Fields [mailto:[email-masked]] 
Sent: Thursday, August 19, 2010 12:45 PM
To: Trond Myklebust
Cc: Noveck, David; [email-masked]; [email-masked]
Subject: Re: [nfsv4] OPEN_DOWNGRADE and posix byte range locking issue

The sequence

	open RW
	lock R
	open R
	open downgrade to R

	open RW -> f
	lock R on f
	open R -> g
	close f

--b.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Fri, 20 Aug 2010 11:58:09 -0400

On Fri, Aug 20, 2010 at 11:35:02AM -0400, [email-masked] wrote:
> the Vfs opens as visible objects

I was talking about how our server maps incoming open requests to vfs
opens when talking to its own vfs layer.

Whatever, it's my problem--I can deal with it.

> or as having the assignment of locks to
> such fine-grained opens.
> 

But, yes, I have found the open upgrade/downgrade behavior confusing.

--b.