draft-ietf-nfsv4-flex-files-18.txt   draft-ietf-nfsv4-flex-files-19.txt 
NFSv4 B. Halevy NFSv4 B. Halevy
Internet-Draft Internet-Draft
Intended status: Standards Track T. Haynes Intended status: Standards Track T. Haynes
Expires: October 27, 2018 Hammerspace Expires: November 4, 2018 Hammerspace
April 25, 2018 May 03, 2018
Parallel NFS (pNFS) Flexible File Layout Parallel NFS (pNFS) Flexible File Layout
draft-ietf-nfsv4-flex-files-18.txt draft-ietf-nfsv4-flex-files-19.txt
Abstract Abstract
The Parallel Network File System (pNFS) allows a separation between The Parallel Network File System (pNFS) allows a separation between
the metadata (onto a metadata server) and data (onto a storage the metadata (onto a metadata server) and data (onto a storage
device) for a file. The flexible file layout type is defined in this device) for a file. The flexible file layout type is defined in this
document as an extension to pNFS which allows the use of storage document as an extension to pNFS which allows the use of storage
devices in a fashion such that they require only a quite limited devices in a fashion such that they require only a quite limited
degree of interaction with the metadata server, using already degree of interaction with the metadata server, using already
existing protocols. Client-side mirroring is also added to provide existing protocols. Client-side mirroring is also added to provide
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 October 27, 2018. This Internet-Draft will expire on November 4, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
skipping to change at page 37, line 16 skipping to change at page 37, line 16
In cases where clients are uncommunicative and their lease has In cases where clients are uncommunicative and their lease has
expired or when clients fail to return recalled layouts within a expired or when clients fail to return recalled layouts within a
lease period, the server MAY revoke client layouts and reassign these lease period, the server MAY revoke client layouts and reassign these
resources to other clients (see Section 12.5.5 in [RFC5661]). To resources to other clients (see Section 12.5.5 in [RFC5661]). To
avoid data corruption, the metadata server MUST fence off the revoked avoid data corruption, the metadata server MUST fence off the revoked
clients from the respective data files as described in Section 2.2. clients from the respective data files as described in Section 2.2.
15. Security Considerations 15. Security Considerations
The pNFS feature partitions the NFSv4.1+ file system protocol into The combination of components in a pNFS system is required to
two parts, the control path and the data path (storage protocol). preserve the security properties of NFSv4.1+ with respect to an
The control path contains all the new operations described by this entity accessing data via a client. The pNFS feature partitions the
feature; all existing NFSv4 security mechanisms and features apply to NFSv4.1+ file system protocol into two parts, the control protocol
the control path (see Sections 1.7.1 and 2.2.1 of [RFC5661]). The and the data protocol. As the control protocol in this document is
combination of components in a pNFS system is required to preserve NFS, the security properties are equivalent to that version of NFS.
the security properties of NFSv4.1+ with respect to an entity The Flexible File Layout further divides the data protocol into
accessing data via a client, including security countermeasures to metadata and data paths. The security properties of the metadata
defend against threats that NFSv4.1+ provides defenses for in path are equivalent to those of NFSv4.1x (see Sections 1.7.1 and
environments where these threats are considered significant. 2.2.1 of [RFC5661]). And the security properties of the data path
are equivalent to those of the version of NFS used to access the
The metadata server is primarily responsible for securing the data storage device, with the provision that the metadata server is
path. It has to authenticate the client access and provide responsible for authenticating client access to the data file. The
appropriate credentials to the client to access data files on the metadata server provides appropriate credentials to the client to
storage device. Finally, it is responsible for revoking access for a access data files on the storage device. It is also responsible for
client to the storage device. revoking access for a client to the storage device.
The metadata server enforces the file access-control policy at The metadata server enforces the file access-control policy at
LAYOUTGET time. The client should use RPC authorization credentials LAYOUTGET time. The client should use RPC authorization credentials
for getting the layout for the requested iomode (READ or RW) and the for getting the layout for the requested iomode (READ or RW) and the
server verifies the permissions and ACL for these credentials, server verifies the permissions and ACL for these credentials,
possibly returning NFS4ERR_ACCESS if the client is not allowed the possibly returning NFS4ERR_ACCESS if the client is not allowed the
requested iomode. If the LAYOUTGET operation succeeds the client requested iomode. If the LAYOUTGET operation succeeds the client
receives, as part of the layout, a set of credentials allowing it I/O receives, as part of the layout, a set of credentials allowing it I/O
access to the specified data files corresponding to the requested access to the specified data files corresponding to the requested
iomode. When the client acts on I/O operations on behalf of its iomode. When the client acts on I/O operations on behalf of its
 End of changes. 4 change blocks. 
20 lines changed or deleted 20 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/