draft-ietf-nfsv4-pnfs-block-06.txt   draft-ietf-nfsv4-pnfs-block-07.txt 
NFSv4 Working Group David L. Black NFSv4 Working Group D. Black
Internet Draft Stephen Fridella Internet Draft S. Fridella
Expires: August 25, 2008 Jason Glasgow Expires: September 17, 2008 J. Glasgow
Intended Status: Proposed Standard EMC Corporation Intended Status: Proposed Standard EMC Corporation
February 25, 2008 March 17, 2008
pNFS Block/Volume Layout pNFS Block/Volume Layout
draft-ietf-nfsv4-pnfs-block-06.txt draft-ietf-nfsv4-pnfs-block-07.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she 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 becomes aware will be disclosed, in accordance with Section 6 of
BCP 79. BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 September 2007. This Internet-Draft will expire in September 2008.
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 23 skipping to change at page 2, line 23
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
1.1. General Definitions.......................................3 1.1. General Definitions.......................................3
1.2. XDR Description of NFSv4.1 block layout...................4 1.2. XDR Description of NFSv4.1 block layout...................4
2. Block Layout Description.......................................5 2. Block Layout Description.......................................5
2.1. Background and Architecture...............................5 2.1. Background and Architecture...............................5
2.2. GETDEVICELIST and GETDEVICEINFO...........................6 2.2. GETDEVICELIST and GETDEVICEINFO...........................6
2.2.1. Volume Identification................................6 2.2.1. Volume Identification................................6
2.2.2. Volume Topology......................................7 2.2.2. Volume Topology......................................7
2.2.3. GETDEVICELIST and GETDEVICEINFO deviceid4............9 2.2.3. GETDEVICELIST and GETDEVICEINFO deviceid4...........10
2.3. Data Structures: Extents and Extent Lists................10 2.3. Data Structures: Extents and Extent Lists................10
2.3.1. Layout Requests and Extent Lists....................12 2.3.1. Layout Requests and Extent Lists....................13
2.3.2. Layout Commits......................................13 2.3.2. Layout Commits......................................14
2.3.3. Layout Returns......................................14 2.3.3. Layout Returns......................................14
2.3.4. Client Copy-on-Write Processing.....................14 2.3.4. Client Copy-on-Write Processing.....................15
2.3.5. Extents are Permissions.............................16 2.3.5. Extents are Permissions.............................16
2.3.6. End-of-file Processing..............................17 2.3.6. End-of-file Processing..............................18
2.3.7. Layout Hints........................................18 2.3.7. Layout Hints........................................18
2.3.8. Client Fencing......................................18 2.3.8. Client Fencing......................................19
2.4. Crash Recovery Issues....................................20 2.4. Crash Recovery Issues....................................21
2.5. Recalling resources: CB_RECALL_ANY.......................21 2.5. Recalling resources: CB_RECALL_ANY.......................21
2.6. Transient and Permanent Errors...........................21 2.6. Transient and Permanent Errors...........................22
3. Security Considerations.......................................22 3. Security Considerations.......................................22
4. Conclusions...................................................23 4. Conclusions...................................................24
5. IANA Considerations...........................................23 5. IANA Considerations...........................................24
6. Acknowledgments...............................................23 6. Acknowledgments...............................................24
7. References....................................................24 7. References....................................................24
7.1. Normative References.....................................24 7.1. Normative References.....................................25
7.2. Informative References...................................24 7.2. Informative References...................................25
Authors' Addresses...............................................24 Author's Addresses...............................................25
Intellectual Property Statement..................................25 Intellectual Property Statement..................................26
Disclaimer of Validity...........................................25 Disclaimer of Validity...........................................26
Copyright Statement..............................................26 Copyright Statement..............................................27
Acknowledgment...................................................26 Acknowledgment...................................................27
1. Introduction 1. Introduction
Figure 1 shows the overall architecture of a pNFS system: Figure 1 shows the overall architecture of a pNFS system:
+-----------+ +-----------+
|+-----------+ +-----------+ |+-----------+ +-----------+
||+-----------+ | | ||+-----------+ | |
||| | NFSv4.1 + pNFS | | ||| | NFSv4.1 + pNFS | |
+|| Clients |<------------------------------>| Server | +|| Clients |<------------------------------>| Server |
skipping to change at page 4, line 22 skipping to change at page 4, line 22
Server Server
The "Server" is the entity responsible for coordinating client The "Server" is the entity responsible for coordinating client
access to a set of file systems and is identified by a Server access to a set of file systems and is identified by a Server
owner. owner.
1.2. XDR Description 1.2. 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 embeded 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
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?^ *///??' grep "^ *///" | 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 XDR header description, with the sentinel sequence follows, with The embedded XDR file header follows, with subsequent pieces embedded
additional pieces throughout the document: throughout the document:
////* ////*
/// * This file was machine generated for /// * This file was machine generated for
/// * draft-ietf-nfsv4-pnfs-block-06 /// * draft-ietf-nfsv4-pnfs-block-07
/// * Last updated Tue Jan 29 02:57:06 CST 2008 /// * Last updated Tue Jan 29 02:57:06 CST 2008
/// */ /// */
////* ////*
/// * Copyright (C) The IETF Trust (2007-2008) /// * Copyright (C) The IETF Trust (2007-2008)
/// * All Rights Reserved. /// * All Rights Reserved.
/// * /// *
/// * Copyright (C) The Internet Society (1998-2006). /// * Copyright (C) The Internet Society (1998-2006).
/// * All Rights Reserved. /// * All Rights Reserved.
/// */ /// */
/// ///
////* ////*
/// * 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
nfsv41.x file. This includes both nfs types that end with a 4, such
as offset4, length4, etc, as well as more generic types such as
uint32_t and uint64_t.
2. Block Layout Description 2. Block Layout Description
2.1. Background and Architecture 2.1. Background and Architecture
The fundamental storage abstraction supported by block/volume storage The fundamental storage abstraction supported by block/volume storage
is a storage volume consisting of a sequential series of fixed size is a storage volume consisting of a sequential series of fixed size
blocks. This can be thought of as a logical disk; it may be realized blocks. This can be thought of as a logical disk; it may be realized
by the Storage System as a physical disk, a portion of a physical by the Storage System as a physical disk, a portion of a physical
disk or something more complex (e.g., concatenation, striping, RAID, disk or something more complex (e.g., concatenation, striping, RAID,
and combinations thereof) involving multiple physical disks or and combinations thereof) involving multiple physical disks or
portions thereof. portions thereof.
A pNFS layout for this block/volume class of storage is responsible A pNFS layout for this block/volume class of storage is responsible
for mapping from an NFS file (or portion of a file) to the blocks of for mapping from an NFS file (or portion of a file) to the blocks of
storage volumes that contain the file. The blocks are expressed as storage volumes that contain the file. The blocks are expressed as
extents with 64 bit offsets and lengths using the existing NFSv4 extents with 64 bit offsets and lengths using the existing NFSv4
offset4 and length4 types. Clients must be able to perform I/O to offset4 and length4 types. Clients must be able to perform I/O to
the block extents without affecting additional areas of storage the block extents without affecting additional areas of storage
(especially important for writes), therefore extents MUST be aligned (especially important for writes), therefore extents MUST be aligned
to 512-byte boundaries, and SHOULD be aligned to the block size used to 512-byte boundaries, and writable extents MUST be aligned to the
by the NFSv4 server in managing the actual file system (4 kilobytes block size used by the NFSv4 server in managing the actual file
and 8 kilobytes are common block sizes). This block size is system (4 kilobytes and 8 kilobytes are common block sizes). This
available as the NFSv4.1 layout_blksize attribute. [NFSV4.1] block size is available as the NFSv4.1 layout_blksize attribute.
[NFSV4.1]. Readable extents SHOULD be aligned to the block size used
by the NFSv4 server, but in order to support legacy file systems with
fragments, alignment to 512 byte boundaries is acceptable.
The pNFS operation for requesting a layout (LAYOUTGET) includes the The pNFS operation for requesting a layout (LAYOUTGET) includes the
"layoutiomode4 loga_iomode" argument which indicates whether the "layoutiomode4 loga_iomode" argument which indicates whether the
requested layout is for read-only use or read-write use. A read-only requested layout is for read-only use or read-write use. A read-only
layout may contain holes that are read as zero, whereas a read-write layout may contain holes that are read as zero, whereas a read-write
layout will contain allocated, but un-initialized storage in those layout will contain allocated, but un-initialized storage in those
holes (read as zero, can be written by client). This draft also holes (read as zero, can be written by client). This draft also
supports client participation in copy on write (e.g. for file systems supports client participation in copy on write (e.g. for file systems
with snapshots) by providing both read-only and un-initialized with snapshots) by providing both read-only and un-initialized
storage for the same range in a layout. Reads are initially storage for the same range in a layout. Reads are initially
skipping to change at page 7, line 29 skipping to change at page 7, line 44
device. device.
The pNFS client block layout driver uses this volume identification The pNFS client block layout driver uses this volume identification
to map pnfs_block_volume_type4 PNFS_BLOCK_VOLUME_SIMPLE deviceid4s to to map pnfs_block_volume_type4 PNFS_BLOCK_VOLUME_SIMPLE deviceid4s to
its local view of a LUN. its local view of a LUN.
2.2.2. Volume Topology 2.2.2. Volume Topology
The pNFS block server volume topology is expressed as an arbitrary The pNFS block server volume topology is expressed as an arbitrary
combination of base volume types enumerated in the following data combination of base volume types enumerated in the following data
structures. structures. The individual components of the topology are contained
in an array and components may refer to other components by using
array indices.
///enum pnfs_block_volume_type4 { ///enum pnfs_block_volume_type4 {
/// PNFS_BLOCK_VOLUME_SIMPLE = 0, /* volume maps to a single /// PNFS_BLOCK_VOLUME_SIMPLE = 0, /* volume maps to a single
/// LU */ /// LU */
/// PNFS_BLOCK_VOLUME_SLICE = 1, /* volume is a slice of /// PNFS_BLOCK_VOLUME_SLICE = 1, /* volume is a slice of
/// another volume */ /// another volume */
/// PNFS_BLOCK_VOLUME_CONCAT = 2, /* volume is a /// PNFS_BLOCK_VOLUME_CONCAT = 2, /* volume is a
/// concatenation of /// concatenation of
/// multiple volumes */ /// multiple volumes */
/// PNFS_BLOCK_VOLUME_STRIPE = 3 /* volume is striped across /// PNFS_BLOCK_VOLUME_STRIPE = 3 /* volume is striped across
skipping to change at page 8, line 22 skipping to change at page 8, line 34
/// ///
///struct pnfs_block_slice_volume_info4 { ///struct pnfs_block_slice_volume_info4 {
/// offset4 start; /* offset of the start of the /// offset4 start; /* offset of the start of the
/// slice in bytes */ /// slice in bytes */
/// length4 length; /* length of slice in bytes */ /// length4 length; /* length of slice in bytes */
/// uint32_t volume; /* array index of sliced /// uint32_t volume; /* array index of sliced
/// volume */ /// volume */
///}; ///};
/// ///
///struct pnfs_block_concat_volume_info4 { ///struct pnfs_block_concat_volume_info4 {
/// uint32_t volumes<>; /* array index of volumes /// uint32_t volumes<>; /* array indices of volumes
/// which are concatenated */ /// which are concatenated */
///}; ///};
/// ///
///struct pnfs_block_stripe_volume_info4 { ///struct pnfs_block_stripe_volume_info4 {
/// length4 stripe_unit; /* size of stripe in bytes */ /// length4 stripe_unit; /* size of stripe in bytes */
/// uint32_t volumes<>; /* array indices of volumes /// uint32_t volumes<>; /* array indices of volumes
/// which are striped across -- /// which are striped across --
/// MUST be same size */ /// MUST be same size */
///}; ///};
/// ///
skipping to change at page 8, line 44 skipping to change at page 9, line 15
/// case PNFS_BLOCK_VOLUME_SIMPLE: /// case PNFS_BLOCK_VOLUME_SIMPLE:
/// pnfs_block_simple_volume_info4 simple_info; /// pnfs_block_simple_volume_info4 simple_info;
/// case PNFS_BLOCK_VOLUME_SLICE: /// case PNFS_BLOCK_VOLUME_SLICE:
/// pnfs_block_slice_volume_info4 slice_info; /// pnfs_block_slice_volume_info4 slice_info;
/// case PNFS_BLOCK_VOLUME_CONCAT: /// case PNFS_BLOCK_VOLUME_CONCAT:
/// pnfs_block_concat_volume_info4 concat_info; /// pnfs_block_concat_volume_info4 concat_info;
/// case PNFS_BLOCK_VOLUME_STRIPE: /// case PNFS_BLOCK_VOLUME_STRIPE:
/// pnfs_block_stripe_volume_info4 stripe_info; /// pnfs_block_stripe_volume_info4 stripe_info;
///}; ///};
/// ///
////* block layout specific type for da_addr_body */
///struct pnfs_block_deviceaddr4 { ///struct pnfs_block_deviceaddr4 {
/// pnfs_block_volume4 volumes<>; /* array of volumes */ /// pnfs_block_volume4 volumes<>; /* array of volumes */
///}; ///};
/// ///
The "pnfs_block_deviceaddr4" data structure is a structure that The "pnfs_block_deviceaddr4" data structure is a structure that
allows arbitrarily complex nested volume structures to be encoded. allows arbitrarily complex nested volume structures to be encoded.
The types of aggregations that are allowed are stripes, The types of aggregations that are allowed are stripes,
concatenations, and slices. Note that the volume topology expressed concatenations, and slices. Note that the volume topology expressed
in the pnfs_block_deviceaddr4 data structure will always resolve to a in the pnfs_block_deviceaddr4 data structure will always resolve to a
set of pnfs_block_volume_type4 PNFS_BLOCK_VOLUME_SIMPLE. The array set of pnfs_block_volume_type4 PNFS_BLOCK_VOLUME_SIMPLE. The array
of volumes is ordered such that the root of the volume hierarchy is of volumes is ordered such that the root of the volume hierarchy is
the last element of the array. Concat, slice and stripe volumes MUST the last element of the array. Concat, slice and stripe volumes MUST
refer to volumes defined by lower indexed elements of the array. refer to volumes defined by lower indexed elements of the array.
skipping to change at page 11, line 18 skipping to change at page 11, line 38
/// stored. */ /// stored. */
/// offset4 file_offset; /* the starting byte offset in /// offset4 file_offset; /* the starting byte offset in
/// the file */ /// the file */
/// length4 extent_length; /* the size in bytes of the /// length4 extent_length; /* the size in bytes of the
/// extent */ /// extent */
/// offset4 storage_offset; /* the starting byte offset in /// offset4 storage_offset; /* the starting byte offset in
/// the volume */ /// the volume */
/// pnfs_block_extent_state4 es; /* the state of this extent */ /// pnfs_block_extent_state4 es; /* the state of this extent */
///}; ///};
/// ///
////* block layout specific type for loc_body */
///struct pnfs_block_layout4 { ///struct pnfs_block_layout4 {
/// pnfs_block_extent4 extents<>; /* extents which make up this /// pnfs_block_extent4 extents<>; /* extents which make up this
/// layout. */ /// layout. */
///}; ///};
/// ///
The block layout consists of a list of extents which map the logical The block layout consists of a list of extents which map the logical
regions of the file to physical locations on a volume. The "storage regions of the file to physical locations on a volume. The "storage
offset" field within each extent identifies a location on the logical offset" field within each extent identifies a location on the logical
volume specified by the "vol_id" field in the extent. The vol_id volume specified by the "vol_id" field in the extent. The vol_id
skipping to change at page 13, line 25 skipping to change at page 14, line 7
PNFS_BLOCK_INVALID_DATA extents. This overlap of PNFS_BLOCK_INVALID_DATA extents. This overlap of
PNFS_BLOCK_READ_DATA and PNFS_BLOCK_INVALID_DATA extents is the PNFS_BLOCK_READ_DATA and PNFS_BLOCK_INVALID_DATA extents is the
only permitted extent overlap. only permitted extent overlap.
o Extents MUST be ordered in the list by starting offset, with o Extents MUST be ordered in the list by starting offset, with
PNFS_BLOCK_READ_DATA extents preceding PNFS_BLOCK_INVALID_DATA PNFS_BLOCK_READ_DATA extents preceding PNFS_BLOCK_INVALID_DATA
extents in the case of equal file_offsets. extents in the case of equal file_offsets.
2.3.2. Layout Commits 2.3.2. Layout Commits
struct pnfs_block_layoutupdate4 { ////* block layout specific type for lou_body */
///struct pnfs_block_layoutupdate4 {
pnfs_block_extent4 commit_list<>; /* list of extents which now /// pnfs_block_extent4 commit_list<>; /* list of extents which
contain valid data. */ /// * now contain valid data.
/// */
}; ///};
///
The "pnfs_block_layoutupdate4" structure is used by the client as the The "pnfs_block_layoutupdate4" structure is used by the client as the
block-protocol specific argument in a LAYOUTCOMMIT operation. The block-protocol specific argument in a LAYOUTCOMMIT operation. The
"commit_list" field is an extent list covering regions of the file "commit_list" field is an extent list covering regions of the file
layout that were previously in the PNFS_BLOCK_INVALID_DATA state, but layout that were previously in the PNFS_BLOCK_INVALID_DATA state, but
have been written by the client and should now be considered in the have been written by the client and should now be considered in the
PNFS_BLOCK_READ_WRITE_DATA state. The es field of each extent in the PNFS_BLOCK_READ_WRITE_DATA state. The es field of each extent in the
commit_list MUST be set to PNFS_BLOCK_READ_WRITE_DATA. The extents commit_list MUST be set to PNFS_BLOCK_READ_WRITE_DATA. The extents
in the commit list MUST be disjoint and MUST be sorted by in the commit list MUST be disjoint and MUST be sorted by
file_offset. The storage_offset field is unused. Implementers file_offset. The storage_offset field is unused. Implementers
skipping to change at page 18, line 20 skipping to change at page 19, line 5
the current end-of-file, or extended explicitly by a SETATTR request, the current end-of-file, or extended explicitly by a SETATTR request,
the server need not recall any portions of any pNFS layouts. the server need not recall any portions of any pNFS layouts.
2.3.7. Layout Hints 2.3.7. Layout Hints
The SETATTR operation supports a layout hint attribute [NFSv4.1]. The SETATTR operation supports a layout hint attribute [NFSv4.1].
When the client sets a layout hint (data type layouthint4) with a When the client sets a layout hint (data type layouthint4) with a
layout type of LAYOUT4_BLOCK_VOLUME (the loh_type field), the layout type of LAYOUT4_BLOCK_VOLUME (the loh_type field), the
loh_body field contains a value of data type pnfs_block_layouthint4. loh_body field contains a value of data type pnfs_block_layouthint4.
////* block layout specific type for loh_body */
///struct pnfs_block_layouthint4 { ///struct pnfs_block_layouthint4 {
/// uint64_t maximum_io_time; /* maximum i/o time in seconds /// uint64_t maximum_io_time; /* maximum i/o time in seconds
/// */ /// */
///}; ///};
/// ///
The block layout client uses the layout hint data structure to The block layout client uses the layout hint data structure to
communicate to the server the maximum time that it may take an I/O to communicate to the server the maximum time that it may take an I/O to
execute on the client. Clients using block layouts it MUST set the execute on the client. Clients using block layouts MUST set the
layout hint attribute before using LAYOUTGET operations. layout hint attribute before using LAYOUTGET operations.
2.3.8. Client Fencing 2.3.8. Client Fencing
The pNFS block protocol must handle situations in which a system The pNFS block protocol must handle situations in which a system
failure, typically a network connectivity issue, requires the server failure, typically a network connectivity issue, requires the server
to unilaterally revoke extents from one client in order to transfer to unilaterally revoke extents from one client in order to transfer
the extents to another client. The pNFS server implementation MUST the extents to another client. The pNFS server implementation MUST
ensure that when resources are transferred to another client, they ensure that when resources are transferred to another client, they
are not used by the client originally owning them, and this must be are not used by the client originally owning them, and this must be
skipping to change at page 21, line 14 skipping to change at page 21, line 45
2.5. Recalling resources: CB_RECALL_ANY 2.5. Recalling resources: CB_RECALL_ANY
The server may decide that it cannot hold all of the state for The server may decide that it cannot hold all of the state for
layouts without running out of resources. In such a case, it is free layouts without running out of resources. In such a case, it is free
to recall individual layouts using CB_LAYOUTRECALL to reduce the to recall individual layouts using CB_LAYOUTRECALL to reduce the
load, or it may choose to request that the client return any layout. load, or it may choose to request that the client return any layout.
For the block layout we define the following bit For the block layout we define the following bit
const RCA4_BLK_LAYOUT_RECALL_ANY_LAYOUTS = 4; ///const RCA4_BLK_LAYOUT_RECALL_ANY_LAYOUTS = 4;
When the server sends a CB_RECALL_ANY request to a client specifying When the server sends a CB_RECALL_ANY request to a client specifying
the RCA4_BLK_LAYOUT_RECALL_ANY_LAYOUTS bit in craa_type_mask, the the RCA4_BLK_LAYOUT_RECALL_ANY_LAYOUTS bit in craa_type_mask, the
client should immediately respond with NFS4_OK, and then client should immediately respond with NFS4_OK, and then
asynchronously return complete file layouts until the number of files asynchronously return complete file layouts until the number of files
with layouts cached on the client is less the craa_object_to_keep. with layouts cached on the client is less the craa_object_to_keep.
The block layout does not currently use bits 5, 6 or 7. If any of The block layout does not currently use bits 5, 6 or 7. If any of
these bits are set, the client should return NFS4ERR_INVAL. these bits are set, the client should return NFS4ERR_INVAL.
skipping to change at page 23, line 47 skipping to change at page 24, line 32
This draft specifies the block/volume layout type for pNFS and This draft specifies the block/volume layout type for pNFS and
associated functionality. associated functionality.
5. IANA Considerations 5. IANA Considerations
There are no IANA considerations in this document. All pNFS IANA There are no IANA considerations in this document. All pNFS IANA
Considerations are covered in [NFSV4.1]. Considerations are covered in [NFSV4.1].
6. Acknowledgments 6. Acknowledgments
7. This draft draws extensively on the authors' familiarity with the This draft draws extensively on the authors' familiarity with the
mapping functionality and protocol in EMC's HighRoad system mapping functionality and protocol in EMC's MPFS (previously named
[HighRoad]. The protocol used by HighRoad is called FMP (File HighRoad) system [MPFS]. The protocol used by MPFS is called FMP
Mapping Protocol); it is an add-on protocol that runs in parallel (File Mapping Protocol); it is an add-on protocol that runs in
with file system protocols such as NFSv3 to provide pNFS-like parallel with file system protocols such as NFSv3 to provide pNFS-
functionality for block/volume storage. While drawing on HighRoad like functionality for block/volume storage. While drawing on FMP,
FMP, the data structures and functional considerations in this draft the data structures and functional considerations in this draft
differ in significant ways, based on lessons learned and the differ in significant ways, based on lessons learned and the
opportunity to take advantage of NFSv4 features such as COMPOUND opportunity to take advantage of NFSv4 features such as COMPOUND
operations. The design to support pNFS client participation in copy- operations. The design to support pNFS client participation in copy-
on-write is based on text and ideas contributed by Craig Everhart on-write is based on text and ideas contributed by Craig Everhart
(formerly with IBM).References (formerly with IBM).
Andy Adamson, Richard Chandler, Benny Halevy, Fredric Isaman, and
Mario Wurzl all helped to review drafts of this specification.
7. References
7.1. Normative References 7.1. Normative References
[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-14.txt, Internet Version 1", draft-ietf-nfsv4-minorversion1-14.txt, Internet
Draft, July 2007. Draft, July 2007.
[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
[HighRoad] EMC Corporation, "EMC Celerra HighRoad", EMC C819.1 white [MPFS] EMC Corporation, "EMC Celerra Multi-Path File System", EMC
paper, available at: Data Sheet, available at:
http://www.emc.com/pdf/products/celerra_file_server/HighRoad_wp.pdf http://www.emc.com/collateral/software/data-sheet/h2006-celerra-mpfs-
link checked 29 August 2006. mpfsi.pdf
[SMIS] SNIA, "SNIA Storage Management Initiative Specification", [SMIS] SNIA, "SNIA Storage Management Initiative Specification",
version 1.0.2, available at: version 1.0.2, available at:
http://www.snia.org/smi/tech_activities/smi_spec_pr/spec/SMIS_1_0_2_f http://www.snia.org/tech_activities/standards/curr_standards/smi/SMI-
inal.pdf S_Technical_Position_v1.0.3r1.pdf
Authors' Addresses Authors' Addresses
David L. Black David L. Black
EMC Corporation EMC Corporation
176 South Street 176 South Street
Hopkinton, MA 01748 Hopkinton, MA 01748
Phone: +1 (508) 293-7953 Phone: +1 (508) 293-7953
Email: black_david@emc.com Email: black_david@emc.com
 End of changes. 31 change blocks. 
58 lines changed or deleted 77 lines changed or added

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