draft-ietf-nfsv4-layout-types-08.txt   draft-ietf-nfsv4-layout-types-09.txt 
NFSv4 T. Haynes NFSv4 T. Haynes
Internet-Draft Primary Data Internet-Draft Primary Data
Updates: 5661 (if approved) August 31, 2017 Updates: 5661 (if approved) February 05, 2018
Intended status: Standards Track Intended status: Standards Track
Expires: March 4, 2018 Expires: August 9, 2018
Requirements for pNFS Layout Types Requirements for pNFS Layout Types
draft-ietf-nfsv4-layout-types-08.txt draft-ietf-nfsv4-layout-types-09.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
regard, this document effectively updates RFC5661. regard, this document updates RFC5661.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 March 4, 2018. This Internet-Draft will expire on August 9, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 36 skipping to change at page 2, line 36
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . 16 8.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 16 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 16
Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 16 Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
The concept of layout type has a central role in the definition and The concept of layout type has a central role in the definition and
implementation of Parallel Network File System (pNFS). Clients and implementation of Parallel Network File System (pNFS) (see
servers implementing different layout types behave differently in [RFC5661]). Clients and servers implementing different layout types
many ways while conforming to the overall pNFS framework defined in behave differently in many ways while conforming to the overall pNFS
[RFC5661] and this document. Layout types may differ as to: framework defined in [RFC5661] and this document. Layout types may
differ as to:
o The method used to do I/O operations directed to data storage o The method used to do I/O operations directed to data storage
devices. devices.
o The requirements for communication between the metadata server o The requirements for communication between the metadata server
(MDS) and the storage devices. (MDS) and the storage devices.
o The means used to ensure that I/O requests are only processed when o The means used to ensure that I/O requests are only processed when
the client holds an appropriate layout. the client holds an appropriate layout.
skipping to change at page 3, line 26 skipping to change at page 3, line 29
Some implementers have interpreted the text in Sections 12 ("Parallel Some implementers have interpreted the text in Sections 12 ("Parallel
NFS (pNFS)") and 13 ("NFSv4.1 as a Storage Protocol in pNFS: the File NFS (pNFS)") and 13 ("NFSv4.1 as a Storage Protocol in pNFS: the File
Layout Type") of [RFC5661] as both being applying only to the file Layout Type") of [RFC5661] as both being applying only to the file
layout type. Because Section 13 was not covered in a separate layout type. Because Section 13 was not covered in a separate
standards-track document such as those for both the block and object standards-track document such as those for both the block and object
layout types, there had been some confusion as to the layout types, there had been some confusion as to the
responsibilities of both the metadata server and the data servers responsibilities of both the metadata server and the data servers
(DS) which were laid out in Section 12. (DS) which were laid out in Section 12.
As a consequence, new internet drafts (see [FlexFiles] and [Lustre]) As a consequence, authors of new specifications (see [FlexFiles] and
may struggle to meet the requirements to be a pNFS layout type. This [Lustre]) may struggle to meet the requirements to be a pNFS layout
document gathers the requirements from all of the original layout type. This document gathers the requirements from all of the
type standard documents and then specifies the requirements placed on original layout type standard documents and then specifies the
all layout types independent of the particular type chosen. requirements placed on all layout types independent of the particular
type chosen.
2. Definitions 2. Definitions
control communication requirements: are for a layout type the control communication requirements: are for a layout type the
details regarding information on layouts, stateids, file metadata, details regarding information on layouts, stateids, file metadata,
and file data which must be communicated between the metadata and file data which must be communicated between the metadata
server and the storage devices. server and the storage devices.
control protocol: is the particular mechanism that an implementation control protocol: is the particular mechanism that an implementation
of a layout type would use to meet the control communication of a layout type would use to meet the control communication
requirement for that layout type. This need not be a protocol as requirement for that layout type. This need not be a protocol as
normally understood. In some cases the same protocol may be used normally understood. In some cases the same protocol may be used
as a control protocol and storage protocol. as a control protocol and storage protocol.
storage protocol: is the protocol used by clients to do I/O
operations to the storage device. Each layout type specifies the
set of storage protocols.
loose coupling: is when the control protocol is a storage protocol.
tight coupling: is an arrangement in which the control protocol is
one designed specifically for that purpose. It may be either a
proprietary protocol, adapted specifically to a a particular
metadata server, or one based on a standards-track document.
(file) data: is that part of the file system object which contains (file) data: is that part of the file system object which contains
the data to read or written. It is the contents of the object the data to read or written. It is the contents of the object
rather than the attributes of the object. rather than the attributes of the object.
data server (DS): is a pNFS server which provides the file's data data server (DS): is a pNFS server which provides the file's data
when the file system object is accessed over a file-based when the file system object is accessed over a file-based
protocol. Note that this usage differs from that in [RFC5661] protocol. Note that this usage differs from that in [RFC5661]
which applies the term in some cases even when other sorts of which applies the term in some cases even when other sorts of
protocols are being used. Depending on the layout, there might be protocols are being used. Depending on the layout, there might be
one or more data servers over which the data is striped. While one or more data servers over which the data is striped. While
the metadata server is strictly accessed over the NFSv4.1 the metadata server is strictly accessed over the NFSv4.1
protocol, the data server could be accessed via any file access protocol, the data server could be accessed via any file access
protocol that meets the pNFS requirements. protocol that meets the pNFS requirements.
See Section 2.1 for a comparison of this term and "data storage See Section 2.1 for a comparison of this term and "data storage
device". device".
storage device: is the target to which clients may direct I/O
requests when they hold an appropriate layout. Note that each
data server is a storage device but that some storage device are
not data servers. See Section 2.1 for further discussion.
fencing: is the process by which the metadata server prevents the fencing: is the process by which the metadata server prevents the
storage devices from processing I/O from a specific client to a storage devices from processing I/O from a specific client to a
specific file. specific file.
layout: is the information a client uses to access file data on a layout: is the information a client uses to access file data on a
storage device. This information will include specification of storage device. This information will include specification of
the protocol (layout type) and the identity of the storage devices the protocol (layout type) and the identity of the storage devices
to be used. to be used.
The bulk of the contents of the layout are defined in [RFC5661] The bulk of the contents of the layout are defined in [RFC5661]
skipping to change at page 4, line 40 skipping to change at page 5, line 12
uniquely defines the layout state provided by the server for a uniquely defines the layout state provided by the server for a
specific layout that describes a layout type and file (see specific layout that describes a layout type and file (see
Section 12.5.2 of [RFC5661]). Further, Section 12.5.3 describes Section 12.5.2 of [RFC5661]). Further, Section 12.5.3 describes
differences in handling between layout stateids and other stateid differences in handling between layout stateids and other stateid
types. types.
layout type: is a specification of both the storage protocol used to layout type: is a specification of both the storage protocol used to
access the data and the aggregation scheme used to lay out the access the data and the aggregation scheme used to lay out the
file data on the underlying storage devices. file data on the underlying storage devices.
loose coupling: is when the control protocol is a storage protocol. recalling a layout: is a graceful recall, via a callback, of a
specific layout by the metadata server to the client. Graceful
here means that the client would have the opportunity to flush any
writes, etc., before returning the layout to the metadata server.
revoking a layout: is an invalidation of a specific layout by the
metadata server. Once revocation occurs, the metadata server will
not accept as valid any reference to the revoked layout and a
storage device will not accept any client access based on the
layout.
(file) metadata: is that part of the file system object that (file) metadata: is that part of the file system object that
contains various descriptive data relevant to the file object, as contains various descriptive data relevant to the file object, as
opposed to the file data itself. This could include the time of opposed to the file data itself. This could include the time of
last modification, access time, end-of-file (EOF) position, etc. last modification, access time, end-of-file (EOF) position, etc.
metadata server (MDS): is the pNFS server which provides metadata metadata server (MDS): is the pNFS server which provides metadata
information for a file system object. It also is responsible for information for a file system object. It also is responsible for
generating, recalling, and revoking layouts for file system generating, recalling, and revoking layouts for file system
objects, for performing directory operations, and for performing I objects, for performing directory operations, and for performing I
/O operations to regular files when the clients direct these to /O operations to regular files when the clients direct these to
the metadata server itself. the metadata server itself.
recalling a layout: is a graceful recall, via a callback, of a
specific layout by the metadata server to the client. Graceful
here means that the client would have the opportunity to flush any
writes, etc., before returning the layout to the metadata server.
revoking a layout: is an invalidation of a specific layout by the
metadata server. Once revocation occurs, the metadata server will
not accept as valid any reference to the revoked layout and a
storage device will not accept any client access based on the
layout.
stateid: is a 128-bit quantity returned by a server that uniquely stateid: is a 128-bit quantity returned by a server that uniquely
defines the set of locking-related state provided by the server. defines the set of locking-related state provided by the server.
Stateids may designate state related to open files, to byte-range Stateids may designate state related to open files, to byte-range
locks, to delegations, or to layouts. locks, to delegations, or to layouts.
storage device: is the target to which clients may direct I/O
requests when they hold an appropriate layout. Note that each
data server is a storage device but that some storage device are
not data servers. See Section 2.1 for further discussion.
storage protocol: is the protocol used by clients to do I/O
operations to the storage device. Each layout type specifies the
set of storage protocols.
tight coupling: is an arrangement in which the control protocol is
one designed specifically for that purpose. It may be either a
proprietary protocol, adapted specifically to a a particular
metadata server, or one based on a standards-track document.
2.1. Use of the Terms "Data Server" and "Storage Device" 2.1. Use of the Terms "Data Server" and "Storage Device"
In [RFC5661], these two terms of "Data Server" and "Storage Device" In [RFC5661], these two terms of "Data Server" and "Storage Device"
are used somewhat inconsistently: are used somewhat inconsistently:
o In chapter 12, where pNFS in general is discussed, the term o In chapter 12, where pNFS in general is discussed, the term
"storage device" is used. "storage device" is used.
o In chapter 13, where the file layout type is discussed, the term o In chapter 13, where the file layout type is discussed, the term
"data server" is used. "data server" is used.
skipping to change at page 15, line 12 skipping to change at page 15, line 12
semantic requirements of NFSv4.1 (e.g., locking) are met in the semantic requirements of NFSv4.1 (e.g., locking) are met in the
context of the proposed layout type. context of the proposed layout type.
6. Security Considerations 6. Security Considerations
This section does not deal directly with security considerations for This section does not deal directly with security considerations for
existing or new layout types. Instead, it provides a general existing or new layout types. Instead, it provides a general
framework for understating security-related issues within the pNFS framework for understating security-related issues within the pNFS
framework. Specific security considerations will be addressed in the framework. Specific security considerations will be addressed in the
Security Considerations sections of documents specifying layout Security Considerations sections of documents specifying layout
types. types. For example, in Section 5 of [RFC5663], the lack of finer-
than-physical disk access control necessitates that the client is
delegated the responsibility to enforce the access provided to them
in the layout extent which they were granted by the metadata server.
The layout type specification must ensure that only data accesses The layout type specification must ensure that only data accesses
consistent with the NFSV4.1 security model are allowed. It may do consistent with the NFSV4.1 security model are allowed. It may do
this directly, by providing that appropriate checks be performed at this directly, by providing that appropriate checks be performed at
the time each access is performed. It may do it indirectly by the time each access is performed. It may do it indirectly by
allowing the client or the storage device to be responsible for allowing the client or the storage device to be responsible for
making the appropriate checks. In the latter case, I/O access writes making the appropriate checks. In the latter case, I/O access writes
are reflected in layouts and the layout type must provide a way to are reflected in layouts and the layout type must provide a way to
prevent inappropriate access due to permissions changes between the prevent inappropriate access due to permissions changes between the
time a layout is granted and the time the access is performed. time a layout is granted and the time the access is performed.
 End of changes. 14 change blocks. 
42 lines changed or deleted 47 lines changed or added

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