Re: [nfsv4] More layout stuff: layout return on close

Tigran Mkrtchyan <tigran.mkrtchyan@desy.de> Thu, 25 November 2010 09:10 UTC

Return-Path: <tigran.mkrtchyan@desy.de>
X-Original-To: nfsv4@core3.amsl.com
Delivered-To: nfsv4@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD7003A6A5B for <nfsv4@core3.amsl.com>; Thu, 25 Nov 2010 01:10:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.248
X-Spam-Level:
X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, UNPARSEABLE_RELAY=0.001]
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 vgrnhW2AdTw1 for <nfsv4@core3.amsl.com>; Thu, 25 Nov 2010 01:10:15 -0800 (PST)
Received: from smtp-out-1.desy.de (smtp-out-1.desy.de [131.169.56.84]) by core3.amsl.com (Postfix) with ESMTP id 09EF03A68FA for <nfsv4@ietf.org>; Thu, 25 Nov 2010 01:10:14 -0800 (PST)
Received: from smtp-map-1.desy.de (smtp-map-1.desy.de [131.169.56.66]) by smtp-out-1.desy.de (DESY_OUT_1) with ESMTP id A9F59172B for <nfsv4@ietf.org>; Thu, 25 Nov 2010 10:11:14 +0100 (MET)
Received: from adserv71.win.desy.de (adserv71.win.desy.de [131.169.97.57]) by smtp-map-1.desy.de (DESY_MAP_1) with ESMTP id 8915D13F0A for <nfsv4@ietf.org>; Thu, 25 Nov 2010 10:11:14 +0100 (MET)
Received: from smtp-intra-2.desy.de (lb-40-26.desy.de) by adserv71.win.desy.de (Clearswift SMTPRS 5.3.4) with ESMTP id <T998eecb5a983a961390cc@adserv71.win.desy.de>; Thu, 25 Nov 2010 10:11:13 +0100
Received: from [131.169.185.68] (anahit.desy.de [131.169.185.68]) by smtp-intra-2.desy.de (DESY-INTRA-2) with ESMTP id C65EADC5; Thu, 25 Nov 2010 10:11:13 +0100 (MET)
Message-ID: <4CEE283D.5040903@desy.de>
Date: Thu, 25 Nov 2010 10:11:25 +0100
From: Tigran Mkrtchyan <tigran.mkrtchyan@desy.de>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: nfsv4@ietf.org
References: <1290552459.30508.4.camel@heimdal.trondhjem.org> <4CECC382.5020207@panasas.com> <4CECE104.5080009@desy.de> <1290610592.3234.20.camel@heimdal.trondhjem.org>
In-Reply-To: <1290610592.3234.20.camel@heimdal.trondhjem.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
Subject: Re: [nfsv4] More layout stuff: layout return on close
X-BeenThere: nfsv4@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@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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, 25 Nov 2010 09:10:16 -0000

On 11/24/2010 03:56 PM, Trond Myklebust wrote:
> On Wed, 2010-11-24 at 10:55 +0100, Tigran Mkrtchyan wrote:
>>
>> We are in a quite weird situation here. From one side servers asks  a
>> client to return
>> layout on close, but from other side you have to keep track of the
>> layout and recall it to
>> ensure that the client will not use it any more.  I would love to see
>> this part of the spec to
>> be more deterministic. But it we change it not to be a more strong
>> requirements, then
>> some of the current clients will become not complaint with the spec. Are
>> we ok with that?
> I fail to see your point. Which clients would become spec incompliant if
> we relax the requirement that they must send a layoutreturn before close
> when the server sets the logr_return_on_close flag? Relaxing a
> requirement is not equivalent to prohibiting the behaviour.
If I read it correctly, then spec change will allow servers to forget 
client layout on close.
The new clients will simply forget layout on close. Nevertheless the old 
( existing ) clients
are allowed to reuse it as return_on_close was ( are ) only a hint.

May be I see it wrong.

Tigran.
>> And of course I have to change layout handling in our server we rely on
>> layoutreturn. Which
>> is not a big change (I think). BTW, is there any other server uses
>> return_on_close ?
> You don't have to change the server, but if you don't then it will
> perform less than optimally with forgetful clients.
>
>
> Trond