draft-ietf-nfsv4-minorversion2-30.txt   draft-ietf-nfsv4-minorversion2-31.txt 
NFSv4 T. Haynes NFSv4 T. Haynes
Internet-Draft Primary Data Internet-Draft Primary Data
Intended status: Standards Track January 21, 2015 Intended status: Standards Track March 03, 2015
Expires: July 25, 2015 Expires: September 4, 2015
NFS Version 4 Minor Version 2 NFS Version 4 Minor Version 2
draft-ietf-nfsv4-minorversion2-30.txt draft-ietf-nfsv4-minorversion2-31.txt
Abstract Abstract
This Internet-Draft describes NFS version 4 minor version two, This Internet-Draft describes NFS version 4 minor version two,
describing the protocol extensions made from NFS version 4 minor describing the protocol extensions made from NFS version 4 minor
version 1. Major extensions introduced in NFS version 4 minor version 1. Major extensions introduced in NFS version 4 minor
version two include: Server Side Copy, Application I/O Advise, Space version two include: Server Side Copy, Application I/O Advise, Space
Reservations, Sparse Files, Application Data Blocks, and Labeled NFS. Reservations, Sparse Files, Application Data Blocks, and Labeled NFS.
Requirements Language Requirements Language
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 July 25, 2015. This Internet-Draft will expire on September 4, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 10, line 33 skipping to change at page 10, line 33
The implementation of server-side copy is OPTIONAL by the client and The implementation of server-side copy is OPTIONAL by the client and
the server. However, in order to successfully copy a file, some the server. However, in order to successfully copy a file, some
operations MUST be supported by the client and/or server. operations MUST be supported by the client and/or server.
If a client desires an intra-server file copy, then it MUST support If a client desires an intra-server file copy, then it MUST support
the COPY and CB_OFFLOAD operations. If COPY returns a stateid, then the COPY and CB_OFFLOAD operations. If COPY returns a stateid, then
the client MAY use the OFFLOAD_CANCEL and OFFLOAD_STATUS operations. the client MAY use the OFFLOAD_CANCEL and OFFLOAD_STATUS operations.
If a client desires an inter-server file copy, then it MUST support If a client desires an inter-server file copy, then it MUST support
the COPY, COPY_NOTICE, and CB_OFFLOAD operations, and MAY use the the COPY, COPY_NOTIFY, and CB_OFFLOAD operations, and MAY use the
OFFLOAD_CANCEL operation. If COPY returns a stateid, then the client OFFLOAD_CANCEL operation. If COPY returns a stateid, then the client
MAY use the OFFLOAD_CANCEL and OFFLOAD_STATUS operations. MAY use the OFFLOAD_CANCEL and OFFLOAD_STATUS operations.
If a server supports intra-server copy, then the server MUST support If a server supports intra-server copy, then the server MUST support
the COPY operation. If a server's COPY operation returns a stateid, the COPY operation. If a server's COPY operation returns a stateid,
then the server MUST also support these operations: CB_OFFLOAD, then the server MUST also support these operations: CB_OFFLOAD,
OFFLOAD_CANCEL, and OFFLOAD_STATUS. OFFLOAD_CANCEL, and OFFLOAD_STATUS.
If a source server supports inter-server copy, then the source server If a source server supports inter-server copy, then the source server
MUST support all these operations: COPY_NOTIFY and OFFLOAD_CANCEL. MUST support all these operations: COPY_NOTIFY and OFFLOAD_CANCEL.
skipping to change at page 36, line 22 skipping to change at page 36, line 22
16k -> (20k - 1) : 00 00 00 04 ca fe de ad 00 00 ... 00 00 16k -> (20k - 1) : 00 00 00 04 ca fe de ad 00 00 ... 00 00
20k -> (24k - 1) : 00 00 00 05 fe ed fa ce 00 00 ... 00 00 20k -> (24k - 1) : 00 00 00 05 fe ed fa ce 00 00 ... 00 00
24k -> (24k - 1) : 00 00 00 06 fe ed fa ce 00 00 ... 00 00 24k -> (24k - 1) : 00 00 00 06 fe ed fa ce 00 00 ... 00 00
... ...
62k -> (64k - 1) : 00 00 00 15 fe ed fa ce 00 00 ... 00 00 62k -> (64k - 1) : 00 00 00 15 fe ed fa ce 00 00 ... 00 00
8.4. An Example of Zeroing Space 8.4. An Example of Zeroing Space
A simpler use case for WRITE_SAME are applications that want to A simpler use case for WRITE_SAME are applications that want to
efficiently zero out a file, but do not want to modify space efficiently zero out a file, but do not want to modify space
reservations. This can easily be archived by a call to WRITE_SAME reservations. This can easily be achieved by a call to WRITE_SAME
without a ADB block numbers and pattern, e.g.: without a ADB block numbers and pattern, e.g.:
WRITE_SAME {0, 1k, 10000, 0, 0, 0, 0} WRITE_SAME {0, 1k, 10000, 0, 0, 0, 0}
9. Labeled NFS 9. Labeled NFS
9.1. Introduction 9.1. Introduction
Access control models such as Unix permissions or Access Control Access control models such as Unix permissions or Access Control
Lists are commonly referred to as Discretionary Access Control (DAC) Lists are commonly referred to as Discretionary Access Control (DAC)
skipping to change at page 55, line 41 skipping to change at page 55, line 41
| RECLAIM_COMPLETE | REQ | | | RECLAIM_COMPLETE | REQ | |
| RELEASE_LOCKOWNER | MNI | | | RELEASE_LOCKOWNER | MNI | |
| REMOVE | REQ | | | REMOVE | REQ | |
| RENAME | REQ | | | RENAME | REQ | |
| RENEW | MNI | | | RENEW | MNI | |
| RESTOREFH | REQ | | | RESTOREFH | REQ | |
| SAVEFH | REQ | | | SAVEFH | REQ | |
| SECINFO | REQ | | | SECINFO | REQ | |
| SECINFO_NO_NAME | REC | pNFS file layout | | SECINFO_NO_NAME | REC | pNFS file layout |
| | | (REQ) | | | | (REQ) |
| SEEK | OPT | |
| SEQUENCE | REQ | | | SEQUENCE | REQ | |
| SETATTR | REQ | | | SETATTR | REQ | |
| SETCLIENTID | MNI | | | SETCLIENTID | MNI | |
| SETCLIENTID_CONFIRM | MNI | | | SETCLIENTID_CONFIRM | MNI | |
| SET_SSV | REQ | | | SET_SSV | REQ | |
| TEST_STATEID | REQ | | | TEST_STATEID | REQ | |
| VERIFY | REQ | | | VERIFY | REQ | |
| WANT_DELEGATION | OPT | FDELG (OPT) | | WANT_DELEGATION | OPT | FDELG (OPT) |
| WRITE | REQ | | | WRITE | REQ | |
| WRITE_SAME | OPT | ADB (REQ) | | WRITE_SAME | OPT | ADB (REQ) |
skipping to change at page 61, line 31 skipping to change at page 61, line 31
The SAVED_FH must be a regular file. If SAVED_FH is not a regular The SAVED_FH must be a regular file. If SAVED_FH is not a regular
file, the operation MUST fail and return NFS4ERR_WRONG_TYPE. file, the operation MUST fail and return NFS4ERR_WRONG_TYPE.
In order to set SAVED_FH to the source file handle, the compound In order to set SAVED_FH to the source file handle, the compound
procedure requesting the COPY will include a sub-sequence of procedure requesting the COPY will include a sub-sequence of
operations such as operations such as
PUTFH source-fh PUTFH source-fh
SAVEFH SAVEFH
If the request is for a server-to-server copy, the source-fh is a If the request is for an inter-server-to-server copy, the source-fh
filehandle from the source server and the compound procedure is being is a filehandle from the source server and the compound procedure is
executed on the destination server. In this case, the source-fh is a being executed on the destination server. In this case, the source-
foreign filehandle on the server receiving the COPY request. If fh is a foreign filehandle on the server receiving the COPY request.
either PUTFH or SAVEFH checked the validity of the filehandle, the If either PUTFH or SAVEFH checked the validity of the filehandle, the
operation would likely fail and return NFS4ERR_STALE. operation would likely fail and return NFS4ERR_STALE.
If a server supports the server-to-server COPY feature, a PUTFH If a server supports the inter-server-to-server COPY feature, a PUTFH
followed by a SAVEFH MUST NOT return NFS4ERR_STALE for either followed by a SAVEFH MUST NOT return NFS4ERR_STALE for either
operation. These restrictions do not pose substantial difficulties operation. These restrictions do not pose substantial difficulties
for servers. The CURRENT_FH and SAVED_FH may be validated in the for servers. The CURRENT_FH and SAVED_FH may be validated in the
context of the operation referencing them and an NFS4ERR_STALE error context of the operation referencing them and an NFS4ERR_STALE error
returned for an invalid file handle at that point. returned for an invalid file handle at that point.
For an intra-server copy, both the ca_src_stateid and ca_dst_stateid For an intra-server copy, both the ca_src_stateid and ca_dst_stateid
MUST refer to either open or locking states provided earlier by the MUST refer to either open or locking states provided earlier by the
server. If either stateid is invalid, then the operation MUST fail. server. If either stateid is invalid, then the operation MUST fail.
If the request is for a inter-server copy, then the ca_src_stateid If the request is for a inter-server copy, then the ca_src_stateid
skipping to change at page 66, line 18 skipping to change at page 66, line 18
If this operation succeeds, the source server will allow the If this operation succeeds, the source server will allow the
cna_destination_server to copy the specified file on behalf of the cna_destination_server to copy the specified file on behalf of the
given user as long as both of the following conditions are met: given user as long as both of the following conditions are met:
o The destination server begins reading the source file before the o The destination server begins reading the source file before the
cnr_lease_time expires. If the cnr_lease_time expires while the cnr_lease_time expires. If the cnr_lease_time expires while the
destination server is still reading the source file, the destination server is still reading the source file, the
destination server is allowed to finish reading the file. destination server is allowed to finish reading the file.
o The client has not issued a COPY_REVOKE for the same combination o The client has not issued a OFFLOAD_CANCEL for the same
of user, filehandle, and destination server. combination of user, filehandle, and destination server.
The cnr_lease_time is chosen by the source server. A cnr_lease_time The cnr_lease_time is chosen by the source server. A cnr_lease_time
of 0 (zero) indicates an infinite lease. To avoid the need for of 0 (zero) indicates an infinite lease. To avoid the need for
synchronized clocks, copy lease times are granted by the server as a synchronized clocks, copy lease times are granted by the server as a
time delta. To renew the copy lease time the client should resend time delta. To renew the copy lease time the client should resend
the same copy notification request to the source server. the same copy notification request to the source server.
A successful response will also contain a list of netloc4 network A successful response will also contain a list of netloc4 network
location formats called cnr_source_server, on which the source is location formats called cnr_source_server, on which the source is
willing to accept connections from the destination. These might not willing to accept connections from the destination. These might not
 End of changes. 9 change blocks. 
14 lines changed or deleted 15 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/