IETF Logo Mail Archive

Re: [nfsv4] LAYOUTERROR in draft-ietf-nfsv4-minorversion2-40

David Noveck <davenoveck@gmail.com> Mon, 25 January 2016 01:41 UTC

Return-Path: <davenoveck@gmail.com>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68C371B36AA for <nfsv4@ietfa.amsl.com>; Sun, 24 Jan 2016 17:41:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ndpGS0gIp02l for <nfsv4@ietfa.amsl.com>; Sun, 24 Jan 2016 17:41:17 -0800 (PST)
Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 528971B36A6 for <nfsv4@ietf.org>; Sun, 24 Jan 2016 17:41:17 -0800 (PST)
Received: by mail-ob0-x22e.google.com with SMTP id zv1so3443900obb.2 for <nfsv4@ietf.org>; Sun, 24 Jan 2016 17:41:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MbIdQtaemD8/8Be07yv2DULimhOEiTzp0SV8wdFaa4s=; b=Hd/93NPzCGPGTb0KW1XI74b2BMa+8NwwMi9khgyl0gWoy+fTzyWeC1d6vRrVh4LyOB 4j0W7Ix6oeU0OlZ2ybn72WJnnW3TejJkNJarmuEWwvRUassLBN9picUtS6P2kmqwojKP liQddr6mXkYQRB9M7mxMYYPE1FSDx6suhN71LWizqJejWjMDLiX9Th5emfvLVryOr/uh Bvodr3qmeJ0ksp+9k5dP2bFUt7A2UfjJ3j5dPmyX8TSXL2TS1d+C1ymW+BTck5iy2z4c FVSRlWCge/7omYtycIBWtfBZ7hxd3GTo3AjDP0PN1gApMBATsCX21DViRQoYCLkw5s/h T7eA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=MbIdQtaemD8/8Be07yv2DULimhOEiTzp0SV8wdFaa4s=; b=PY6Ov+J77tUMF6uzttw2g7lwKaG2GgFa/xPxYyhyTuz9USsd8fCLJZ87ndKkcfnZPp V2gTfwsRMkbzUVenhliB3qtFwXZrqlelmpFyMDBwgb0GzVLUi6PKr9wljdDb0JfV/K16 3xu7tNcJjhnOqK9PdPfxnGo9XOpgsxA9LtO8WiKwh8igV4KH9AUsKNkfSODsjmW1YaYz MHhg5i80Xfv6iu9ZSq9FS+7f9pcrRTKQ+ixx8pugKSnp5TlJINZ57xJj6WszkbmYbMRR vIVCwXbSlnthLe7jlRUVqDPQXhkjxVFTYbxkTCedLFHI4H0ErxuZ3iIpMDBzLhulwypV FEJg==
X-Gm-Message-State: AG10YOSyLJXWoT1pBrIl6qGLpm5z/IH0jZeIvFT+QE0/u7/DDzhkMYFYg8w5emjInK362Xs8GDzrVGb7Ejgz9A==
MIME-Version: 1.0
X-Received: by 10.182.92.234 with SMTP id cp10mr11172321obb.79.1453686076631; Sun, 24 Jan 2016 17:41:16 -0800 (PST)
Received: by 10.182.92.201 with HTTP; Sun, 24 Jan 2016 17:41:16 -0800 (PST)
In-Reply-To: <CAABAsM6MxEYHkX+RrRvt=nsNNHZUo8jgLovo2cgHbrhSQO1vXQ@mail.gmail.com>
References: <CAABAsM5Nv_m9UwKzCoJV5HsBb8Lm4L8VWaoVDYPD2cVGd1QWPw@mail.gmail.com> <CADaq8jcE-0KqyMkbyxvFykQ3QwxgJG8X3WLNX9KaJwX9Uw+dTQ@mail.gmail.com> <CAABAsM6MxEYHkX+RrRvt=nsNNHZUo8jgLovo2cgHbrhSQO1vXQ@mail.gmail.com>
Date: Sun, 24 Jan 2016 20:41:16 -0500
Message-ID: <CADaq8jfG0TY36-sECkVWFp9GJ2LnLst_Y1G1tc19cVebTqrPGA@mail.gmail.com>
From: David Noveck <davenoveck@gmail.com>
To: Trond Myklebust <trondmy@gmail.com>
Content-Type: multipart/alternative; boundary="001a11c3050436745e052a1eaa17"
Archived-At: <http://mailarchive.ietf.org/arch/msg/nfsv4/6o6euEiIeIYEbIVqmcM5jSWe9aA>
Cc: "nfsv4@ietf.org" <nfsv4@ietf.org>
Subject: Re: [nfsv4] LAYOUTERROR in draft-ietf-nfsv4-minorversion2-40
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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: Mon, 25 Jan 2016 01:41:19 -0000

If this is only needed when interacting with a server supporting  the
flex-file layout type, the question should probably be ""What values should
[or SHOULD] servers that provide support for the flex-file layout type be
setting for 'ca_maxoperations' during session negotiation"?  I think it is
perfectly fine for the flex-files document to give reasonable guidance on
this point.



On Sun, Jan 24, 2016 at 12:34 PM, Trond Myklebust <trondmy@gmail.com> wrote:

> As I said in the reply to Benny's email, the question then becomes
> "what values are servers setting for 'ca_maxoperations' during session
> negotiation"?
>
> Cheers
>   Trond
>
> On Sun, Jan 24, 2016 at 5:23 AM, David Noveck <davenoveck@gmail.com>
> wrote:
> > You might consider reporting multiple ranges by using multiple
> > LAYOUTERRORs in a COMPOUND, given that each
> > LAYOUTERROR only allows a single range to be reported.
> >
> > On Sat, Jan 23, 2016 at 10:45 AM, Trond Myklebust <trondmy@gmail.com>
> wrote:
> >>
> >> Hi,
> >>
> >> When looking to implement LAYOUTERROR from
> >> https://tools.ietf.org/html/draft-ietf-nfsv4-minorversion2-40, I
> >> noticed there is a major difference between it and the way we're doing
> >> error passing in LAYOUTRETURN. While the latter allows you to send an
> >> array of several error reports for different byte ranges on the same
> >> file, the LAYOUTERROR spec only allows you to specify a single byte
> >> range.
> >>
> >> Being able to specify errors as an array of ranges is somewhat of a
> >> requirement for the flexfiles environment. In the case where the data
> >> is mirrored across several DSes, reporting the actual byte ranges
> >> where errors occurred can significantly cut down on the amount of work
> >> that the server has to perform to fix the mirroring when errors start
> >> to occur; instead of rewriting the whole file, it can just rewrite
> >> those chunks that had errors.
> >>
> >> A typical scenario where this might happen is if the file is fenced,
> >> and so the WRITEs start receiving EACCES calls; unless you are
> >> extraordinarily lucky, the fencing will leave one set of successful
> >> writes on one mirror image, and a different set on the other (due to
> >> timing, RPC reordering, etc).
> >>
> >> While I can continue to use LAYOUTRETURN for most cases, I was hoping
> >> to use LAYOUTERROR for those cases where we have queued up lots of
> >> errors (due to parallel WRITEs), and so want to split the error
> >> reporting into multiple RPC calls.
> >>
> >> Cheers
> >>   Trond
> >>
> >> _______________________________________________
> >> nfsv4 mailing list
> >> nfsv4@ietf.org
> >> https://www.ietf.org/mailman/listinfo/nfsv4
> >
> >
>

v2.23.0 | Report a Bug | By Email