Internet DRAFT - draft-hellwig-nfsv4-scsi-layout-nvme
draft-hellwig-nfsv4-scsi-layout-nvme
NFSv4 C. Hellwig
Internet-Draft
Intended status: Informational C. Lever
Expires: 8 January 2023 Oracle
S. Faibish
Cirrus Data Solutions Inc.
D. Black
Dell Technologies
7 July 2022
Using the Parallel NFS (pNFS) SCSI Layout with NVMe
draft-hellwig-nfsv4-scsi-layout-nvme-03
Abstract
This document explains how to use the Parallel Network File System
(pNFS) SCSI Layout Type with transports using the NVMe or NVMe over
Fabrics protocol.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
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 https://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 8 January 2023.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
Hellwig, et al. Expires 8 January 2023 [Page 1]
Internet-Draft pNFS SCSI Layout for NVMe July 2022
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. General Definitions . . . . . . . . . . . . . . . . . . . 3
2. SCSI Layout mapping to NVMe . . . . . . . . . . . . . . . . . 3
2.1. Volume Identification . . . . . . . . . . . . . . . . . . 3
2.2. Client Fencing . . . . . . . . . . . . . . . . . . . . . 4
2.2.1. PRs - Key Registration . . . . . . . . . . . . . . . 4
2.2.2. PRs - MDS Registration and Reservation . . . . . . . 5
2.2.3. Fencing Action . . . . . . . . . . . . . . . . . . . 5
2.2.4. Client Recovery after a Fence Action . . . . . . . . 5
2.3. Volatile write caches . . . . . . . . . . . . . . . . . . 6
3. Security Considerations . . . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Normative References . . . . . . . . . . . . . . . . . . 7
5.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
The pNFS Small Computer System Interface (SCSI) layout [RFC8154] is a
layout type that allows NFS clients to directly perform I/O to block
storage devices while bypassing the Metadata Server (MDS). It is
specified by using concepts from the SCSI protocol family for the
data path to the storage devices.
This documents explains how to access NVM Command set Namespaces
[NVME-NVM] exported by NVMe Controllers implementing the NVMe Base
specification ([NVME-BASE]) using the SCSI layout type. This
document works independent of the underlying transport used by the
NVMe Controller and thus supports Controllers implementing a wide
variety of transports, including PCIe Express, RDMA, TCP and Fibre
Channel.
This document does not amend the pNFS SCSI layout document, but
instead explains how to map the SCSI constructs used in the pNFS SCSI
layout document to NVMe concepts.
Hellwig, et al. Expires 8 January 2023 [Page 2]
Internet-Draft pNFS SCSI Layout for NVMe July 2022
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
1.2. General Definitions
The following definitions are provided for the purpose of providing
an appropriate context for the reader.
Client The "client" is the entity that accesses the NFS server's
resources. The client may be an application that contains the
logic to access the NFS server directly. The client may also be
the traditional operating system client that provides remote file
system services for a set of applications.
Server The "server" is the entity responsible for coordinating
client access to a set of file systems and is identified by a
server owner.
2. SCSI Layout mapping to NVMe
The SCSI layout definition [RFC8154] only references few SCSI
specific concepts directly. This document provides a mapping from
these SCSI concepts to NVM Express concepts that SHOULD be used when
using the pNFS SCSI layout with NVMe namespaces.
2.1. Volume Identification
The pNFS SCSI layout uses the Device Identification VPD page (page
code 0x83) from [SPC5] to identify the devices used by a layout.
Implementations that use NVMe namespaces as storage devices map NVMe
namespace identifiers to a subset of the identifiers that the Device
Identification VPD page supports for SCSI logical units.
To be used as storage devices for the pNFS SCSI layout, NVMe
namespaces MUST support either the EUI64 or NGUID value reported in a
Namespace Identification Descriptor, the I/O Command Set Independent
Identify Namespace Data Structure, and the Identify Namespace Data
Structure, NVM Command Set. If available, the NGUID value SHOULD be
used as it is the larger identifier.
Methods based on the Serial Number are not be suitable for unique
addressing needs and thus MUST NOT be used.
Hellwig, et al. Expires 8 January 2023 [Page 3]
Internet-Draft pNFS SCSI Layout for NVMe July 2022
The pnfs_scsi_base_volume_info4 structure for an NVMe namespace SHALL
be constructed as follows:
1. The "sbv_code_set" field SHALL be set to PS_CODE_SET_BINARY.
2. The "pnfs_scsi_designator_type" field SHALL be set to
PS_DESIGNATOR_EUI64.
3. The "sbv_designator" field SHALL contain either the NGUID or the
EUI64 identifier for the namespace. If both NGUID and EUI64
identifiers are available, then the NGUID identifier SHOULD be
used as it is the larger identifier.
RFC 8154 specifies the "sbv_designator" field as an XDR variable
length opaque<>. The length of that XDR opaque<> value (part of its
XDR representation) indicates which NVMe identifier is present. That
length MUST be 16 octets for an NVMe NGUID identifier and MUST be 8
octets for an NVMe EUI64 identifier. All other lengths MUST NOT be
used with an NVMe namespace.
2.2. Client Fencing
The SCSI layout uses Persistent Reservations (PRs) to provide client
fencing. For this both the MDS and the Clients have to register a
key with the storage device, and the MDS has to create a reservation
on the storage device.
The following is a full mapping of the required PERSISTENT RESERVE IN
and PERSISTENT RESERVE OUT SCSI commands [SPC5] to NVMe commands
which MUST be used when using NVMe namespaces as storage devices for
the pNFS SCSI layout.
2.2.1. PRs - Key Registration
On NVMe namespaces, reservations keys are registered using the
Reservation Register command (refer to Section 7.3 of [NVME-BASE])
with the Reservation Register Action (RREGA) field set to 000b (i.e.,
Register Reservation Key) and supplying the reservation key in the
New Reservation Key (NRKEY) field.
Reservation keys are unregistered using the Reservation Register
command with the Reservation Register Action (RREGA) field set to
001b (i.e., Unregister Reservation Key) and supplying the reservation
key in the Current Reservation Key (CRKEY) field.
One important difference between SCSI Persistent Reservations and
NVMe Reservations is that NVMe reservation keys always apply to all
controllers used by a host (as indicated by the NVMe Host
Hellwig, et al. Expires 8 January 2023 [Page 4]
Internet-Draft pNFS SCSI Layout for NVMe July 2022
Identifier). This behavior is analogous to setting the ALL_TG_PT bit
when registering a SCSI Reservation key, and is always supported by
NVMe Reservations, unlike the ALL_TG_PT for which SCSI support is
inconsistent and cannot be relied upon. Registering a reservation
key with a namespace creates an association between a host and a
namespace. A host that is a registrant of a namespace may use any
controller with which that host is associated (i.e., that has the
same Host Identifier, refer to Section 5.27.1.25 of [NVME-BASE]) to
access that namespace as a registrant.
2.2.2. PRs - MDS Registration and Reservation
Before returning a PNFS_SCSI_VOLUME_BASE volume to the client, the
MDS needs to prepare the volume for fencing using PRs. This is done
by registering the reservation generated for the MDS with the device
(see Section 2.2.1) followed by a Reservation Acquire command (refer
to Section 7.2 of [NVME-BASE]) with the Reservation Acquire Action
(RACQA) field set to 000b (i.e., Acquire) and the Reservation Type
(RTYPE) field set to 4h (i.e., Exclusive Access - Registrants Only
Reservation).
2.2.3. Fencing Action
In case of a non-responding client, the MDS fences the client by
executing a Reservation Acquire command (refer to section 7.2 of
[NVME-BASE]), with the Reservation Acquire Action (RACQA) field to
001b (i.e., Preempt) or 010b (i.e., Preempt and Abort), the Current
Reservation Key (CRKEY) field set to the server's reservation key,
the Preempt Reservation Key (PRKEY) field set to the reservation key
associated with the non-responding client and the Reservation Type
(RTYPE) field set to 4h (i.e., Exclusive Access - Registrants Only
Reservation). The client can distinguish I/O errors due to fencing
from other errors based on the Reservation Conflict NVMe status code.
2.2.4. Client Recovery after a Fence Action
If an NVMe command issued by the client to the storage device returns
a non-retryable error (refer to the DNR bit defined in Figure 92 in
[NVME-BASE]), the client MUST commit all layouts that use the storage
device through the MDS, return all outstanding layouts for the
device, forget the device ID, and unregister the reservation key.
Hellwig, et al. Expires 8 January 2023 [Page 5]
Internet-Draft pNFS SCSI Layout for NVMe July 2022
2.3. Volatile write caches
For NVMe controllers a volatile write cache is enabled if bit 0 of
the Volatile Write Cache (VWC) field in the Identify Controller Data
Structure, I/O Command Set Independent (see Figure 275 in
[NVME-BASE]) is set and the Volatile Write Cache Enable (WCE) bit
(i.e., bit 00) in the Volatile Write Cache Feature (Feature
Identifier 06h) (see Section 5.27.1.4 [NVME-BASE]) is set. If a
volatile write cache is enabled on an NVMe namespace used as a
storage device for the pNFS SCSI layout, the pNFS server (MDS) MUST
use the NVMe FLUSH command to flush the volatile write cache to
stable storage before the LAYOUTCOMMIT operation returns
3. Security Considerations
NFSv4 clients access NFSv4 metadata servers using the NFSv4 protocol.
The security considerations generally described in [RFC8881] apply to
a client's interactions with the metadata server. However, NFSv4
clients and servers access NVMe storage devices at a lower layer than
NFSv4. NFSv4 and RPC security is not directly applicable to I/O to
data servers using NVMe.
pNFS with an NVMe layout can be used with NVMe transports (e.g., NVMe
over PCIe [NVME-PCIE]) that provide essentially no additional
security functionality. Or, pNFS may be used with storage protocols
such as NVMe over TCP [NVME-TCP] that can provide significant
transport layer security.
It is the responsibility of those administering and deploying pNFS
with an NVMe layout to ensure that appropriate protection is deployed
to that protocol. When using IP-based storage protocols such as NVMe
over TCP, data confidentiality and integrity SHOULD be provided for
traffic between pNFS clients and NVMe storage devices by using a
secure communication protocol such as TLS [RFC8446]. For NVMe over
TCP, TLS SHOULD be used as described in [NVME-TCP] to protect traffic
between pNFS clients and NVMe namespaces used as storage devices.
Physical security is a common means for protocols not based on IP.
In environments where the security requirements for the storage
protocol cannot be met, pNFS with an NVMe layout SHOULD NOT be
deployed.
When security is available for the data server storage protocol, it
is generally at a different granularity and with a different notion
of identity than NFSv4 (e.g., NFSv4 controls user access to files,
and NVMe controls initiator access to volumes). As with pNFS with
the block layout type [RFC5663], the pNFS client is responsible for
enforcing appropriate correspondences between these security layers.
Hellwig, et al. Expires 8 January 2023 [Page 6]
Internet-Draft pNFS SCSI Layout for NVMe July 2022
In environments where the security requirements are such that client-
side protection from access to storage outside of the layout is not
sufficient, pNFS with a SCSI layout on a NVMe namespace SHOULD NOT be
deployed.
As with other block-oriented pNFS layout types, the metadata server
is able to fence off a client's access to the data on an NVMe
namespace used as a storage device. If a metadata server revokes a
layout, the client's access MUST be terminated at the storage devices
via fencing as specified in Section 2.2. The client has a subsequent
opportunity to acquire a new layout.
4. IANA Considerations
The document does not require any actions by IANA.
5. References
5.1. Normative References
[NVME-BASE]
NVM Express, Inc., "NVM Express Base Specification,
Revision 2.0", May 2021.
[NVME-NVM] NVM Express, Inc., "NVM Express NVM Command Set
Specification, Revision 1.0", May 2021.
[NVME-PCIE]
NVM Express, Inc., "NVMe over PCIe Transport
Specification, Revision 1.0", May 2021.
[NVME-TCP] NVM Express, Inc., "NVM Express TCP Transport
Specification, Revision 1.0", May 2021.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
[RFC5663] Black, D., Fridella, S., and J. Glasgow, "Parallel NFS
(pNFS) Block/Volume Layout", RFC 5663,
DOI 10.17487/RFC5663, January 2010,
<https://www.rfc-editor.org/info/rfc5663>.
[RFC8154] Hellwig, C., "Parallel NFS (pNFS) Small Computer System
Interface (SCSI) Layout", May 2017.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Hellwig, et al. Expires 8 January 2023 [Page 7]
Internet-Draft pNFS SCSI Layout for NVMe July 2022
[RFC8881] Noveck, D., Ed. and C. Lever, "Network File System (NFS)
Version 4 Minor Version 1 Protocol", RFC 8881,
DOI 10.17487/RFC8881, August 2020,
<https://www.rfc-editor.org/info/rfc8881>.
[SPC5] INCITS Technical Committee T10, "SCSI Primary Commands-5",
ANSI INCITS 502-2019, 2019.
5.2. Informative References
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
Authors' Addresses
Christoph Hellwig
Email: hch@lst.de
Charles Lever
Oracle Corporation
United States of America
Email: chuck.lever@oracle.com
Sorin Faibish
Cirrus Data Solutions Inc.
11 Selwyn Road
Newton, MA 02461
United States of America
Email: sorin.faibish@cdsi.us.com
David L. Black
Dell Technologies
176 South Street
Hopkinton, MA 01748
United States of America
Email: david.black@dell.com
Hellwig, et al. Expires 8 January 2023 [Page 8]
