draft-ietf-nfsv4-layout-types-06.txt   draft-ietf-nfsv4-layout-types-07.txt 
NFSv4 T. Haynes NFSv4 T. Haynes
Internet-Draft Primary Data Internet-Draft Primary Data
Updates: 5661 (if approved) August 16, 2017 Updates: 5661 (if approved) August 29, 2017
Intended status: Standards Track Intended status: Standards Track
Expires: February 17, 2018 Expires: March 2, 2018
Requirements for pNFS Layout Types Requirements for pNFS Layout Types
draft-ietf-nfsv4-layout-types-06.txt draft-ietf-nfsv4-layout-types-07.txt
Abstract Abstract
This document defines the requirements which individual pNFS layout This document defines the requirements which individual pNFS layout
types need to meet in order to work within the parallel NFS (pNFS) types need to meet in order to work within the parallel NFS (pNFS)
framework as defined in RFC5661. In so doing, it aims to clearly framework as defined in RFC5661. In so doing, it aims to clearly
distinguish between requirements for pNFS as a whole and those distinguish between requirements for pNFS as a whole and those
specifically directed to the pNFS File Layout. The lack of a clear specifically directed to the pNFS File Layout. The lack of a clear
separation between the two set of requirements has been troublesome separation between the two set of requirements has been troublesome
for those specifying and evaluating new Layout Types. In this for those specifying and evaluating new Layout Types. In this
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on February 17, 2018. This Internet-Draft will expire on March 2, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 6, line 39 skipping to change at page 6, line 39
(2) any particular requirement applies to those defining layout (2) any particular requirement applies to those defining layout
types. types.
(3) the requirement is a general requirement which implementations (3) the requirement is a general requirement which implementations
need to conform to, with the specific means left to layout type need to conform to, with the specific means left to layout type
definitions type to specify. definitions type to specify.
3. The Control Protocol 3. The Control Protocol
One of the key requirements of a layout type is the need for a A layout type has to meet the requirements that apply to the
mechanism to be used to meet the requirements that apply to the
interaction between the metadata server and the storage device such interaction between the metadata server and the storage device such
that they present a consistent interface to the client that they present to the client a consistent view of stored data and
(Section 12.2.6 of [RFC5661]). Particular implementations may lock state (Section 12.2.6 of [RFC5661]). Particular implementations
satisfy this requirement in any manner they choose and the mechanism may satisfy these requirements in any manner they choose and the
chosen may not be described as a protocol. Specifications defining mechanism chosen need not be described as a protocol. Specifications
layout types need to clearly show how implementations can meet the defining layout types need to clearly show how implementations can
requirements discussed below, especially with respect to those that meet the requirements discussed below, especially with respect to
have security implications. In addition, such specifications may those that have security implications. In addition, such
find it necessary to impose requirements on implementations of the specifications may find it necessary to impose requirements on
layout type to ensure appropriate interoperability. implementations of the layout type to ensure appropriate
interoperability.
In some cases, there may be no control protocol other than the In some cases, there may be no control protocol other than the
storage protocol. This is often described as using a "loose storage protocol. This is often described as using a "loose
coupling" model. In such cases, the assumption is that the metadata coupling" model. In such cases, the assumption is that the metadata
server, storage devices, and client may be changed independently and server, storage devices, and client may be changed independently and
that the implementation requirements in the layout type specification that the implementation requirements in the layout type specification
need to ensure this degree of interoperability. This model is used need to ensure this degree of interoperability. This model is used
in the block and object layout type specification. in the block and object layout type specification.
In other cases, it is assumed that there will be a purpose-built In other cases, it is assumed that there will be a purpose-built
skipping to change at page 11, line 11 skipping to change at page 11, line 11
from accessing a specific file, then the layout type specification from accessing a specific file, then the layout type specification
has to document how the metadata server is going to fence the has to document how the metadata server is going to fence the
client from access to the file on that storage device. client from access to the file on that storage device.
o If the metadata server implements mandatory byte-range locking o If the metadata server implements mandatory byte-range locking
when accessed directly by the client, it must do so when data is when accessed directly by the client, it must do so when data is
read or written using the designated storage protocol. read or written using the designated storage protocol.
4. Specifications of Original Layout Types 4. Specifications of Original Layout Types
This section is not normative with regards to each of the presented This section updates Section 12 of [RFC5661], which enumerates the
types. This document does not update the specification of either the requirements of pNFS layout type specifications. It is not normative
block layout type (see [RFC5663]) or the object layout type (see with regards to the file layout type presented in Section 13 of
[RFC5664]). Nor does it update Section 13 of [RFC5661], but rather [RFC5661], the block layout type [RFC5663], and the object layout
Section 12 of that document. In other words, it is the pNFS type [RFC5664]. These are discussed here only to illuminate the
requirements being updated rather than the specification of the file updates made to Section 12 of [RFC5661].
layout type.
4.1. File Layout Type 4.1. File Layout Type
Because the storage protocol is a subset of NFSv4.1, the semantics of Because the storage protocol is a subset of NFSv4.1, the semantics of
the file layout type comes closest to the semantics of NFSv4.1 in the the file layout type comes closest to the semantics of NFSv4.1 in the
absence of pNFS. In particular, the stateid and principal used for I absence of pNFS. In particular, the stateid and principal used for I
/O MUST have the same effect and be subject to the same validation on /O MUST have the same effect and be subject to the same validation on
a data server as it would have if the I/O were being performed on the a data server as it would have if the I/O were being performed on the
metadata server itself. The same set of validations are applied metadata server itself. The same set of validations are applied
whether pNFS is in effect or not. whether pNFS is in effect or not.
 End of changes. 7 change blocks. 
22 lines changed or deleted 21 lines changed or added

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