From: Noveck, Dave (Dave.Noveck@netapp.com)
Date: 11/03/00-10:06:44 AM Z
Message-ID: <BC0FBE708897D4118C5500902745938E21E423@black.eng.netapp.com>
From: "Noveck, Dave" <Dave.Noveck@netapp.com>
Subject: RE: downgrade/upgrade (was Re: Spec-related discussions at the Ba ke-off)
Date: Fri, 3 Nov 2000 08:06:44 -0800
> "David Robinson" <David.Robinson@ebay.sun.com> writes:
> > I don't recall what the motivation for an upgrade/downgrade OPEN was.
> Just scanned the archive, looking for "downgrade" in a case insensitive
> search. BTW, I was not a participant in the discussion, so this is all
> based on reading the archive and not recollection of my thoughts at the
> time.
> The deal is this:
> UNIX process opens file "A" with mode READ and
> the nfs v4 file system issues the OPEN with mode READ, and deny NONE.
> The same process now opens "A" again, but this time with mode WRITE.
> NFSv4 has no notion of a unique file descriptor. Given that the
> nfs_lockowner is the same, and the file is the same, the only way the server
> can handle this is to treat the operation as an upgrade. So the nfsv4
> file system sends an OPEN with mode READ/WRITE and deny NONE.
> I gathered from the discussion that the Windows API would not allow the
> same process to open the file with two different modes, but in any
> case, this is immaterial, since UNIX does.
I may have misunderstood him, but I gathered from Carl, that Windows would
allow the same process to open the file with two different modes as long
as those modes are compatible (assuming exactly rules that would apply
for two different processes).
Carl, could you confirm or deny?
A process can open the file for READ, DENY=READ, and then
the same process can open the same file for WRITE, DENY=WRITE
> When the process closes one of the file descriptors on "A", the NFSv4
> file system needs to downgrade the SHARE to either READ or WRITE on the
> server. It cannot issue a CLOSE, because this removes all the SHARE
> state, so would leave a window for another client to OPEN the file with
> a DENY=~NONE, and so prevent the client from doing another OPEN to
> re-open the file. So an OPEN_DOWNGRADE operation is needed to deal with
> this.
Also, there may be byte-range locks associated with the first open so
closing could run into a problem there as well.
> > I don't believe that any existing APIs that handle shares has this
> > capability so I question why it shouldn't just be done with a CLOSE
> > followed by an OPEN, if it is ever needed.
> See the above.
This archive was generated by hypermail 2.1.2 : 03/04/05-01:48:20 AM Z CST