Re: [nfsv4] New Version Notification for draft-haynes-nfsv4-flex-filesv2-00.txt
Thomas Haynes <loghyr@primarydata.com> Tue, 08 August 2017 23:18 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 AC5D1126E64 for <nfsv4@ietfa.amsl.com>; Tue, 8 Aug 2017 16:18:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=primarydata.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 h9IhLkaNhGy8 for <nfsv4@ietfa.amsl.com>; Tue, 8 Aug 2017 16:18:02 -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 E1BF6127058 for <nfsv4@ietf.org>; Tue, 8 Aug 2017 16:18:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=primarydata.com; s=mimecast20170802; t=1502234281; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references; bh=+zaA8pDK16rt0W9vfwZdIS9zEauy4phS9opksn+bECU=; b=LcXxQcOPvjN9J0IYF2KqhZ7K92pA8PguFBkLUPrHFXgInMxgh1xgYveiC3+24ft5vsPqxfwrNyA6F2LX9RlAbnuZ5Q+DJJaMcn6NeL+VY3h6/KKvVGj7NHj9LZcPXzqvaFV/9FJP18FHf95jQ0aW2K/dFTDur4KAilfS8dwJgqA=
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03lp0054.outbound.protection.outlook.com [216.32.180.54]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-182-KaTbXlixNSC34gYohJzcqw-1; Tue, 08 Aug 2017 19:17:56 -0400
Received: from BY2PR1101MB1093.namprd11.prod.outlook.com (10.164.166.21) by BY2PR1101MB1094.namprd11.prod.outlook.com (10.164.166.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1320.16; Tue, 8 Aug 2017 23:17:54 +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.1320.018; Tue, 8 Aug 2017 23:17:54 +0000
From: Thomas Haynes <loghyr@primarydata.com>
To: Dave Noveck <davenoveck@gmail.com>
CC: "nfsv4@ietf.org" <nfsv4@ietf.org>
Thread-Topic: [nfsv4] New Version Notification for draft-haynes-nfsv4-flex-filesv2-00.txt
Thread-Index: AQHTEJyQy9ixOQ7N/kCNCfQ0ROZ9OA==
Date: Tue, 08 Aug 2017 23:17:54 +0000
Message-ID: <23C37CB0-91CC-4301-A46F-323C49F5F637@primarydata.com>
References: <150215110527.12392.18161698955589691126.idtracker@ietfa.amsl.com> <2CA259E3-BD3A-482B-BFBF-3B90425AD3EA@primarydata.com> <CADaq8jekZoDmziLUh1Vr=MJxVfAj1T=Vv-+EC5Hm89LMt+vrww@mail.gmail.com>
In-Reply-To: <CADaq8jekZoDmziLUh1Vr=MJxVfAj1T=Vv-+EC5Hm89LMt+vrww@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [63.157.6.18]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BY2PR1101MB1094; 20:KNsiq3WqRRw2ghas9dd2/aBKs/bQNFDUnWTcGYNvDiTlKGxn+xx0ibP/7gAyfqvA+KR3+hvGxTjeAzFKws5G4eYuzmVC3AAdeRlL7Fl/OTxwQPxGBpW/vVrhdboOHPtHwIxrUFAPAXgxhGTh8HdgbSbgBb5XeRQxUOThi6gaeWI=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: f87e584d-7aff-40fc-f5db-08d4deb3b2b9
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(2017082002075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BY2PR1101MB1094;
x-ms-traffictypediagnostic: BY2PR1101MB1094:
x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105)(192374486261705)(17755550239193);
x-microsoft-antispam-prvs: <BY2PR1101MB1094FAA450FFCB2EF31E7E29CE8A0@BY2PR1101MB1094.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)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6041248)(2016111802025)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(20161123562025)(6043046)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BY2PR1101MB1094; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BY2PR1101MB1094;
x-forefront-prvs: 03932714EB
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39410400002)(39400400002)(39450400003)(39830400002)(377424004)(377454003)(199003)(24454002)(189002)(66066001)(2950100002)(53546010)(6916009)(83716003)(5660300001)(606006)(68736007)(97736004)(86362001)(14454004)(8676002)(82746002)(7736002)(38730400002)(478600001)(39060400002)(8936002)(110136004)(76176999)(3846002)(4326008)(2420400007)(105586002)(54356999)(101416001)(189998001)(50986999)(102836003)(6436002)(966005)(229853002)(6486002)(3660700001)(25786009)(81156014)(81166006)(6116002)(15650500001)(6246003)(3280700002)(10710500007)(1411001)(6506006)(6306002)(236005)(2900100001)(99286003)(106356001)(6512007)(2906002)(77096006)(230783001)(33656002)(54896002)(36756003)(53936002)(7110500001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR1101MB1094; H:BY2PR1101MB1093.namprd11.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
MIME-Version: 1.0
X-OriginatorOrg: primarydata.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Aug 2017 23:17:54.3251 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 03193ed6-8726-4bb3-a832-18ab0d28adb7
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR1101MB1094
X-MC-Unique: KaTbXlixNSC34gYohJzcqw-1
Content-Type: multipart/alternative; boundary="_000_23C37CB091CC4301A46F323C49F5F637primarydatacom_"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/vTpbeHON7kQbHPe-R2yt78aLRFk>
Subject: Re: [nfsv4] New Version Notification for draft-haynes-nfsv4-flex-filesv2-00.txt
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: Tue, 08 Aug 2017 23:18:05 -0000
On Aug 8, 2017, at 3:17 AM, David Noveck <davenoveck@gmail.com<mailto:davenoveck@gmail.com>> wrote: > And Ben, the other reason not to use a typed opaque auth blob > is because the ffds_user and ffds_group are strings, and do > not fit into AUTH_UNIX. I don''t see how the fact that ffds_user and ffds_group, being strings, do not fit into AUTH_UNIX can be argument for retaining them. My argument would be the minimal set of changes necessary to make a ffv2 implementation. One thing about the synthetic ids are that they are used to fence as much as they are used as credentials. This may mean that we need both the ids and the auth field. If the existence of AUTH_UNIX is relevant to the matter, it would argue for deleting ffds_user and ffds_group and subsuming them both within ffds_auth. The situation is the same regarding the fact there might be arrays of these things. Clearly, if one of these items needs to be an array, they all do.. If that's the case, it would be better to have one potentially troublesome array rather than three. After having some time to think about this, I believe I have difference between these and the other fields. Both the stateid and file handles are generated by the storage device - with loose coupling, we cannot do anything to modify these. However, the synthetic ids, the auth token, and the mode bits (which are never discussed but which play an important role), can be set by the metadata server. So we can mandate that they are all the same across each instance of the data file. If they are not, then the client will inform the metadata server in a LAYOUT_ERROR (or LAYOUT_RETURN) that it cannot access the data and then the metadata server can repair the access (mode/ids/auth token). The auth token is not directly modifiable, but as the storage device validates it to the private auth server, this should be sufficient. On Mon, Aug 7, 2017 at 8:25 PM, Thomas Haynes <loghyr@primarydata.com<mailto:loghyr@primarydata.com>> wrote: So here is a first hack at Flex Files v2. I thought it would come in much smaller than 11 pages, so perhaps some pruning will be necessary. I’m aware Ben had some comments on: Can I suggest putting in a typed opaque auth blob instead of explicit synthetic uid/gid fields? I have purposely done: /// struct ffv2_data_server4 { /// deviceid4 ffds_deviceid; /// uint32_t ffds_efficiency; /// stateid4 ffds_stateid<>; /// nfs_fh4 ffds_fh_vers<>; /// fattr4_owner ffds_user; /// fattr4_owner_group ffds_group; /// opaque_auth ffds_auth; /// }; Because of AI1: [[AI1: after the lesson learned from ffds_stateid, we either need to put an array here or define all of the file handles to share the same credentials. And as Olga points out in her email, this gets big fast. Especially if we throw in many mirrored copies! --TH]] I.e., the ffds_auth is inside an array of ffv2_data_server4 which is in itself inside an array of ffv2_mirror4 AND it could be argued that ffds_auth (and ffds_user/ffds_group) need to be an array. Even if we decide to make all FHs share the same credentials, we eventually can hit a limit of the number of mirrored copies. And Ben, the other reason not to use a typed opaque auth blob is because the ffds_user and ffds_group are strings, and do not fit into AUTH_UNIX. We could define AUTH_SYNTHETIC. :-) Begin forwarded message: From: <internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>> Subject: New Version Notification for draft-haynes-nfsv4-flex-filesv2-00.txt Date: August 7, 2017 at 5:11:45 PM PDT To: Thomas Haynes <thomas.haynes@primarydata.com<mailto:thomas.haynes@primarydata.com>> A new version of I-D, draft-haynes-nfsv4-flex-filesv2-00.txt has been successfully submitted by Thomas Haynes and posted to the IETF repository. Name: draft-haynes-nfsv4-flex-filesv2 Revision: 00 Title: Parallel NFS (pNFS) Flexible File Layout v2 Document date: 2017-08-07 Group: Individual Submission Pages: 11 URL: https://www.ietf.org/internet-drafts/draft-haynes-nfsv4-flex-filesv2-00.txt Status: https://datatracker.ietf.org/doc/draft-haynes-nfsv4-flex-filesv2/ Htmlized: https://tools.ietf.org/html/draft-haynes-nfsv4-flex-filesv2-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-haynes-nfsv4-flex-filesv2-00 Abstract: The Parallel Network File System (pNFS) allows a separation between the metadata (onto a metadata server) and data (onto a storage device) for a file. The flexible file layout type is an extension to pNFS which allows the use of storage devices in a fashion such that they require only a quite limited degree of interaction with the metadata server, using already existing protocols. This document describes two extensions to the flexible file layout type to allow for multiple stateids for tightly coupled NFSv4 models and an additional security mechanism for loosely coupled models. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org/>. The IETF Secretariat _______________________________________________ nfsv4 mailing list nfsv4@ietf.org<mailto:nfsv4@ietf.org> https://www.ietf.org/mailman/listinfo/nfsv4
- [nfsv4] Fwd: New Version Notification for draft-h… Thomas Haynes
- Re: [nfsv4] Fwd: New Version Notification for dra… David Noveck
- Re: [nfsv4] Fwd: New Version Notification for dra… Olga Kornievskaia
- Re: [nfsv4] Fwd: New Version Notification for dra… Trond Myklebust
- Re: [nfsv4] Fwd: New Version Notification for dra… Benjamin Kaduk
- Re: [nfsv4] Fwd: New Version Notification for dra… Olga Kornievskaia
- Re: [nfsv4] Fwd: New Version Notification for dra… Trond Myklebust
- Re: [nfsv4] Fwd: New Version Notification for dra… Benjamin Kaduk
- Re: [nfsv4] Fwd: New Version Notification for dra… Olga Kornievskaia
- Re: [nfsv4] Fwd: New Version Notification for dra… Benjamin Kaduk
- Re: [nfsv4] Fwd: New Version Notification for dra… Olga Kornievskaia
- Re: [nfsv4] Fwd: New Version Notification for dra… Trond Myklebust
- Re: [nfsv4] Fwd: New Version Notification for dra… Olga Kornievskaia
- Re: [nfsv4] Fwd: New Version Notification for dra… Trond Myklebust
- Re: [nfsv4] Fwd: New Version Notification for dra… Olga Kornievskaia
- Re: [nfsv4] New Version Notification for draft-ha… Thomas Haynes
- Re: [nfsv4] New Version Notification for draft-ha… Thomas Haynes
- Re: [nfsv4] Fwd: New Version Notification for dra… Benjamin Kaduk
- Re: [nfsv4] Fwd: New Version Notification for dra… Trond Myklebust
- Re: [nfsv4] Fwd: New Version Notification for dra… Olga Kornievskaia
- Re: [nfsv4] Fwd: New Version Notification for dra… Trond Myklebust
- [nfsv4] Minorversioning [was Re: New Version Noti… Thomas Haynes
- Re: [nfsv4] Minorversioning [was Re: New Version … David Noveck
- Re: [nfsv4] Fwd: New Version Notification for dra… J. Bruce Fields
- Re: [nfsv4] Fwd: New Version Notification for dra… Benjamin Kaduk