Re: [nfsv4] Fwd: New Version Notification for draft-haynes-nfsv4-flex-filesv2-00.txt

David Noveck <davenoveck@gmail.com> Tue, 08 August 2017 10:17 UTC

Return-Path: <davenoveck@gmail.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 2A3B01321A5 for <nfsv4@ietfa.amsl.com>; Tue, 8 Aug 2017 03:17:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 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, 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 (2048-bit key) header.d=gmail.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 7N_2PhzLDJyK for <nfsv4@ietfa.amsl.com>; Tue, 8 Aug 2017 03:17:02 -0700 (PDT)
Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (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 2781313219B for <nfsv4@ietf.org>; Tue, 8 Aug 2017 03:17:02 -0700 (PDT)
Received: by mail-io0-x232.google.com with SMTP id g71so11920499ioe.5 for <nfsv4@ietf.org>; Tue, 08 Aug 2017 03:17:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1tPn5ze3hE2tKWs7BD15p/irZecFD4qUfG6gOAmkI3w=; b=WwygUX3tOBnJcawELyDWJPVbe2t3RLKVrsLWDNEohy7kLVqWxE5jURYAhevBzsyvnR zMCoqecAEilJ2pUKGW30Gq8R0GpU5qV75RsLVwSdp2TkMMa+OSCj/pRPNrP79IL4nKqV HJG+d5s4wfG9/esaAPRoMPoiw0MQpMnQ6pIgSe2QRepe9P4m82U72n1D0tySM3G2pN97 l4eXWRyl4Fa0VccUeFfbUfLUmw8qQ5E9b+7JWsdb62+jofPF9eeVMs5lmOHIKmIqVZcJ kFuFgrn2f5hRuzuRQ7SwwlHdwPmvYp2cNB60q88RV0uSIpnL25aeD0dC22ft0vlOmKRI YvVg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1tPn5ze3hE2tKWs7BD15p/irZecFD4qUfG6gOAmkI3w=; b=diEab5Edj6zB5zPjcZ+j60C+lpm996GPs7kQmCpAZ14PBGtiq0T5qROM3VMQiC8o1T 3eNFarX1uGrKZa7+EHbaMWIliCEhiSG6u4PxultsQlglvmi4tvwPuckG5v3683qw09ka uj+hFWGwt/SN/Pq0h8VPPLGVhUjrgp8OgbzFk6jz1dBJj7KXAjUqOfAh5LId/sDV5eyW eM3iRMdzISrnnxSPrDsqDAUiX5tls4uTfq/AV1zfNTQ5Gckx5vFVOCAWk3DOj0yMQqEe TFoPWBnAOOaxG991Qw4Nq2GLUKqDCUB/VMs5Q/O+0Dls63jyhm5scX8GqXGMnBFAl3x2 M3YQ==
X-Gm-Message-State: AHYfb5gN+oX8TJV3KYh7Rwd5AGCr1GKrJhDavvh8HiXN/Z5DnuTMuB2+ AOxsDj9Rtx4gCwM9bSQZmUGeIC8Lfg==
X-Received: by 10.107.19.222 with SMTP id 91mr2925447iot.313.1502187421326; Tue, 08 Aug 2017 03:17:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.142.72 with HTTP; Tue, 8 Aug 2017 03:17:00 -0700 (PDT)
In-Reply-To: <2CA259E3-BD3A-482B-BFBF-3B90425AD3EA@primarydata.com>
References: <150215110527.12392.18161698955589691126.idtracker@ietfa.amsl.com> <2CA259E3-BD3A-482B-BFBF-3B90425AD3EA@primarydata.com>
From: David Noveck <davenoveck@gmail.com>
Date: Tue, 8 Aug 2017 06:17:00 -0400
Message-ID: <CADaq8jekZoDmziLUh1Vr=MJxVfAj1T=Vv-+EC5Hm89LMt+vrww@mail.gmail.com>
To: Thomas Haynes <loghyr@primarydata.com>
Cc: "nfsv4@ietf.org" <nfsv4@ietf.org>
Content-Type: multipart/alternative; boundary="001a113f9264a266a305563b436b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/wApHVbG0Hn679q6kqiUOUmqVON8>
Subject: Re: [nfsv4] Fwd: 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 10:17:05 -0000

> 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.  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.

On Mon, Aug 7, 2017 at 8:25 PM, Thomas Haynes <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>
> *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>
>
>
> 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.
>
> The IETF Secretariat
>
>
>
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
>
>