Re: [nfsv4] question on bulk recall text

"Halevy, Benny" <bhalevy@panasas.com> Thu, 14 October 2010 13:20 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 C135D3A6A31 for <nfsv4@core3.amsl.com>; Thu, 14 Oct 2010 06:20:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level:
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_61=0.6, 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 GXxNKBwPBVjb for <nfsv4@core3.amsl.com>; Thu, 14 Oct 2010 06:20:09 -0700 (PDT)
Received: from exprod5og101.obsmtp.com (exprod5og101.obsmtp.com [64.18.0.141]) by core3.amsl.com (Postfix) with SMTP id 591BA3A6A22 for <nfsv4@ietf.org>; Thu, 14 Oct 2010 06:20:09 -0700 (PDT)
Received: from source ([67.152.220.89]) by exprod5ob101.postini.com ([64.18.4.12]) with SMTP ID DSNKTLcD1979790DH6xcOOXtQsCFSYHhW0an@postini.com; Thu, 14 Oct 2010 06:21:28 PDT
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 14 Oct 2010 09:21:27 -0400
Message-ID: <7225594ED4A1304C9E43D030A886D221F4C9A3@daytona.int.panasas.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [nfsv4] question on bulk recall text
Thread-Index: ActrJryimXFuZmcyS8mt/KZNvQujOAAezlQu
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> <ae7df427cd14510fdc260b62211aa06f.squirrel@webmail.eisler.com>
From: "Halevy, Benny" <bhalevy@panasas.com>
To: "Mike Eisler" <mre-ietf@eisler.com>, <nfsv4@ietf.org>, <trond.myklebust@fys.uio.no>
Cc: iisaman@netapp.com
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: Thu, 14 Oct 2010 13:20:12 -0000

> 
> 
> From: nfsv4-bounces@ietf.org on behalf of Mike Eisler
> Sent: Thu 2010-10-14 00:33
> To: nfsv4@ietf.org
> Subject: Re: [nfsv4] question on bulk recall text
> 
> 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.d 
> >
> > 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.
> 

True, and the last layoutreturn in response to the layoutrecall callback must be one.
But can't the client send RETURN_FILE layoutreturns voluntareely in the meanwhile
using the layout stateid is has in hand?.
I may need to be reminded at the exact test in the spec the prohibits that as Trond said...
 
Benny