draft-ietf-nfsv4-pnfs-block-11.txt   draft-ietf-nfsv4-pnfs-block-12.txt 
NFSv4 Working Group D. Black NFSv4 Working Group D. Black
Internet Draft S. Fridella Internet Draft EMC Corporation
Expires: June 12, 2009 J. Glasgow Expires: June 25, 2009 S. Fridella
Intended Status: Proposed Standard EMC Corporation Intended Status: Proposed Standard EMC Corporation
December 9, 2008 J. Glasgow
Google
December 22, 2008
pNFS Block/Volume Layout pNFS Block/Volume Layout
draft-ietf-nfsv4-pnfs-block-11.txt draft-ietf-nfsv4-pnfs-block-12.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that This Internet-Draft is submitted to IETF in full conformance with the
any applicable patent or other IPR claims of which he or she is provisions of BCP 78 and BCP 79.
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire in May 2009. This Internet-Draft will expire on June 25, 2009.
Copyright Notice
Copyright (c) 2008 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Abstract Abstract
Parallel NFS (pNFS) extends NFSv4 to allow clients to directly access Parallel NFS (pNFS) extends NFSv4 to allow clients to directly access
file data on the storage used by the NFSv4 server. This ability to file data on the storage used by the NFSv4 server. This ability to
bypass the server for data access can increase both performance and bypass the server for data access can increase both performance and
parallelism, but requires additional client functionality for data parallelism, but requires additional client functionality for data
access, some of which is dependent on the class of storage used. The access, some of which is dependent on the class of storage used. The
main pNFS operations draft specifies storage-class-independent main pNFS operations draft specifies storage-class-independent
extensions to NFS; this draft specifies the additional extensions extensions to NFS; this draft specifies the additional extensions
skipping to change at page 2, line 13 skipping to change at page 2, line 25
based storage. based storage.
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119]. document are to be interpreted as described in RFC-2119 [RFC2119].
Table of Contents Table of Contents
1. Introduction.................................................. 3 Copyright Notice..................................................1
1.1. General Definitions ..................................... 3 1. Introduction...................................................4
1.2. XDR Description of NFSv4.1 block layout.................. 4 1.1. General Definitions.......................................4
2. Block Layout Description ..................................... 5 1.2. Code Components Licensing Notice..........................5
2.1. Background and Architecture ............................. 5 1.3. XDR Description...........................................5
2.2. GETDEVICELIST and GETDEVICEINFO.......................... 7 2. Block Layout Description.......................................8
2.2.1. Volume Identification............................... 7 2.1. Background and Architecture...............................8
2.2.2. Volume Topology..................................... 8 2.2. GETDEVICELIST and GETDEVICEINFO...........................9
2.2.3. GETDEVICELIST and GETDEVICEINFO deviceid4...........11 2.2.1. Volume Identification................................9
2.3. Data Structures: Extents and Extent Lists................11 2.2.2. Volume Topology.....................................11
2.3.1. Layout Requests and Extent Lists....................14 2.2.3. GETDEVICELIST and GETDEVICEINFO deviceid4...........14
2.3.2. Layout Commits .....................................15 2.3. Data Structures: Extents and Extent Lists................14
2.3.3. Layout Returns .....................................16 2.3.1. Layout Requests and Extent Lists....................17
2.3.4. Client Copy-on-Write Processing.....................16 2.3.2. Layout Commits......................................18
2.3.5. Extents are Permissions.............................18 2.3.3. Layout Returns......................................19
2.3.6. End-of-file Processing .............................19 2.3.4. Client Copy-on-Write Processing.....................19
2.3.7. Layout Hints........................................20 2.3.5. Extents are Permissions.............................21
2.3.8. Client Fencing .....................................20 2.3.6. End-of-file Processing..............................22
2.4. Crash Recovery Issues....................................22 2.3.7. Layout Hints........................................23
2.5. Recalling resources: CB_RECALL_ANY ......................23 2.3.8. Client Fencing......................................23
2.6. Transient and Permanent Errors...........................23 2.4. Crash Recovery Issues....................................25
3. Security Considerations.......................................24 2.5. Recalling resources: CB_RECALL_ANY.......................26
4. Conclusions...................................................26 2.6. Transient and Permanent Errors...........................26
5. IANA Considerations...........................................26 3. Security Considerations.......................................27
6. Acknowledgments...............................................26 4. Conclusions...................................................29
7. References....................................................26 5. IANA Considerations...........................................29
7.1. Normative References.....................................26 6. Acknowledgments...............................................29
7.2. Informative References...................................27 7. References....................................................29
Author's Addresses...............................................27 7.1. Normative References.....................................29
Intellectual Property Statement..................................27 7.2. Informative References...................................30
Disclaimer of Validity...........................................28 Authors' Addresses...............................................30
Copyright Statement .............................................28
Acknowledgment...................................................28
1. Introduction 1. Introduction
Figure 1 shows the overall architecture of a Parallel NFS (pNFS) Figure 1 shows the overall architecture of a Parallel NFS (pNFS)
system: system:
+-----------+ +-----------+
|+-----------+ +-----------+ |+-----------+ +-----------+
||+-----------+ | | ||+-----------+ | |
||| | NFSv4.1 + pNFS | | ||| | NFSv4.1 + pNFS | |
skipping to change at page 4, line 39 skipping to change at page 5, line 39
1.3. XDR Description 1.3. XDR Description
This document contains the XDR ([XDR]) description of the NFSv4.1 This document contains the XDR ([XDR]) description of the NFSv4.1
block layout protocol. The XDR description is embedded in this block layout protocol. The XDR description is embedded in this
document in a way that makes it simple for the reader to extract into document in a way that makes it simple for the reader to extract into
a ready to compile form. The reader can feed this document into the a ready to compile form. The reader can feed this document into the
following shell script to produce the machine readable XDR following shell script to produce the machine readable XDR
description of the NFSv4.1 block layout: description of the NFSv4.1 block layout:
#!/bin/sh #!/bin/sh
grep '^ *///' | sed 's?^ */// ??' | sed 's?^ *///$??' $* grep '^ *///' $* | sed 's?^ */// ??' | sed 's?^ *///$??'
I.e. if the above script is stored in a file called "extract.sh", and I.e. if the above script is stored in a file called "extract.sh", and
this document is in a file called "spec.txt", then the reader can do: this document is in a file called "spec.txt", then the reader can do:
sh extract.sh < spec.txt > nfs4_block_layout_spec.x sh extract.sh < spec.txt > nfs4_block_layout_spec.x
The effect of the script is to remove both leading white space and a The effect of the script is to remove both leading white space and a
sentinel sequence of "///" from each matching line. sentinel sequence of "///" from each matching line.
The embedded XDR file header follows, with subsequent pieces embedded The embedded XDR file header follows, with subsequent pieces embedded
throughout the document: throughout the document:
/// /* /// /*
/// * This code was derived from IETF RFC &rfc.number. /// * This code was derived from IETF RFC &rfc.number.
[[RFC Editor: please insert RFC number if needed]] [[RFC Editor: please insert RFC number if needed]]
/// * Please reproduce this note if possible. /// * Please reproduce this note if possible.
/// */ /// */
/// /*
/// * Copyright (c) 2008 IETF Trust and the persons identified
/// * as the document authors. All rights reserved.
/// *
/// * Redistribution and use in source and binary forms, with
/// * or without modification, are permitted provided that the
/// * following conditions are met:
/// *
/// * o Redistributions of source code must retain the above
/// * copyright notice, this list of conditions and the
/// * following disclaimer.
/// *
/// * o Redistributions in binary form must reproduce the above
/// * copyright notice, this list of conditions and the
/// * following disclaimer in the documentation and/or other
/// * materials provided with the distribution.
/// *
/// * o Neither the name of Internet Society, IETF or IETF
/// * Trust, nor the names of specific contributors, may be
/// * used to endorse or promote products derived from this
/// * software without specific prior written permission.
/// *
/// * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS
/// * AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED
/// * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
/// * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
/// * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
/// * EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
/// * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
/// * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
/// * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
/// * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
/// * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
/// * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
/// * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
/// * IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
/// * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
/// */
/// ///
/// /* /// /*
/// * nfs4_block_layout_prot.x /// * nfs4_block_layout_prot.x
/// */ /// */
/// ///
/// %#include "nfsv41.h" /// %#include "nfsv41.h"
/// ///
The XDR code contained in this document depends on types from The XDR code contained in this document depends on types from
nfsv41.x file. This includes both nfs types that end with a 4, such nfsv41.x file. This includes both nfs types that end with a 4, such
skipping to change at page 6, line 31 skipping to change at page 9, line 22
writeable storage, and the corresponding read-only storage is no writeable storage, and the corresponding read-only storage is no
longer used. longer used.
The block/volume layout solution expands the security The block/volume layout solution expands the security
responsibilities of the pNFS clients and there are a number of responsibilities of the pNFS clients and there are a number of
environments where the mandatory to implement security properties for environments where the mandatory to implement security properties for
NFS cannot be satisfied. The additional security responsibilities of NFS cannot be satisfied. The additional security responsibilities of
the client follow, and a full discussion is present in Section 3 the client follow, and a full discussion is present in Section 3
"Security Considerations". "Security Considerations".
o Typically, storage array network (SAN) disk arrays and SAN o Typically, storage area network (SAN) disk arrays and SAN
protocols provide access control mechanisms (e.g., logical unit protocols provide access control mechanisms (e.g., logical unit
number mapping and/or masking) which operate at the granularity of number mapping and/or masking) which operate at the granularity of
individual hosts, not individual blocks. For this reason, block- individual hosts, not individual blocks. For this reason, block-
based protection must be provided by the client software. based protection must be provided by the client software.
o Similarly, SAN disk arrays and SAN protocols typically are not be o Similarly, SAN disk arrays and SAN protocols typically are not be
able to validate NFS locks that apply to file regions. For able to validate NFS locks that apply to file regions. For
instance, if a file is covered by a mandatory read-only lock, the instance, if a file is covered by a mandatory read-only lock, the
server can ensure that only readable layouts for the file are server can ensure that only readable layouts for the file are
granted to pNFS clients. However, it is up to each pNFS client to granted to pNFS clients. However, it is up to each pNFS client to
skipping to change at page 26, line 45 skipping to change at page 29, line 45
7.1. Normative References 7.1. Normative References
[LEGAL] IETF Trust, "Legal Provisions Relating to IETF Documents", [LEGAL] IETF Trust, "Legal Provisions Relating to IETF Documents",
URL http://trustee.ietf.org/docs/IETF-Trust-License- URL http://trustee.ietf.org/docs/IETF-Trust-License-
Policy.pdf, November 2008. Policy.pdf, November 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[NFSV4.1] Shepler, S., Eisler, M., and Noveck, D. ed., "NFSv4 Minor [NFSV4.1] Shepler, S., Eisler, M., and Noveck, D. ed., "NFSv4 Minor
Version 1", draft-ietf-nfsv4-minorversion1-26.txt, Internet Version 1", RFC [[RFC Editor: please insert NFSv4 Minor
Draft, September 2008. Version 1 RFC number]], [[RFC Editor: please insert NFSv4
Minor Version 1 RFC month]] [[RFC Editor: please insert
NFSv4 Minor Version 1 year].
<http://www.ietf.org/rfc/rfc[[RFC Editor: please insert
NFSv4 Minor Version 1 RFC number]].txt>.
[XDR] Eisler, M., "XDR: External Data Representation Standard", [XDR] Eisler, M., "XDR: External Data Representation Standard",
STD 67, RFC 4506, May 2006. STD 67, RFC 4506, May 2006.
7.2. Informative References 7.2. Informative References
[MPFS] EMC Corporation, "EMC Celerra Multi-Path File System", EMC [MPFS] EMC Corporation, "EMC Celerra Multi-Path File System", EMC
Data Sheet, available at: Data Sheet, available at:
http://www.emc.com/collateral/software/data-sheet/h2006-celerra-mpfs- http://www.emc.com/collateral/software/data-sheet/h2006-celerra-mpfs-
mpfsi.pdf mpfsi.pdf
skipping to change at page 27, line 41 skipping to change at line 1222
Phone: +1 (508) 249-3528 Phone: +1 (508) 249-3528
Email: fridella_stephen@emc.com Email: fridella_stephen@emc.com
Jason Glasgow Jason Glasgow
Google Google
5 Cambridge Center 5 Cambridge Center
Cambridge, MA 02142 Cambridge, MA 02142
Phone: +1 (617) 575 1599 Phone: +1 (617) 575 1599
Email: jglasgow@aya.yale.edu Email: jglasgow@aya.yale.edu
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 11 change blocks. 
47 lines changed or deleted 98 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/