]>
Network File System Requirements for Computational Storage
Oracle CorporationUnited States of Americachuck.lever@oracle.comTransport
Network File System Version 4
This document introduces an architecture
for supporting Computational Storage
on Network File System version 4 (NFS) servers and clients.
Computational storage is more than providing compute offload.
True computational storage conforms to one or both
of the following criteria:
Compute resources co-located with data storage leverages
a high bandwidth link between storage and local compute.
Compute resources co-located with data storage reduces
interrupt or data bandwidth needed between storage and host.
For NFS, the focus of computational storage techniques is
on reducing network utilization between a server and its clients.
NFSv4.2
already applies this approach:
new features include
copy offload and file initialization (ALLOCATE).
There are two broad types of computation offloaded to storage:
Examples include SQL offload, or performing a "find" operation
without pulling a filesystem's data to a client.
Also known as data transformation.
Examples include compression, transcoding, encryption, or integrity checking.
The purpose of the current document is to provide a framework
for reasoning about computational storage relative to the NFS protocol.
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
when, and only when, they appear in all capitals, as shown here.
For various reasons,
we do not want to require changes to the NFS protocol to expose
computational resources.
Instead, an NFS server host can advertise alternate RPC programs
which allow NFS clients access to the server's computational services
in a structured fashion.
The underlying assumption is that such computation runs faster on a
host that can access file data directly rather than via NFS.
An important class of input and output parameters for these remote
procedures are objects (e.g. files and directories) that exist in a
filesystem that is shared via NFS.
Such objects are referenced by filehandle and optionally a range of bytes.
Serialization is necessary to prevent an offload agent from colliding
with access by NFS clients.
Open state or a delegation might be appropriate for this purpose.
A trust relationship must exist between clients and servers.
For example, how would clients be certain that the server has actually
encrypted a file's content?
There will need to be a mechanism for authorizing offload agents
to access file data.
This document requests no action from IANA.
Special thanks go to
Transport Area Director Magnus Westerlund,
NFSV4 Working Group Chairs Spencer Shepler and Brian Pawlowski,
and
NFSV4 Working Group Secretary Thomas Haynes
for their support.