Re: [nfsv4] parallel LAYOUTGETs using open stateid

Benny Halevy <bhalevy@panasas.com> Thu, 07 October 2010 14:35 UTC

Return-Path: <bhalevy@panasas.com>
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 6E9333A7149 for <nfsv4@core3.amsl.com>; Thu, 7 Oct 2010 07:35:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 qAzES6BMQ6uG for <nfsv4@core3.amsl.com>; Thu, 7 Oct 2010 07:35:55 -0700 (PDT)
Received: from exprod5og107.obsmtp.com (exprod5og107.obsmtp.com [64.18.0.184]) by core3.amsl.com (Postfix) with SMTP id EFF6B3A702C for <nfsv4@ietf.org>; Thu, 7 Oct 2010 07:35:54 -0700 (PDT)
Received: from source ([67.152.220.89]) by exprod5ob107.postini.com ([64.18.4.12]) with SMTP ID DSNKTK3bCTOt88DO/imjI2hChzMoSmkCGGpC@postini.com; Thu, 07 Oct 2010 07:36:58 PDT
Received: from lt.bhalevy.com ([172.17.33.129]) by daytona.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Oct 2010 10:36:56 -0400
Message-ID: <4CADDB09.9020308@panasas.com>
Date: Thu, 07 Oct 2010 10:36:57 -0400
From: Benny Halevy <bhalevy@panasas.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.9) Gecko/20100921 Fedora/3.1.4-1.fc13 Thunderbird/3.1.4
MIME-Version: 1.0
To: Fred Isaman <iisaman@citi.umich.edu>
References: <AANLkTinZ1t1YbL55vkT0OJ0i2j9AqNuvFStTwFoGO-dB@mail.gmail.com> <AANLkTin+0BG=u3o2DZcHgdODoaznePOeTrmQJfh9C6Ym@mail.gmail.com> <AANLkTimUgacoB2sEP=_k2RfVfuD04Ane1JY0ip5R+OpB@mail.gmail.com>
In-Reply-To: <AANLkTimUgacoB2sEP=_k2RfVfuD04Ane1JY0ip5R+OpB@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 07 Oct 2010 14:36:56.0239 (UTC) FILETIME=[17672BF0:01CB662D]
Cc: nfsv4@ietf.org
Subject: Re: [nfsv4] parallel LAYOUTGETs using open stateid
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, 07 Oct 2010 14:35:59 -0000

On 2010-10-07 10:20, Fred Isaman wrote:
> On Thu, Oct 7, 2010 at 9:50 AM, Benny Halevy <bhalevy@panasas.com> wrote:
>> On Thu, Oct 7, 2010 at 9:21 AM, Fred Isaman <iisaman@citi.umich.edu> wrote:
>>> This question came up as I was going through our layout stateid code.
>>>
>>> Can the client send multiple LAYOUTGETs in parallel before getting a
>>> layoutstateid by using an open stateid?
>>> If so, what is the server response?  The spec is not clear, but I
>>> would assume it would do one of:
>>> a) returning an error (what error?) on all but the first LAYOUTGET it sees
>>> b) matching the openstateid to the layoutstateid it has already given
>>> out and sending a reply with that stateid and a bumped seqid
>>
>> I'm in favour of (b).
>> Are there any problems you see in that approach?
>>
>> Benny
>>
> 
> The wrinkle it adds is that, in the normal case, after the CB_RECALL
> is resolved, any stale LAYOUTGETs (sent by the client before it
> received the CB_RECALL) that the server receives will either be
> processed normally with a bumped seqid or an error (if the server

But the client MUST not process the layout recall before receiving
replies for the outstanding layoutgets. (see section 12.5.5.2.1.
Layout Recall and Return Sequencing)

Benny

> invalidated the "other" part of the stateid.)  In the openstateid
> case, the server loses the option of returning an error, instead it
> wuold create a new "other" with seqid=1.  That said, I don't see that
> this causes any problems apart from extra bookkeeping.
> 
> Fred
> 
>>> Fred
>>> _______________________________________________
>>> nfsv4 mailing list
>>> nfsv4@ietf.org
>>> https://www.ietf.org/mailman/listinfo/nfsv4
>>>
>>