Re: [nfsv4] question on bulk recall text

"Mike Eisler" <mre-ietf@eisler.com> Wed, 13 October 2010 22:32 UTC

Return-Path: <mre-ietf@eisler.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 7EA733A69D7 for <nfsv4@core3.amsl.com>; Wed, 13 Oct 2010 15:32:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599]
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 DfDRqROGyxLA for <nfsv4@core3.amsl.com>; Wed, 13 Oct 2010 15:32:36 -0700 (PDT)
Received: from postalmail-a8.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by core3.amsl.com (Postfix) with ESMTP id 9E0C93A69FF for <nfsv4@ietf.org>; Wed, 13 Oct 2010 15:32:35 -0700 (PDT)
Received: from webmail.eisler.com (ahfbbjcaiaae.dreamhost.com [75.119.208.4]) by postalmail-a8.g.dreamhost.com (Postfix) with ESMTP id 585CCAABBD for <nfsv4@ietf.org>; Wed, 13 Oct 2010 15:33:52 -0700 (PDT)
Received: from 198.95.226.230 (proxying for 198.95.226.230) (SquirrelMail authenticated user mre-ietf@eisler.com) by webmail.eisler.com with HTTP; Wed, 13 Oct 2010 15:33:53 -0700
Message-ID: <ae7df427cd14510fdc260b62211aa06f.squirrel@webmail.eisler.com>
In-Reply-To: <1286908621.675.1.camel@heimdal.trondhjem.org>
References: <AANLkTinx1ZQWko8D9XgmikaGAv4nHxoWJ2bDuM5O=y_u@mail.gmail.com> <1286902798.24878.9.camel@heimdal.trondhjem.org> <4CB49E59.3040409@panasas.com> <1286908621.675.1.camel@heimdal.trondhjem.org>
Date: Wed, 13 Oct 2010 15:33:53 -0700
From: "Mike Eisler" <mre-ietf@eisler.com>
To: nfsv4@ietf.org
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Subject: Re: [nfsv4] question on bulk recall text
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: Wed, 13 Oct 2010 22:32:39 -0000

On Tue, October 12, 2010 11:37 am, Trond Myklebust wrote:
> On Tue, 2010-10-12 at 13:43 -0400, Benny Halevy wrote:
>> On 2010-10-12 12:59, Trond Myklebust wrote:
>> > On Tue, 2010-10-12 at 12:19 -0400, Fred Isaman wrote:
>> >> The text for bulk recalls in 12.5.5.2.1.5 seems flawed:
>> >>
>> >>    Once a CB_LAYOUTRECALL of LAYOUTRECALL4_ALL is sent, the server
>> MUST
>> >>    NOT allow the client to use any layout stateid except for
>> >>    LAYOUTCOMMIT operations.  Once the client receives a
>> CB_LAYOUTRECALL
>> >>    of LAYOUTRECALL4_ALL, it MUST NOT use any layout stateid except
>> for
>> >>    LAYOUTCOMMIT operations.
>> >>
>> >> (similarly for LAYOUTRECALL4_FSID)
>> >>
>> >> My question: what stateid does the client use to send the required
>> LAYOUTRETURN?
>> >
>> > LAYOUTRETURN with a LAYOUTRETURN4_FSID or a LAYOUTRETURN4_ALL argument
>> > doesn't take a stateid.
>>
>> Right, but if the client wants to return individual layouts
>> in the process the question is still valid.
>> One reason to do that is to show progress while the client
>> is flushing its caches.
>
> LAYOUTCOMMIT should suffice to show progress, whereas LAYOUTRETURN with
> a LAYOUTRETURN4_FILE appears to be explicitly prohibited by the spec
> (and not just in the text that Fred quotes).

Correct, no point in a bulk recall if you can't have a bulk return.

-- 
Mike Eisler, Senior Technical Director, NetApp, 719 599 9026,
http://blogs.netapp.com/eislers_nfs_blog/