IETF Logo Mail Archive

Re: [nfsv4] parallel LAYOUTGETs using open stateid

Fred Isaman <iisaman@citi.umich.edu> Thu, 07 October 2010 15:28 UTC

Return-Path: <faisaman4@gmail.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 CDB263A6F9D for <nfsv4@core3.amsl.com>; Thu, 7 Oct 2010 08:28:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 dGHUhtkg3ciY for <nfsv4@core3.amsl.com>; Thu, 7 Oct 2010 08:27:58 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 4C0D63A6C24 for <nfsv4@ietf.org>; Thu, 7 Oct 2010 08:27:18 -0700 (PDT)
Received: by bwz9 with SMTP id 9so666325bwz.31 for <nfsv4@ietf.org>; Thu, 07 Oct 2010 08:28:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=QOOspBWS5GAIovDR0T1E6v20326iFICA73PXTAuid1o=; b=CwcTtCBo7DDVfjY+W6crbN+DX78yB4O0943SWja5qmwYKnOG6ZBOf9vUgCE5IKTfL4 TlLDfEhu9ySWVHJCETMJFWNvYpC3GmytzWsg8QmwsvUxFxfd06g+K3TXhnfIMpwc/9D6 Ex3ovi5cfWKA93wnCpZhOGbk792xRytpjUeD0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=cWFxHpsXMnv+18auQoezOluiMDwol2h+42m8v0ETkp+fQKUmD1K+uJi6cGopqOLOiv VszQz7jizlJZSOQyuGm7qw1/bSTBsbs9GaP/FupeDs7fzICmc6rhS+8JhhYf0GRYnHtk VDAb/quHGcLTSqJz8AaO6kjgFvJgDi26PtldA=
MIME-Version: 1.0
Received: by 10.204.84.20 with SMTP id h20mr786835bkl.186.1286465297625; Thu, 07 Oct 2010 08:28:17 -0700 (PDT)
Sender: faisaman4@gmail.com
Received: by 10.204.48.34 with HTTP; Thu, 7 Oct 2010 08:28:17 -0700 (PDT)
In-Reply-To: <4CADDB09.9020308@panasas.com>
References: <AANLkTinZ1t1YbL55vkT0OJ0i2j9AqNuvFStTwFoGO-dB@mail.gmail.com> <AANLkTin+0BG=u3o2DZcHgdODoaznePOeTrmQJfh9C6Ym@mail.gmail.com> <AANLkTimUgacoB2sEP=_k2RfVfuD04Ane1JY0ip5R+OpB@mail.gmail.com> <4CADDB09.9020308@panasas.com>
Date: Thu, 07 Oct 2010 11:28:17 -0400
X-Google-Sender-Auth: m98e7A2J1n4wSsPPEx-kyxdNIgo
Message-ID: <AANLkTikWYdxMzxxzu6MqPsJM7JVdzR2J6iYEp-n5OMXG@mail.gmail.com>
From: Fred Isaman <iisaman@citi.umich.edu>
To: Benny Halevy <bhalevy@panasas.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
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 15:28:32 -0000

On Thu, Oct 7, 2010 at 10:36 AM, Benny Halevy <bhalevy@panasas.com> wrote:
> 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

No, it must wait for the outstanding layoutgets that the server
processed before sending the CB_RECALL.  It is possible (at least by
the way I read the spec), to send two LAYOUTGETs, one of which gets
delayed and doesn't hit the server until after the CB_RECALL is
resolved, and then have the server process that LAYOUTGET normally.

Fred

>
>> 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
>>>>
>>>
>

v2.23.0 | Report a Bug | By Email