[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [nfsv4] Asking for details about OPEN_DOWNGRADE
On Wed, Jun 25, 2008 at 11:49:01AM -0400, Rick Macklem wrote:
>
>
> On Mon, 16 Jun 2008, Trond Myklebust wrote:
>
>> On Mon, 2008-06-16 at 16:50 -0700, Steven Huntington wrote:
>>> Question to the gallery:
>>>
>>> Does all this imply that for open reclaim, the client needs to send
>>> each individual OPEN reclaim OP as opposed to a single composite OPEN
>>> for the openowner/FH pair, so that the new instance of the server can
>>> know what unions are valid and what aren't? In short, does this apply
>>> to reclaimed open share/deny flags as well as non-reclaimed ("normal")
>>> ones?
>>>
>>> Cheers,
>>>
>>> Steve Huntington, IBM San Jose
>>
>> Yes, but assuming that you have applications that are all opening the
>> same file with a mixture of all three open modes (I'm also assuming you
>> don't care about the POSIX-incompatible DENY modes), you should be able
>> to get away with just sending a maximum of 3 OPEN calls per file
>> +open_owner combination.
>> i.e.
>> - OPEN(OPEN4_SHARE_ACCESS_READ, OPEN4_SHARE_DENY_NONE)
>> - OPEN(OPEN4_SHARE_ACCESS_WRITE, OPEN4_SHARE_DENY_NONE)
>> - OPEN(OPEN4_SHARE_ACCESS_BOTH, OPEN4_SHARE_DENY_NONE)
>>
>> That will allow you to downgrade to a READ-only mode once all the O_RDWR
>> and O_WRONLY descriptors have been closed, or to a WRITE-only mode once
>> the O_RDWR and O_RDONLY descriptors have been closed.
>>
> Flame suit on:-)... Personally, I can't see much point in a posix client
> (one always using deny_none) iFrom nfsv4-bounces at ietf.org Wed Jun 25 09:32:09 2008
Return-Path: <nfsv4-bounces at ietf.org>
X-Original-To: nfsv4-archive at megatron.ietf.org
Delivered-To: ietfarch-nfsv4-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 5FFD13A698C;
Wed, 25 Jun 2008 09:32:09 -0700 (PDT)
X-Original-To: nfsv4 at core3.amsl.com
Delivered-To: nfsv4 at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 4BFD53A698C
for <nfsv4 at core3.amsl.com>; Wed, 25 Jun 2008 09:32:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5
tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id NZlhbPmLIPj0 for <nfsv4 at core3.amsl.com>;
Wed, 25 Jun 2008 09:32:04 -0700 (PDT)
Received: from fieldses.org (mail.fieldses.org [66.93.2.214])
by core3.amsl.com (Postfix) with ESMTP id EB70A3A67E3
for <nfsv4 at ietf.org>; Wed, 25 Jun 2008 09:32:03 -0700 (PDT)
Received: from bfields by fieldses.org with local (Exim 4.69)
(envelope-from <bfields at fieldses.org>)
id 1KBXuY-0003BX-0o; Wed, 25 Jun 2008 12:31:58 -0400
Date: Wed, 25 Jun 2008 12:31:57 -0400
To: Rick Macklem <rmacklem at uoguelph.ca>
Message-ID: <20080625163157.GA12143 at fieldses.org>
References: <OF2D79CE77.5B8F176A-ON8825746A.0082610F-8825746A.0082EEE4 at us.ibm.com>
<1213662521.7230.18.camel at localhost>
<Pine.GSO.4.63.0806251104290.13386 at muncher.cs.uoguelph.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.63.0806251104290.13386 at muncher.cs.uoguelph.ca>
User-Agent: Mutt/1.5.18 (2008-05-17)
From: "J. Bruce Fields" <bfields at fieldses.org>
Cc: Steven Huntington <shunting at us.ibm.com>, nfsv4 at ietf.org,
Trond Myklebust <trond.myklebust at fys.uio.no>
Subject: Re: [nfsv4] Asking for details about OPEN_DOWNGRADE
X-BeenThere: nfsv4 at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>,
<mailto:nfsv4-request at ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/nfsv4>
List-Post: <mailto:nfsv4 at ietf.org>
List-Help: <mailto:nfsv4-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>,
<mailto:nfsv4-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: nfsv4-bounces at ietf.org
Errors-To: nfsv4-bounces at ietf.org
On Wed, Jun 25, 2008 at 11:49:01AM -0400, Rick Macklem wrote:
>
>
> On Mon, 16 Jun 2008, Trond Myklebust wrote:
>
>> On Mon, 2008-06-16 at 16:50 -0700, Steven Huntington wrote:
>>> Question to the gallery:
>>>
>>> Does all this imply that for open reclaim, the client needs to send
>>> each individual OPEN reclaim OP as opposed to a single composite OPEN
>>> for the openowner/FH pair, so that the new instance of the server can
>>> know what unions are valid and what aren't? In short, does this apply
>>> to reclaimed open share/deny flags as well as non-reclaimed ("normal")
>>> ones?
>>>
>>> Cheers,
>>>
>>> Steve Huntington, IBM San Jose
>>
>> Yes, but assuming that you have applications that are all opening the
>> same file with a mixture of all three open modes (I'm also assuming you
>> don't care about the POSIX-incompatible DENY modes), you should be able
>> to get away with just sending a maximum of 3 OPEN calls per file
>> +open_owner combination.
>> i.e.
>> - OPEN(OPEN4_SHARE_ACCESS_READ, OPEN4_SHARE_DENY_NONE)
>> - OPEN(OPEN4_SHARE_ACCESS_WRITE, OPEN4_SHARE_DENY_NONE)
>> - OPEN(OPEN4_SHARE_ACCESS_BOTH, OPEN4_SHARE_DENY_NONE)
>>
>> That will allow you to downgrade to a READ-only mode once all the O_RDWR
>> and O_WRONLY descriptors have been closed, or to a WRITE-only mode once
>> the O_RDWR and O_RDONLY descriptors have been closed.
>>
> Flame suit on:-)... Personally, I can't see much point in a posix client
> (one always using deny_none) in doing open_downgrades at all. As the
> recent discussion has shown, it's a pain to get right and what benefit
> does it have?
>
> - Since all opens are deny_none, other clients aren't restricted against
> opening the file.
Local users may be unnecessarily prohibited from executing it, though,
right?
--b.
> - Unless another client had the file open, the open probably provided a
> delegation, so the client is doing opens locally anyhow and just using
> Access to check permissions, etc.
> - If the file is being opened by other clients, holding the open with
> the most access permissions acquired will prevent the other client
> being given a delegation. (The case where rw is downgraded to ro and
> then another client opens it for reading and gets a read delegation.)
> Some might argue this is a case where the open_downgrade is a good thing
> to do, but I haven't found read delegations particularily useful and,
> if this client wants to "open upgrade" to rw again, the read delegation
> just results in extra overhead. As such, I'd argue that just holding
> onto the rw open and preventing another client from getting a read
> delegation is preferable, or at least "as acceptable".
>
> In summary, I can't see an advantage for the client in doing an
> open_downgrade and I can't see what advantage it provides to the server
> or other clients, either? (Assuming it's always using deny_none, of
> course.)
>
> Comments? rick
>
> _______________________________________________
> nfsv4 mailing list
> nfsv4 at ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
_______________________________________________
nfsv4 mailing list
nfsv4 at ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
n doing open_downgrades at all. As the
> recent discussion has shown, it's a pain to get right and what benefit
> does it have?
>
> - Since all opens are deny_none, other clients aren't restricted against
> opening the file.
Local users may be unnecessarily prohibited from executing it, though,
right?
--b.
> - Unless another client had the file open, the open probably provided a
> delegation, so the client is doing opens locally anyhow and just using
> Access to check permissions, etc.
> - If the file is being opened by other clients, holding the open with
> the most access permissions acquired will prevent the other client
> being given a delegation. (The case where rw is downgraded to ro and
> then another client opens it for reading and gets a read delegation.)
> Some might argue this is a case where the open_downgrade is a good thing
> to do, but I haven't found read delegations particularily useful and,
> if this client wants to "open upgrade" to rw again, the read delegation
> just results in extra overhead. As such, I'd argue that just holding
> onto the rw open and preventing another client from getting a read
> delegation is preferable, or at least "as acceptable".
>
> In summary, I can't see an advantage for the client in doing an
> open_downgrade and I can't see what advantage it provides to the server
> or other clients, either? (Assuming it's always using deny_none, of
> course.)
>
> Comments? rick
>
> _______________________________________________
> nfsv4 mailing list
> nfsv4 at ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
_______________________________________________
nfsv4 mailing list
nfsv4 at ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4