[nfsv4] Comments on draft-faibish-nfsv4-pnfs-block-disk-protection-00

Jim Rees <rees@umich.edu> Thu, 24 March 2011 23:31 UTC

Return-Path: <rees@umich.edu>
X-Original-To: nfsv4@core3.amsl.com
Delivered-To: nfsv4@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14F9B3A6916 for <nfsv4@core3.amsl.com>; Thu, 24 Mar 2011 16:31:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.392
X-Spam-Level:
X-Spam-Status: No, score=-5.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+Bpgj9KFN17 for <nfsv4@core3.amsl.com>; Thu, 24 Mar 2011 16:31:56 -0700 (PDT)
Received: from int-mailstore01.merit.edu (int-mailstore01.merit.edu [207.75.116.232]) by core3.amsl.com (Postfix) with ESMTP id D127F3A6911 for <nfsv4@ietf.org>; Thu, 24 Mar 2011 16:31:56 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by int-mailstore01.merit.edu (Postfix) with ESMTP id AB46B305735D for <nfsv4@ietf.org>; Thu, 24 Mar 2011 19:33:31 -0400 (EDT)
X-Virus-Scanned: amavisd-new at int-mailstore01.merit.edu
Received: from int-mailstore01.merit.edu ([127.0.0.1]) by localhost (int-mailstore01.merit.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZQm0jO3+oor for <nfsv4@ietf.org>; Thu, 24 Mar 2011 19:33:31 -0400 (EDT)
Received: from merit.edu (74-126-0-171.static.123.net [74.126.0.171]) by int-mailstore01.merit.edu (Postfix) with ESMTPSA id 36C663055C16 for <nfsv4@ietf.org>; Thu, 24 Mar 2011 19:33:31 -0400 (EDT)
Date: Thu, 24 Mar 2011 19:33:30 -0400
From: Jim Rees <rees@umich.edu>
To: nfsv4@ietf.org
Message-ID: <20110324233330.GB15033@merit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Subject: [nfsv4] Comments on draft-faibish-nfsv4-pnfs-block-disk-protection-00
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 24 Mar 2011 23:31:58 -0000

Here are my comments on draft-faibish-nfsv4-pnfs-block-disk-protection-00

1. The Introduction seems confusing.  I think it needs a more concise
problem statement.  The statement in section 4.1 is good.

2. Another use case:  A SAN is exporting several LUNS, all of which are pnfs
volumes.  But the MDS the client is talking to only uses a subset of these
volumes; the others are used by a different MDS that the client is not
talking to (does not have mounted).  In this case, even after the client
sends the GETDEVICELIST, it still doesn't have the complete list of all pnfs
volumes.

3. A possible problem.  Is it always the case that the pnfs volumes are
dedicated to pnfs and never used for anything else?  The case I'm thinking
of is where a server is exporting a partition that holds, for example, an
ext4 file system.  The server could mount the partition locally, or it could
export it as a data partition over iscsi for pnfs (probably at different
times).  The same partition would require two different GUIDs.  Or what
about an LVM partition that holds pnfs data blocks?

4. Not stated in the draft, I think most OSes already read the partition
table of each device at the time its attached (at boot for local disks and
at login time for iscsi), so the draft doesn't impose any undue burden.
It's an implementation point but maybe worth mentioning.

5. Sort of glossed over is the requirement that each volume have a GPT.  But
I guess that's ok.