Return-Path: linux-nfs-owner@vger.kernel.org Received: from mail-ie0-f181.google.com ([209.85.223.181]:32837 "EHLO mail-ie0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753539AbbAOQaP (ORCPT ); Thu, 15 Jan 2015 11:30:15 -0500 Received: by mail-ie0-f181.google.com with SMTP id rl12so15760934iec.12 for ; Thu, 15 Jan 2015 08:30:14 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <20150115162618.GA14681@lst.de> References: <1420561721-9150-10-git-send-email-hch@lst.de> <20150108164851.03b64e16@synchrony.poochiereds.net> <20150109100551.GA23173@lst.de> <20150109085130.0f862d24@synchrony.poochiereds.net> <20150109171641.GA17464@lst.de> <20150109092835.5fdbac5d@synchrony.poochiereds.net> <20150109093353.31a2e425@synchrony.poochiereds.net> <20150109184943.GA18955@lst.de> <20150114191627.GA76105@kitty> <20150115162618.GA14681@lst.de> Date: Thu, 15 Jan 2015 11:30:14 -0500 Message-ID: Subject: Re: [nfsv4] rfc5661 errata 3901, was: Re: [PATCH 09/18] nfsd: implement pNFS operations From: Trond Myklebust To: Christoph Hellwig Cc: Tom Haynes , Linux NFS Mailing List , Sachin Bhamare , "nfsv4@ietf.org" , "J. Bruce Fields" , Jeff Layton Content-Type: text/plain; charset=UTF-8 Sender: linux-nfs-owner@vger.kernel.org List-ID: On Thu, Jan 15, 2015 at 11:26 AM, Christoph Hellwig wrote: > On Wed, Jan 14, 2015 at 11:16:27AM -0800, Tom Haynes wrote: >> Christoph, >> >> I don't understand this concern. Section 8.2.1: >> >> open stateids: OPEN state for a given client ID/open-owner/filehandle triple >> >> delegation stateids: A stateid represents a single delegation held by a client for a >> particular filehandle. >> >> By definition, open/delegation stateids are tracked per >> file/client combination. > > My concern is that the language in errata 3901 says the server should > invalidate all layouts after all open stateids are closed, and all > delegation stateids are returned for a given file, which means the > server needs to add another object just to track the layouts. If > on the other hand we say the lifetime of the layouts is tied to > the open stateid or the delegation stateid used to create the > layout stateid we can track the outstanding layouts in those > open/delegation stateid (and the lock stateid as well). > The problem, in my mind, is that defeats the main purpose of return-on-close, which is to reduce the on-the-wire chattiness of the protocol. How one implements that internally on the server is not really a concern that should be reflected in the protocol. Cheers Trond