--- 1/draft-ietf-nfsv4-layout-types-07.txt 2017-08-31 14:13:16.703074390 -0700 +++ 2/draft-ietf-nfsv4-layout-types-08.txt 2017-08-31 14:13:16.739075259 -0700 @@ -1,19 +1,19 @@ NFSv4 T. Haynes Internet-Draft Primary Data -Updates: 5661 (if approved) August 29, 2017 +Updates: 5661 (if approved) August 31, 2017 Intended status: Standards Track -Expires: March 2, 2018 +Expires: March 4, 2018 Requirements for pNFS Layout Types - draft-ietf-nfsv4-layout-types-07.txt + draft-ietf-nfsv4-layout-types-08.txt Abstract This document defines the requirements which individual pNFS layout 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 distinguish between requirements for pNFS as a whole and those specifically directed to the pNFS File Layout. The lack of a clear separation between the two set of requirements has been troublesome for those specifying and evaluating new Layout Types. In this @@ -27,21 +27,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2017 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 @@ -51,33 +51,33 @@ the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Use of the Terms "Data Server" and "Storage Device" . . . 5 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 6 3. The Control Protocol . . . . . . . . . . . . . . . . . . . . 6 - 3.1. Control Protocol REQUIREMENTS . . . . . . . . . . . . . . 8 - 3.2. Previously Undocumented Protocol REQUIREMENTS . . . . . . 9 + 3.1. Control Protocol Requirements . . . . . . . . . . . . . . 8 + 3.2. Previously Undocumented Protocol Requirements . . . . . . 9 3.3. Editorial Requirements . . . . . . . . . . . . . . . . . 10 4. Specifications of Original Layout Types . . . . . . . . . . . 11 4.1. File Layout Type . . . . . . . . . . . . . . . . . . . . 11 4.2. Block Layout Type . . . . . . . . . . . . . . . . . . . . 12 4.3. Object Layout Type . . . . . . . . . . . . . . . . . . . 13 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 - 8.2. Informative References . . . . . . . . . . . . . . . . . 15 + 8.2. Informative References . . . . . . . . . . . . . . . . . 16 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 16 Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction The concept of layout type has a central role in the definition and implementation of Parallel Network File System (pNFS). Clients and servers implementing different layout types behave differently in many ways while conforming to the overall pNFS framework defined in @@ -126,21 +126,21 @@ control communication requirements: are for a layout type the details regarding information on layouts, stateids, file metadata, and file data which must be communicated between the metadata server and the storage devices. control protocol: is the particular mechanism that an implementation of a layout type would use to meet the control communication requirement for that layout type. This need not be a protocol as 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 the data to read or written. It is the contents of the object rather than the attributes of the object. data server (DS): is a pNFS server which provides the file's data when the file system object is accessed over a file-based protocol. Note that this usage differs from that in [RFC5661] which applies the term in some cases even when other sorts of protocols are being used. Depending on the layout, there might be @@ -211,24 +211,24 @@ 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 when 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. + 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" In [RFC5661], these two terms of "Data Server" and "Storage Device" are used somewhat inconsistently: o In chapter 12, where pNFS in general is discussed, the term "storage device" is used. o In chapter 13, where the file layout type is discussed, the term @@ -324,23 +324,23 @@ same way as those that use an internal control protocol or a functional equivalent. An example of this last case is the SCSI layout type [RFC8154], which extends the block layout type. The block layout type had a requirement for fencing of clients, but did not present a way for the control protocol (in this case the SCSI storage protocol) to fence the client. The SCSI layout type remedies that in [RFC8154] and in 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: (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 metadata server instead of to the storage device. The metadata server must be able to retrieve the data from the constituent storage devices and present it back to the client. A corollary to this is that even though the metadata server has successfully given the client a layout, the client MAY still send I/O requests to the metadata server. @@ -350,38 +350,48 @@ server typically would revoke a layout whenever a client fails 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 enforcing a change in locking state or access permissions that the storage device cannot directly enforce. Effective revocation may require client co-operation in using a particular stateid (files layout) or principal (e,g., flexible 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 access controls: ACLs and file open modes. Section 12.9 of [RFC5661] specifically lays this burden on the combination of clients, storage devices, and the metadata server. However the specification of the individual layout type might create requirements as to how this is to be done. This may include a possible requirement for the metadata server to update the storage device so that it can enforce security. The file layout requires the storage device to enforce access whereas the flex file layout requires both the storage device and the client to enforce security. (4) Interactions between locking and I/O operations MUST obey existing semantic restrictions. In particular, if an I/O operation would be invalid when directed at the metadata server, 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 as to the value of attributes such as modify time, the change attribute, and the EOF position MUST be of limited duration with clear means of resolution of any discrepancies being provided. Note that (a) Discrepancies need not be resolved unless any client has accessed the file in question via the metadata server, typically by performing a GETATTR. @@ -401,21 +411,21 @@ These requirements may be satisfied in different ways by different layout types. As an example, while the file layout type uses the stateid to fence off the client, there is no requirement that other layout types use this stateid approach. Each new standards-track document for a layout types MUST address how the client, metadata server, and storage devices are to interact to 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 [RFC5661], the existing layout types do have more requirements that they need to enforce. The client has these obligations when making I/O requests to the storage devices: (1) Clients MUST NOT perform I/O to the storage device if they do not have layouts for the files in question. @@ -426,21 +436,21 @@ (3) Clients MUST NOT perform I/O operations which would be inconsistent with the iomode specified in the layout segments it holds. Under the file layout type, the storage devices are able to reject any request made not conforming to these requirements. This may not be possible for other known layout types, which puts the burden of enforcing such violations solely on the client. For these layout 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. (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. A layout type might discourage such I/O, but it can not forbid it. (3) The metadata server MUST be able to do storage allocation, whether that is to create, delete, extend, or truncate files. @@ -467,21 +477,22 @@ Some examples include: o If the metadata server does not have a means to invalidate a stateid issued to the storage device to keep a particular client from accessing a specific file, then the layout type specification has to document how the metadata server is going to fence the client from access to the file on that storage device. 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. 4. Specifications of Original Layout Types This section updates Section 12 of [RFC5661], which enumerates the requirements of pNFS layout type specifications. It is not normative with regards to the file layout type presented in Section 13 of [RFC5661], the block layout type [RFC5663], and the object layout type [RFC5664]. These are discussed here only to illuminate the updates made to Section 12 of [RFC5661]. @@ -700,22 +711,22 @@ Parallel NFS (pNFS) Operations", RFC 5664, January 2010. [RFC8154] Hellwig, C., "Parallel NFS (pNFS) Small Computer System Interface (SCSI) Layout", RFC 8154, DOI 10.17487/RFC8154, May 2017, . 8.2. Informative References [FlexFiles] Halevy, B. and T. Haynes, "Parallel NFS (pNFS) Flexible - File Layout", draft-ietf-nfsv4-flex-files-11 (Work In - Progress), July 2017. + File Layout", draft-ietf-nfsv4-flex-files-13 (Work In + Progress), August 2017. [Lustre] Faibish, S. and P. Tao, "Parallel NFS (pNFS) Lustre Layout Operations", draft-faibish-nfsv4-pnfs-lustre-layout-07 (Work In Progress), April 2014. Appendix A. Acknowledgments Dave Noveck provided an early review that sharpened the clarity of the definitions. He also provided a more comprehensive review of the document.