draft-ietf-nfsv4-layout-types-07.txt   draft-ietf-nfsv4-layout-types-08.txt 
NFSv4 T. Haynes NFSv4 T. Haynes
Internet-Draft Primary Data Internet-Draft Primary Data
Updates: 5661 (if approved) August 29, 2017 Updates: 5661 (if approved) August 31, 2017
Intended status: Standards Track Intended status: Standards Track
Expires: March 2, 2018 Expires: March 4, 2018
Requirements for pNFS Layout Types Requirements for pNFS Layout Types
draft-ietf-nfsv4-layout-types-07.txt draft-ietf-nfsv4-layout-types-08.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 March 2, 2018. This Internet-Draft will expire on March 4, 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 2, line 16 skipping to change at page 2, line 16
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Use of the Terms "Data Server" and "Storage Device" . . . 5 2.1. Use of the Terms "Data Server" and "Storage Device" . . . 5
2.2. Requirements Language . . . . . . . . . . . . . . . . . . 6 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 6
3. The Control Protocol . . . . . . . . . . . . . . . . . . . . 6 3. The Control Protocol . . . . . . . . . . . . . . . . . . . . 6
3.1. Control Protocol REQUIREMENTS . . . . . . . . . . . . . . 8 3.1. Control Protocol Requirements . . . . . . . . . . . . . . 8
3.2. Previously Undocumented Protocol REQUIREMENTS . . . . . . 9 3.2. Previously Undocumented Protocol Requirements . . . . . . 9
3.3. Editorial Requirements . . . . . . . . . . . . . . . . . 10 3.3. Editorial Requirements . . . . . . . . . . . . . . . . . 10
4. Specifications of Original Layout Types . . . . . . . . . . . 11 4. Specifications of Original Layout Types . . . . . . . . . . . 11
4.1. File Layout Type . . . . . . . . . . . . . . . . . . . . 11 4.1. File Layout Type . . . . . . . . . . . . . . . . . . . . 11
4.2. Block Layout Type . . . . . . . . . . . . . . . . . . . . 12 4.2. Block Layout Type . . . . . . . . . . . . . . . . . . . . 12
4.3. Object Layout Type . . . . . . . . . . . . . . . . . . . 13 4.3. Object Layout Type . . . . . . . . . . . . . . . . . . . 13
5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . 15 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). Clients and
servers implementing different layout types behave differently in servers implementing different layout types behave differently in
many ways while conforming to the overall pNFS framework defined in many ways while conforming to the overall pNFS framework defined in
skipping to change at page 3, line 43 skipping to change at page 3, line 43
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 data access protocol. as a control protocol and storage protocol.
(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
skipping to change at page 5, line 32 skipping to change at page 5, line 32
storage device: is the target to which clients may direct I/O storage device: is the target to which clients may direct I/O
requests when they hold an appropriate layout. Note that each requests when they hold an appropriate layout. Note that each
data server is a storage device but that some storage device are data server is a storage device but that some storage device are
not data servers. See Section 2.1 for further discussion. not data servers. See Section 2.1 for further discussion.
storage protocol: is the protocol used by clients to do I/O storage protocol: is the protocol used by clients to do I/O
operations to the storage device. Each layout type specifies the operations to the storage device. Each layout type specifies the
set of storage protocols. set of storage protocols.
tight coupling: is when the control protocol is one designed tight coupling: is an arrangement in which the control protocol is
specifically for that purpose. It may be either a proprietary one designed specifically for that purpose. It may be either a
protocol, adapted specifically to a a particular metadata server, proprietary protocol, adapted specifically to a a particular
or one based on a standards-track document. 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
skipping to change at page 8, line 5 skipping to change at page 8, line 5
same way as those that use an internal control protocol or a same way as those that use an internal control protocol or a
functional equivalent. functional equivalent.
An example of this last case is the SCSI layout type [RFC8154], which An example of this last case is the SCSI layout type [RFC8154], which
extends the block layout type. The block layout type had a extends the block layout type. The block layout type had a
requirement for fencing of clients, but did not present a way for the requirement for fencing of clients, but did not present a way for the
control protocol (in this case the SCSI storage protocol) to fence control protocol (in this case the SCSI storage protocol) to fence
the client. The SCSI layout type remedies that in [RFC8154] and in the client. The SCSI layout type remedies that in [RFC8154] and in
effect has a tightly coupled model. effect has a tightly coupled model.
3.1. Control Protocol REQUIREMENTS 3.1. Control Protocol Requirements
The REQUIREMENTS of interactions between the metadata server and the The requirements of interactions between the metadata server and the
storage devices are: storage devices are:
(1) The metadata server MUST be able to service the client's I/O (1) The metadata server MUST be able to service the client's I/O
requests if the client decides to make such requests to the requests if the client decides to make such requests to the
metadata server instead of to the storage device. The metadata metadata server instead of to the storage device. The metadata
server must be able to retrieve the data from the constituent server must be able to retrieve the data from the constituent
storage devices and present it back to the client. A corollary storage devices and present it back to the client. A corollary
to this is that even though the metadata server has successfully to this is that even though the metadata server has successfully
given the client a layout, the client MAY still send I/O given the client a layout, the client MAY still send I/O
requests to the metadata server. requests to the metadata server.
skipping to change at page 8, line 31 skipping to change at page 8, line 31
server typically would revoke a layout whenever a client fails server typically would revoke a layout whenever a client fails
to respond to a recall or a client's lease is expired due to to respond to a recall or a client's lease is expired due to
non-renewal. It might also revoke the layout as a means of non-renewal. It might also revoke the layout as a means of
enforcing a change in locking state or access permissions that enforcing a change in locking state or access permissions that
the storage device cannot directly enforce. the storage device cannot directly enforce.
Effective revocation may require client co-operation in using a Effective revocation may require client co-operation in using a
particular stateid (files layout) or principal (e,g., flexible particular stateid (files layout) or principal (e,g., flexible
files layout) when performing I/O. files layout) when performing I/O.
In contrast, there is no requirement to restrict access to a
file on the storage devices when a layout is recalled. It is
only after the metadata server determines that the client is not
gracefully returning the layout and starts the revocation that
this requirement is enforced.
(3) A pNFS implementation MUST NOT allow the violation of NFSv4.1's (3) A pNFS implementation MUST NOT allow the violation of NFSv4.1's
access controls: ACLs and file open modes. Section 12.9 of access controls: ACLs and file open modes. Section 12.9 of
[RFC5661] specifically lays this burden on the combination of [RFC5661] specifically lays this burden on the combination of
clients, storage devices, and the metadata server. However the clients, storage devices, and the metadata server. However the
specification of the individual layout type might create specification of the individual layout type might create
requirements as to how this is to be done. This may include a requirements as to how this is to be done. This may include a
possible requirement for the metadata server to update the possible requirement for the metadata server to update the
storage device so that it can enforce security. storage device so that it can enforce security.
The file layout requires the storage device to enforce access The file layout requires the storage device to enforce access
whereas the flex file layout requires both the storage device whereas the flex file layout requires both the storage device
and the client to enforce security. and the client to enforce security.
(4) Interactions between locking and I/O operations MUST obey (4) Interactions between locking and I/O operations MUST obey
existing semantic restrictions. In particular, if an I/O existing semantic restrictions. In particular, if an I/O
operation would be invalid when directed at the metadata server, operation would be invalid when directed at the metadata server,
it is not to be allowed when performed on the storage device. it is not to be allowed when performed on the storage device.
For the block and SCSI layout, as the storage device is not able
to reject the I/O operation, the client is responsible for
enforcing this requirement.
(5) Any disagreement between the metadata server and the data server (5) Any disagreement between the metadata server and the data server
as to the value of attributes such as modify time, the change as to the value of attributes such as modify time, the change
attribute, and the EOF position MUST be of limited duration with attribute, and the EOF position MUST be of limited duration with
clear means of resolution of any discrepancies being provided. clear means of resolution of any discrepancies being provided.
Note that Note that
(a) Discrepancies need not be resolved unless any client has (a) Discrepancies need not be resolved unless any client has
accessed the file in question via the metadata server, accessed the file in question via the metadata server,
typically by performing a GETATTR. typically by performing a GETATTR.
skipping to change at page 9, line 34 skipping to change at page 9, line 44
These requirements may be satisfied in different ways by different These requirements may be satisfied in different ways by different
layout types. As an example, while the file layout type uses the layout types. As an example, while the file layout type uses the
stateid to fence off the client, there is no requirement that other stateid to fence off the client, there is no requirement that other
layout types use this stateid approach. layout types use this stateid approach.
Each new standards-track document for a layout types MUST address how Each new standards-track document for a layout types MUST address how
the client, metadata server, and storage devices are to interact to the client, metadata server, and storage devices are to interact to
meet these requirements. meet these requirements.
3.2. Previously Undocumented Protocol REQUIREMENTS 3.2. Previously Undocumented Protocol Requirements
While not explicitly stated as requirements in Section 12 of While not explicitly stated as requirements in Section 12 of
[RFC5661], the existing layout types do have more requirements that [RFC5661], the existing layout types do have more requirements that
they need to enforce. they need to enforce.
The client has these obligations when making I/O requests to the The client has these obligations when making I/O requests to the
storage devices: storage devices:
(1) Clients MUST NOT perform I/O to the storage device if they do (1) Clients MUST NOT perform I/O to the storage device if they do
not have layouts for the files in question. not have layouts for the files in question.
skipping to change at page 10, line 11 skipping to change at page 10, line 21
(3) Clients MUST NOT perform I/O operations which would be (3) Clients MUST NOT perform I/O operations which would be
inconsistent with the iomode specified in the layout segments it inconsistent with the iomode specified in the layout segments it
holds. holds.
Under the file layout type, the storage devices are able to reject Under the file layout type, the storage devices are able to reject
any request made not conforming to these requirements. This may not any request made not conforming to these requirements. This may not
be possible for other known layout types, which puts the burden of be possible for other known layout types, which puts the burden of
enforcing such violations solely on the client. For these layout enforcing such violations solely on the client. For these layout
types: types:
(1) The metadata server MIGHT use fencing operations to the storage (1) The metadata server MAY use fencing operations to the storage
devices to enforce layout revocation against the client. devices to enforce layout revocation against the client.
(2) The metadata server MUST allow the clients to perform data I/O (2) The metadata server MUST allow the clients to perform data I/O
against it, even if it has already granted the client a layout. against it, even if it has already granted the client a layout.
A layout type might discourage such I/O, but it can not forbid A layout type might discourage such I/O, but it can not forbid
it. it.
(3) The metadata server MUST be able to do storage allocation, (3) The metadata server MUST be able to do storage allocation,
whether that is to create, delete, extend, or truncate files. whether that is to create, delete, extend, or truncate files.
skipping to change at page 11, line 6 skipping to change at page 11, line 14
Some examples include: Some examples include:
o If the metadata server does not have a means to invalidate a o If the metadata server does not have a means to invalidate a
stateid issued to the storage device to keep a particular client stateid issued to the storage device to keep a particular client
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, then the layout type
specification must require that this also be done 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 updates Section 12 of [RFC5661], which enumerates the This section updates Section 12 of [RFC5661], which enumerates the
requirements of pNFS layout type specifications. It is not normative requirements of pNFS layout type specifications. It is not normative
with regards to the file layout type presented in Section 13 of with regards to the file layout type presented in Section 13 of
[RFC5661], the block layout type [RFC5663], and the object layout [RFC5661], the block layout type [RFC5663], and the object layout
type [RFC5664]. These are discussed here only to illuminate the type [RFC5664]. These are discussed here only to illuminate the
updates made to Section 12 of [RFC5661]. updates made to Section 12 of [RFC5661].
skipping to change at page 15, line 45 skipping to change at page 16, line 13
Parallel NFS (pNFS) Operations", RFC 5664, January 2010. Parallel NFS (pNFS) Operations", RFC 5664, January 2010.
[RFC8154] Hellwig, C., "Parallel NFS (pNFS) Small Computer System [RFC8154] Hellwig, C., "Parallel NFS (pNFS) Small Computer System
Interface (SCSI) Layout", RFC 8154, DOI 10.17487/RFC8154, Interface (SCSI) Layout", RFC 8154, DOI 10.17487/RFC8154,
May 2017, <http://www.rfc-editor.org/info/rfc8154>. May 2017, <http://www.rfc-editor.org/info/rfc8154>.
8.2. Informative References 8.2. Informative References
[FlexFiles] [FlexFiles]
Halevy, B. and T. Haynes, "Parallel NFS (pNFS) Flexible Halevy, B. and T. Haynes, "Parallel NFS (pNFS) Flexible
File Layout", draft-ietf-nfsv4-flex-files-11 (Work In File Layout", draft-ietf-nfsv4-flex-files-13 (Work In
Progress), July 2017. Progress), August 2017.
[Lustre] Faibish, S. and P. Tao, "Parallel NFS (pNFS) Lustre Layout [Lustre] Faibish, S. and P. Tao, "Parallel NFS (pNFS) Lustre Layout
Operations", draft-faibish-nfsv4-pnfs-lustre-layout-07 Operations", draft-faibish-nfsv4-pnfs-lustre-layout-07
(Work In Progress), April 2014. (Work In Progress), April 2014.
Appendix A. Acknowledgments Appendix A. Acknowledgments
Dave Noveck provided an early review that sharpened the clarity of Dave Noveck provided an early review that sharpened the clarity of
the definitions. He also provided a more comprehensive review of the the definitions. He also provided a more comprehensive review of the
document. document.
 End of changes. 17 change blocks. 
20 lines changed or deleted 31 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/