> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]] On Behalf
> > Of Trond Myklebust
> > Sent: Wednesday, July 07, 2010 7:30 PM
> > To: [email protected]
> > 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
[email protected]
https://www.ietf.org/mailman/listinfo/nfsv4
On Fri, Aug 20, 2010 at 11:35:02AM -0400, [email protected] wrote:
> It isn't the server's problem. There is no way the server has access to
> 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.
>
> 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.
But, yes, I have found the open upgrade/downgrade behavior confusing.
--b.
>
> -----Original Message-----
> From: J. Bruce Fields [mailto:[email protected]]
> Sent: Thursday, August 19, 2010 12:45 PM
> To: Trond Myklebust
> Cc: Noveck, David; [email protected]; [email protected]
> Subject: Re: [nfsv4] OPEN_DOWNGRADE and posix byte range locking issue
>
> > > -----Original Message-----
> > > From: [email protected] [mailto:[email protected]] On
> Behalf
> > > Of Trond Myklebust
> > > Sent: Wednesday, July 07, 2010 7:30 PM
> > > To: [email protected]
> > > 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.
>
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 protected]]
Sent: Thursday, August 19, 2010 12:45 PM
To: Trond Myklebust
Cc: Noveck, David; [email protected]; [email protected]
Subject: Re: [nfsv4] OPEN_DOWNGRADE and posix byte range locking issue
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]] On
Behalf
> > Of Trond Myklebust
> > Sent: Wednesday, July 07, 2010 7:30 PM
> > To: [email protected]
> > 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
[email protected]
https://www.ietf.org/mailman/listinfo/nfsv4