From: Noveck, Dave (Dave.Noveck@netapp.com)
Date: 11/06/00-08:13:29 AM Z
Message-ID: <BC0FBE708897D4118C5500902745938E21E428@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: Mon, 6 Nov 2000 06:13:29 -0800
> > > It might implement this by handling the open upgrade by doing a second
open
> > > and then closing one of its open's when a
> > > downgrade is done. There are some problems with this. As the spec stands,
> > > the client is not constrained in precisely
> > > what downgrades it would do, making it possible for it to make requests,
> > > that cannot be handled by the server closing
> > > one of its opens. Even if this could be resolved, there remains an issue
> I don't understand. The spec is very explicit in that OPEN_DOWNGRADE
> must not add bits not present in the previous OPEN for the nfs_lockowner/file
> pair.
Here is the worrisome case:
An OPEN request is done for READ, DENY=READ (NT server does the
corresponding open).
an OPEN request (same lockower, same file) is done for WRITE,
DENY=WRITE (NT server does corresponding second open on the same
file and upgrades total open state to READ+WRITE,DENY=READ+WRITE
An OPEN_DOWNGRADE request is done specifying READ, DENY=WRITE,
which is a subset (so the spec thngs it's OK) but the server
can't handle it but closing one of its two open files.
> > > with byte-range locks. The NT server has no
> > > way of knowing which of his opens to assign the locks to. He might assign
> > > them to an open which needs to be closed
> > > to satisfy a subsequent downgrade.
> For a given nfs_lockowner/file_handle pair there is just one
> oustanding OPEN. Thus the byte range locks would be moved to the second open,
> which then becomes the only open after the previous open is closed.
The issue there is that there is no way for the NT server to atomically
move locks between open files. You can release a lock and then do the
lock under the other open file but someone else (another local process)
could get the lock you released.
This archive was generated by hypermail 2.1.2 : 03/04/05-01:48:21 AM Z CST