IETF Logo Mail Archive

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

Spencer Shepler <sshepler@microsoft.com> Thu, 07 July 2011 19:34 UTC

Return-Path: <sshepler@microsoft.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 13FFD11E80AA for <nfsv4@ietfa.amsl.com>; Thu, 7 Jul 2011 12:34:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.532
X-Spam-Level:
X-Spam-Status: No, score=-10.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 saD-VRhlyH25 for <nfsv4@ietfa.amsl.com>; Thu, 7 Jul 2011 12:34:30 -0700 (PDT)
Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 76B2E11E80A9 for <nfsv4@ietf.org>; Thu, 7 Jul 2011 12:34:30 -0700 (PDT)
Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 7 Jul 2011 12:34:29 -0700
Received: from TK5EX14MBXC124.redmond.corp.microsoft.com ([169.254.4.62]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.01.0289.008; Thu, 7 Jul 2011 12:34:29 -0700
From: Spencer Shepler <sshepler@microsoft.com>
To: "david.black@emc.com" <david.black@emc.com>
Thread-Topic: [nfsv4] FW: New Version Notification for draft-faibish-nfsv4-pnfs-block-disk-protection-01.txt
Thread-Index: AQHMPMzEItXlWF0fnEmmQvqc/labQ5ThNfuwgAAGDfCAAAMMYA==
Date: Thu, 07 Jul 2011 19:34:29 +0000
Message-ID: <E043D9D8EE3B5743B8B174A814FD584F1FDC0FAC@TK5EX14MBXC124.redmond.corp.microsoft.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>
In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E0589392B28@MX14A.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.71]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "nfsv4@ietf.org" <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:34:31 -0000


> -----Original Message-----
> From: david.black@emc.com [mailto:david.black@emc.com]
> Sent: Thursday, July 07, 2011 12:22 PM
> To: Spencer Shepler
> Cc: nfsv4@ietf.org
> Subject: RE: [nfsv4] FW: New Version Notification for draft-faibish-nfsv4-
> pnfs-block-disk-protection-01.txt
> 
> > 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?
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?

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"?

Spencer

v2.23.0 | Report a Bug | By Email