Re: [nfsv4] Review of draft-ietf-nfsv4-layout-types-05

Thomas Haynes <loghyr@primarydata.com> Thu, 27 July 2017 07:50 UTC

Return-Path: <loghyr@primarydata.com>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD5A12EC3F for <nfsv4@ietfa.amsl.com>; Thu, 27 Jul 2017 00:50:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.489
X-Spam-Level:
X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=primarydata.onmicrosoft.com
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 M4BtCmigGia3 for <nfsv4@ietfa.amsl.com>; Thu, 27 Jul 2017 00:50:15 -0700 (PDT)
Received: from us-smtp-delivery-194.mimecast.com (us-smtp-delivery-194.mimecast.com [63.128.21.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 763121243F3 for <nfsv4@ietf.org>; Thu, 27 Jul 2017 00:50:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=PrimaryData.onmicrosoft.com; s=selector1-primarydata-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=oqqGJGfrg4YT4qKcjgWkg/qteCl9+8LfRcEOHlo3gBY=; b=YbSVXjRLxiFxB6GXbbbXTJI4zuZzYp31BDJvUPUcAOuK7q7JixaPcPtvKv7zemoF3zJD+zj2FMhO+Dbksv5imNMoyTB7ePuKMvpHhuf5/Ca/437ypfZ+oDyVesRXavrBDTGarctTmZN4WL7g4xoQmVxXRXXxr+ud6Qn7agoKZA4=
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01lp0177.outbound.protection.outlook.com [216.32.180.177]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-126-n4PJkcuJMcCLam84V7k7HQ-1; Thu, 27 Jul 2017 03:50:11 -0400
Received: from BY2PR1101MB1093.namprd11.prod.outlook.com (10.164.166.21) by BY2PR1101MB1093.namprd11.prod.outlook.com (10.164.166.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.10; Thu, 27 Jul 2017 07:50:09 +0000
Received: from BY2PR1101MB1093.namprd11.prod.outlook.com ([10.164.166.21]) by BY2PR1101MB1093.namprd11.prod.outlook.com ([10.164.166.21]) with mapi id 15.01.1282.021; Thu, 27 Jul 2017 07:50:08 +0000
From: Thomas Haynes <loghyr@primarydata.com>
To: Thomas Haynes <loghyr@primarydata.com>
CC: Dave Noveck <davenoveck@gmail.com>, "nfsv4@ietf.org" <nfsv4@ietf.org>
Thread-Topic: [nfsv4] Review of draft-ietf-nfsv4-layout-types-05
Thread-Index: AQHTBaTdQhWCs7pLw0CEXjvm8BvsTaJnETQAgAA9cIA=
Date: Thu, 27 Jul 2017 07:50:08 +0000
Message-ID: <45B8939D-B244-4D2E-9BC3-4A4BCFE0B9AC@primarydata.com>
References: <CADaq8jfFg-C8=DFHyEyHxB1jRC03-7nzq0M1V9-BB4wBsg=otA@mail.gmail.com> <0291DF77-B3A1-4F08-9C25-B2A420A2D87B@primarydata.com>
In-Reply-To: <0291DF77-B3A1-4F08-9C25-B2A420A2D87B@primarydata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2601:647:4282:9b41:48b0:3c78:2be5:1ac7]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BY2PR1101MB1093; 20:4zn7pivEp3WUs9g90xi0LNWnGC68rGavtmCxrwScr8J2hSqbNRmpFDMqur4PPQF1ku33aKHaTW/zEBO+E5aMpMz/45/XvD3sBcAsQU4BARxwc+vdW6XPdl0hrAhgqUPOUu0L1HNexDiluagPtENLzQsm66Y4fSoP46walhVe11g=
x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(39830400002)(39400400002)(39450400003)(39410400002)(189002)(199003)(377454003)(24454002)(83716003)(97736004)(6486002)(3280700002)(50986999)(36756003)(110136004)(6246003)(38730400002)(2906002)(6200100001)(101416001)(8676002)(7736002)(76176999)(54356999)(3660700001)(478600001)(5660300001)(39060400002)(33656002)(14454004)(6862004)(77096006)(81166006)(236005)(81156014)(82746002)(99286003)(54906002)(6506006)(6436002)(106356001)(105586002)(53936002)(6512007)(25786009)(54896002)(53546010)(68736007)(86362001)(2950100002)(2900100001)(189998001)(6116002)(8936002)(4326008)(102836003)(229853002)(230783001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR1101MB1093; H:BY2PR1101MB1093.namprd11.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
x-ms-office365-filtering-correlation-id: 38aa7014-7e53-4dff-94c1-08d4d4c41a1a
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BY2PR1101MB1093;
x-ms-traffictypediagnostic: BY2PR1101MB1093:
x-exchange-antispam-report-test: UriScan:(158342451672863);
x-microsoft-antispam-prvs: <BY2PR1101MB1093CBB8C517C85816BADEF1CEBE0@BY2PR1101MB1093.namprd11.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123562025)(20161123555025)(20161123558100)(2016111802025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(6072148)(6043046)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BY2PR1101MB1093; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BY2PR1101MB1093;
x-forefront-prvs: 03818C953D
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
MIME-Version: 1.0
X-OriginatorOrg: primarydata.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jul 2017 07:50:08.1304 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 03193ed6-8726-4bb3-a832-18ab0d28adb7
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR1101MB1093
X-MC-Unique: n4PJkcuJMcCLam84V7k7HQ-1
Content-Type: multipart/alternative; boundary="_000_45B8939DB2444D2E9BC34A4BCFE0B9ACprimarydatacom_"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/CxN5UM0IaswewwSOiBanjlLYwpg>
Subject: Re: [nfsv4] Review of draft-ietf-nfsv4-layout-types-05
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 27 Jul 2017 07:50:19 -0000

On Jul 26, 2017, at 9:10 PM, Thomas Haynes <loghyr@primarydata.com<mailto:loghyr@primarydata.com>> wrote:

I have addressed all of these issues.

I also did a subsequent spell check run and caught 8 other issues. :-)


On Jul 25, 2017, at 5:19 PM, David Noveck <davenoveck@gmail.com<mailto:davenoveck@gmail.com>> wrote:



3.2.  Undocumented Protocol REQUIREMENTS

Suggest changing the section title to "Previously Undocumented Protocol REQUIREMENTS".

I think attention should paid to the differences between/among these requirements and to the fact that these all seem to be directed to the clients (and in one case the MDS) while the following paragraph refers to the ability of storage devices to meet them. ???  Note that:

  *   Items (1), (3), and (4) , are really not about what the client will or won't do.  Whatever rfc5661 says explicitly, it is clear that clients are supposed to respect layouts.  The real issue is whether the data storge evices are able to enforce these.
  *   Item (2) is a requirement on the MDS which doesn't reallly fit with the others.
  *   Item 5 is unclear.  Part of the difficulty is that responsibility for storage allocation is different for different layout types.  Another issue is the "i..e.".  Creating files is only one nsance of storge allocation but simply changing this to an "e.g." will not work.

I suggest starting the section as follows:

If one summarizes the requirements stated in Section 12 of [RFC5661], there are a number of matters in which it is clear that certain behaviors are necessary for the protocol to work while not being stated as explicit requirements.

A number of these concern the obligation of clients to respect layouts when making IO requests on the data storage devices:

This would be followed by what are currently  (1), (3), and (4). and then the following:

 Under the file layout type, the storage devices are able to reject any request made not conforming to these requirements.  However,for other known layout types, this not possible so that the burden of conforming is solely on the client with the data storage devices unable to directly detect violations.  For these layout types, special fencing operations may be necessary to enforce layout revocation.

Also included in this category are:

  *   The requirement for the MDS to perform IO operations directed to it.
  *   The need to provide appropriate storage allocation,whether to create or delete files or to extend or truncate existing ones.

The means to address these requirements will vary with the layout type.  Generally, the control protocol will be used to effect these, whether a purpose-built one, one identical to the storage protocol or a new standards-track control protocol.

The above may not be the final answer to the issues in this section but suggest starting there.


Got home and realized I rushed through the spell check and didn’t document what I did here:

3.2.  Previously Undocumented Protocol REQUIREMENTS

   While not explicitly stated as requirements in Section 12 of
   [RFC5661], the existing layout types do have more requirements that
   they need to enforce.

   The client has these obligations when making I/O requests to the
   storage devices:

   (1)  Clients MUST NOT perform I/O to the storage device if they do
        not have layouts for the files in question.

   (2)  Clients MUST NOT perform I/O operations outside of the specified
        ranges in the layout segment.

   (3)  Clients MUST NOT perform I/O operations which would be
        inconsistent with the iomode specified in the layout segments it
        holds.

   Under the file layout type, the storage devices are able to reject
   any request made not conforming to these requirements.  This may not
   be possible for other known layout types, which puts the burden of
   enforcing such violations solely on the client.  For these layout
   types:

   (1)  The metadata server MIGHT use fencing operations to the storage
        devices to enforce layout revocation against the client.

   (2)  The metadata server MUST allow the clients to perform data I/O
        against it, even if it has already granted the client a layout.
        A layout type might discourage such I/O, but it can not forbid
        it.

   (3)  The metadata server MUST be able to do storage allocation,
        whether that is to create, delete, extend, or truncate files.

   The means to address these requirements will vary with the layout
   type.  A control protocol will be used to effect these, whether a
   purpose-built one, one identical to the storage protocol, or a new
   standards-track control protocol.

By the way, I’m holding off on publishing updates since I do not
want to create moving targets. If people feel otherwise, I can push
new versions...