IETF Logo Mail Archive

Re: [nfsv4] IETF 102 nfsv4 WG meeting go/no-go

"J. Bruce Fields" <bfields@fieldses.org> Thu, 17 May 2018 21:46 UTC

Return-Path: <bfields@fieldses.org>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3D4A1275FD for <nfsv4@ietfa.amsl.com>; Thu, 17 May 2018 14:46:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpK51Ex7_1XA for <nfsv4@ietfa.amsl.com>; Thu, 17 May 2018 14:46:03 -0700 (PDT)
Received: from fieldses.org (fieldses.org [173.255.197.46]) by ietfa.amsl.com (Postfix) with ESMTP id 8B48E1200C5 for <nfsv4@ietf.org>; Thu, 17 May 2018 14:46:03 -0700 (PDT)
Received: by fieldses.org (Postfix, from userid 2815) id 7C9452020; Thu, 17 May 2018 17:46:02 -0400 (EDT)
Date: Thu, 17 May 2018 17:46:02 -0400
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Thomas Haynes <loghyr@gmail.com>
Cc: Trond Myklebust <trondmy@gmail.com>, "nfsv4@ietf.org" <nfsv4@ietf.org>
Message-ID: <20180517214602.GB16112@fieldses.org>
References: <89A4F7ED-2658-492C-BDAC-02193C956C33@oracle.com> <C65BBF0E-80B6-4896-8604-08DA177FDE8E@gmail.com> <20180517012607.GA9355@fieldses.org> <CAABAsM519qhPk4mMmzvcjug0siE=yFPOkCpgWh1Qco+E4ZtSAQ@mail.gmail.com> <20180517032054.GA10279@fieldses.org> <3A6D4B39-422F-4A6F-AA2F-B8B00FFD60D8@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <3A6D4B39-422F-4A6F-AA2F-B8B00FFD60D8@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/NyPmSszwzIzz87ScHj96S9EqcNU>
Subject: Re: [nfsv4] IETF 102 nfsv4 WG meeting go/no-go
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 May 2018 21:46:06 -0000

On Wed, May 16, 2018 at 08:22:26PM -0700, Thomas Haynes wrote:
> > On May 16, 2018, at 8:20 PM, Dr James Bruce Fields <bfields@fieldses.org> wrote:
> > On Wed, May 16, 2018 at 11:10:54PM -0400, Trond Myklebust wrote:
> >> On Wed, 16 May 2018 at 21:26, J. Bruce Fields <bfields@fieldses.org> wrote:
> >>>> draft-haynes-nfsv4-delstid-00 <
> >> https://datatracker.ietf.org/doc/draft-haynes-nfsv4-delstid/>
> >> 
> >>> What's the motivation for WANT_OPEN_XOR_DELEGATION?
> >> 
> >> 
> >> What's the motivation for asking for a delegation _and_ an open stateid?
> >> That means you have to return 2 objects instead of just one.
> >> 
> >> The WANT_OPEN_XOR_DELEGATION  option authorises the server to return a
> >> delegation without the open stateid, which cuts down on the amount of
> >> traffic between the client and server. Yes, you could just ask for a
> >> delegation using WANT_DELEGATION, but if the server is unable to hand one
> >> out, it will return an error, and you're back to sending an OPEN..
> > 
> > Got it, thanks.  So the traffic saved is one unnecessary CLOSE (in the
> > case the server returns a delegation)?
> > 
> > --b.
> 
> Yes - and perhaps a GETATTR in that compound

Is there a particular case you've encountered when those turn out to be
a problem?

--b.

v2.23.0 | Report a Bug | By Email