Re: [nfsv4] FW: New Version Notification for draft-faibish-nfsv4-pnfs-block-disk-protection-01.txt

<david.black@emc.com> Thu, 07 July 2011 19:48 UTC

Return-Path: <david.black@emc.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 4BC6621F8714 for <nfsv4@ietfa.amsl.com>; Thu, 7 Jul 2011 12:48:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.745
X-Spam-Level:
X-Spam-Status: No, score=-105.745 tagged_above=-999 required=5 tests=[AWL=0.854, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mX28gb4NXzVl for <nfsv4@ietfa.amsl.com>; Thu, 7 Jul 2011 12:48:04 -0700 (PDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id ABBAA21F870A for <nfsv4@ietf.org>; Thu, 7 Jul 2011 12:47:58 -0700 (PDT)
Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p67JlviJ012423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Jul 2011 15:47:57 -0400
Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.251]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Thu, 7 Jul 2011 15:47:50 -0400
Received: from mxhub13.corp.emc.com (mxhub13.corp.emc.com [128.221.56.102]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p67JlKF2017480; Thu, 7 Jul 2011 15:47:20 -0400
Received: from mx14a.corp.emc.com ([169.254.1.245]) by mxhub13.corp.emc.com ([128.221.56.102]) with mapi; Thu, 7 Jul 2011 15:47:20 -0400
From: david.black@emc.com
To: sshepler@microsoft.com
Date: Thu, 07 Jul 2011 15:47:19 -0400
Thread-Topic: [nfsv4] FW: New Version Notification for draft-faibish-nfsv4-pnfs-block-disk-protection-01.txt
Thread-Index: AQHMPMzEItXlWF0fnEmmQvqc/labQ5ThNfuwgAAGDfCAAAMMYIAAArGg
Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E0589392B33@MX14A.corp.emc.com>
References: <7C4DFCE962635144B8FAE8CA11D0BF1E0589392870@MX14A.corp.emc.com> <4E15C1B5.5070600@tonian.com> <op.vx8679iyunckof@usensfaibisl2e.eng.emc.com> <1746881557-1310051155-cardhu_decombobulator_blackberry.rim.net-585899366-@b27.c3.bise3.blackberry> <7C4DFCE962635144B8FAE8CA11D0BF1E0589392A9A@MX14A.corp.emc.com> <4E15E259.2090208@tonian.com> <20110707170428.GA26714@merit.edu> <CAP_8SaeM5fn7uLXoOU8XsQ4hdRZP=eLXhi7p51kaFHDOyJ7uyQ@mail.gmail.com> <CAP_8SacPC9nSMOe_jtjpWaP6Vv2ouQf+Fgi7wmBNpWehDJR0hw@mail.gmail.com> <E043D9D8EE3B5743B8B174A814FD584F1FDC0E14@TK5EX14MBXC124.redmond.corp.microsoft.com> <7C4DFCE962635144B8FAE8CA11D0BF1E0589392B28@MX14A.corp.emc.com> <E043D9D8EE3B5743B8B174A814FD584F1FDC0FAC@TK5EX14MBXC124.redmond.corp.microsoft.com>
In-Reply-To: <E043D9D8EE3B5743B8B174A814FD584F1FDC0FAC@TK5EX14MBXC124.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-EMM-MHVC: 1
Cc: nfsv4@ietf.org
Subject: Re: [nfsv4] FW: New Version Notification for draft-faibish-nfsv4-pnfs-block-disk-protection-01.txt
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.12
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: <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, 07 Jul 2011 19:48:05 -0000

> > > Finally, if there exist two block pNFS implementations, wouldn’t there
> > > be a desire (potentially) to have a different GUID value for each?
> >
> > No.  The goal is to have a single GUID that can be used by all pNFS block
> > implementations to enable operating systems to prevent non-pNFS access to
> > devices used for block pNFS data.  Actual claiming of a pNFS block device
> > for use with a particular implementation happens via the pNFS protocol,
> > but that can't be used early in an OS boot sequence.
> 
> The pNFS block client won't differentiate but the pNFS block MDS may, right?

Not based on the GPT using this GUID.  The MDS is free to add another GUID to
the GPT for other purposes, but checking for a superblock for the MDS's physical
filesystem layout is a more likely mechanism.

> The MDS will certainly scan available devices and determine which are
> within its purview.  It is then assumed that all will have the same GUID
> and that additional information beyond the GPT/GUID will identify
> implementation type and then file system structure.  It then is assumed
> that this is left as an exercise to the MDS server implementation?

Yes - it already works this way today, although the MDS scan will typically not
see block devices that aren't supposed to be used by the MDS.

> That is all fine; a brief summary of that would be helpful in the I-D.
> 
> BTW: if there is only one GUID, then the "SHOULD" in the I-D should
> be a "MUST"?

"SHOULD" was used because it's up to implementers to decide whether to implement
this. The requirement could be rephrased as a conditional "MUST" - if the
implementation uses GPT access protection of pNFS block devices, then this GUID
MUST be used.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
david.black@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------