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

["J. Bruce Fields" <bfields@fieldses.org>]

> > -----Original Message-----
> > From: nfsv4-bounces@ietf.org [mailto:nfsv4-bounces@ietf.org] On Behalf
> > Of Trond Myklebust
> > Sent: Wednesday, July 07, 2010 7:30 PM
> > To: nfsv4@ietf.org
> > 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.
_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4