draft-ietf-nfsv4-minorversion2-33.txt   draft-ietf-nfsv4-minorversion2-34.txt 
NFSv4 T. Haynes NFSv4 T. Haynes
Internet-Draft Primary Data Internet-Draft Primary Data
Intended status: Standards Track March 05, 2015 Intended status: Standards Track March 30, 2015
Expires: September 6, 2015 Expires: October 1, 2015
NFS Version 4 Minor Version 2 NFS Version 4 Minor Version 2
draft-ietf-nfsv4-minorversion2-33.txt draft-ietf-nfsv4-minorversion2-34.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 September 6, 2015. This Internet-Draft will expire on October 1, 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 3, line 32 skipping to change at page 3, line 32
9.3.2. Permission Checking . . . . . . . . . . . . . . . . . 38 9.3.2. Permission Checking . . . . . . . . . . . . . . . . . 38
9.3.3. Object Creation . . . . . . . . . . . . . . . . . . . 38 9.3.3. Object Creation . . . . . . . . . . . . . . . . . . . 38
9.3.4. Existing Objects . . . . . . . . . . . . . . . . . . 38 9.3.4. Existing Objects . . . . . . . . . . . . . . . . . . 38
9.3.5. Label Changes . . . . . . . . . . . . . . . . . . . . 39 9.3.5. Label Changes . . . . . . . . . . . . . . . . . . . . 39
9.4. pNFS Considerations . . . . . . . . . . . . . . . . . . . 39 9.4. pNFS Considerations . . . . . . . . . . . . . . . . . . . 39
9.5. Discovery of Server Labeled NFS Support . . . . . . . . . 39 9.5. Discovery of Server Labeled NFS Support . . . . . . . . . 39
9.6. MAC Security NFS Modes of Operation . . . . . . . . . . . 40 9.6. MAC Security NFS Modes of Operation . . . . . . . . . . . 40
9.6.1. Full Mode . . . . . . . . . . . . . . . . . . . . . . 40 9.6.1. Full Mode . . . . . . . . . . . . . . . . . . . . . . 40
9.6.2. Guest Mode . . . . . . . . . . . . . . . . . . . . . 41 9.6.2. Guest Mode . . . . . . . . . . . . . . . . . . . . . 41
9.7. Security Considerations for Labeled NFS . . . . . . . . . 42 9.7. Security Considerations for Labeled NFS . . . . . . . . . 42
10. Sharing change attribute implementation details with NFSv4 10. Sharing change attribute implementation characteristics with
clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 NFSv4 clients . . . . . . . . . . . . . . . . . . . . . . . . 42
11. Error Values . . . . . . . . . . . . . . . . . . . . . . . . 43 11. Error Values . . . . . . . . . . . . . . . . . . . . . . . . 43
11.1. Error Definitions . . . . . . . . . . . . . . . . . . . 43 11.1. Error Definitions . . . . . . . . . . . . . . . . . . . 43
11.1.1. General Errors . . . . . . . . . . . . . . . . . . . 43 11.1.1. General Errors . . . . . . . . . . . . . . . . . . . 43
11.1.2. Server to Server Copy Errors . . . . . . . . . . . . 43 11.1.2. Server to Server Copy Errors . . . . . . . . . . . . 43
11.1.3. Labeled NFS Errors . . . . . . . . . . . . . . . . . 44 11.1.3. Labeled NFS Errors . . . . . . . . . . . . . . . . . 44
11.2. New Operations and Their Valid Errors . . . . . . . . . 44 11.2. New Operations and Their Valid Errors . . . . . . . . . 44
11.3. New Callback Operations and Their Valid Errors . . . . . 48 11.3. New Callback Operations and Their Valid Errors . . . . . 48
12. New File Attributes . . . . . . . . . . . . . . . . . . . . . 49 12. New File Attributes . . . . . . . . . . . . . . . . . . . . . 49
12.1. New RECOMMENDED Attributes - List and Definition 12.1. New RECOMMENDED Attributes - List and Definition
References . . . . . . . . . . . . . . . . . . . . . . . 49 References . . . . . . . . . . . . . . . . . . . . . . . 49
skipping to change at page 4, line 13 skipping to change at page 4, line 13
15.1. Operation 59: ALLOCATE - Reserve Space in A Region of a 15.1. Operation 59: ALLOCATE - Reserve Space in A Region of a
File . . . . . . . . . . . . . . . . . . . . . . . . . . 58 File . . . . . . . . . . . . . . . . . . . . . . . . . . 58
15.2. Operation 60: COPY - Initiate a server-side copy . . . . 59 15.2. Operation 60: COPY - Initiate a server-side copy . . . . 59
15.3. Operation 61: COPY_NOTIFY - Notify a source server of a 15.3. Operation 61: COPY_NOTIFY - Notify a source server of a
future copy . . . . . . . . . . . . . . . . . . . . . . 64 future copy . . . . . . . . . . . . . . . . . . . . . . 64
15.4. Operation 62: DEALLOCATE - Unreserve Space in a Region 15.4. Operation 62: DEALLOCATE - Unreserve Space in a Region
of a File . . . . . . . . . . . . . . . . . . . . . . . 66 of a File . . . . . . . . . . . . . . . . . . . . . . . 66
15.5. Operation 63: IO_ADVISE - Application I/O access pattern 15.5. Operation 63: IO_ADVISE - Application I/O access pattern
hints . . . . . . . . . . . . . . . . . . . . . . . . . 67 hints . . . . . . . . . . . . . . . . . . . . . . . . . 67
15.6. Operation 64: LAYOUTERROR - Provide Errors for the 15.6. Operation 64: LAYOUTERROR - Provide Errors for the
Layout . . . . . . . . . . . . . . . . . . . . . . . . . 73 Layout . . . . . . . . . . . . . . . . . . . . . . . . . 72
15.7. Operation 65: LAYOUTSTATS - Provide Statistics for the 15.7. Operation 65: LAYOUTSTATS - Provide Statistics for the
Layout . . . . . . . . . . . . . . . . . . . . . . . . . 76 Layout . . . . . . . . . . . . . . . . . . . . . . . . . 75
15.8. Operation 66: OFFLOAD_CANCEL - Stop an Offloaded 15.8. Operation 66: OFFLOAD_CANCEL - Stop an Offloaded
Operation . . . . . . . . . . . . . . . . . . . . . . . 77 Operation . . . . . . . . . . . . . . . . . . . . . . . 77
15.9. Operation 67: OFFLOAD_STATUS - Poll for Status of 15.9. Operation 67: OFFLOAD_STATUS - Poll for Status of
Asynchronous Operation . . . . . . . . . . . . . . . . . 78 Asynchronous Operation . . . . . . . . . . . . . . . . . 78
15.10. Operation 68: READ_PLUS - READ Data or Holes from a File 79 15.10. Operation 68: READ_PLUS - READ Data or Holes from a File 79
15.11. Operation 69: SEEK - Find the Next Data or Hole . . . . 84 15.11. Operation 69: SEEK - Find the Next Data or Hole . . . . 84
15.12. Operation 70: WRITE_SAME - WRITE an ADB Multiple Times 15.12. Operation 70: WRITE_SAME - WRITE an ADB Multiple Times
to a File . . . . . . . . . . . . . . . . . . . . . . . 85 to a File . . . . . . . . . . . . . . . . . . . . . . . 85
16. NFSv4.2 Callback Operations . . . . . . . . . . . . . . . . . 89 16. NFSv4.2 Callback Operations . . . . . . . . . . . . . . . . . 89
16.1. Operation 15: CB_OFFLOAD - Report results of an 16.1. Operation 15: CB_OFFLOAD - Report results of an
skipping to change at page 42, line 26 skipping to change at page 42, line 26
protections. Alternate methods might be in use to handle the lack of protections. Alternate methods might be in use to handle the lack of
MAC support and care should be taken to identify and mitigate threats MAC support and care should be taken to identify and mitigate threats
from possible tampering outside of these methods. from possible tampering outside of these methods.
An example of this is that a server that modifies READDIR or LOOKUP An example of this is that a server that modifies READDIR or LOOKUP
results based on the client's subject label might want to always results based on the client's subject label might want to always
construct the same subject label for a client which does not present construct the same subject label for a client which does not present
one. This will prevent a non-Labeled NFS client from mixing entries one. This will prevent a non-Labeled NFS client from mixing entries
in the directory cache. in the directory cache.
10. Sharing change attribute implementation details with NFSv4 clients 10. Sharing change attribute implementation characteristics with NFSv4
clients
Although both the NFSv4 [I-D.ietf-nfsv4-rfc3530bis] and NFSv4.1 Although both the NFSv4 [I-D.ietf-nfsv4-rfc3530bis] and NFSv4.1
protocol [RFC5661], define the change attribute as being mandatory to protocol [RFC5661], define the change attribute as being mandatory to
implement, there is little in the way of guidance as to its implement, there is little in the way of guidance as to its
construction. The only mandated constraint is that the value must construction. The only mandated constraint is that the value must
change whenever the file data or metadata change. change whenever the file data or metadata change.
While this allows for a wide range of implementations, it also leaves While this allows for a wide range of implementations, it also leaves
the client with no way to determine which is the most recent value the client with no way to determine which is the most recent value
for the change attribute in a case where several RPC calls have been for the change attribute in a case where several RPC calls have been
skipping to change at page 60, line 42 skipping to change at page 60, line 42
void; void;
}; };
<CODE ENDS> <CODE ENDS>
15.2.3. DESCRIPTION 15.2.3. DESCRIPTION
The COPY operation is used for both intra-server and inter-server The COPY operation is used for both intra-server and inter-server
copies. In both cases, the COPY is always sent from the client to copies. In both cases, the COPY is always sent from the client to
the destination server of the file copy. The COPY operation requests the destination server of the file copy. The COPY operation requests
that a file be copied from the location specified by the SAVED_FH that a range in the file specified by SAVED_FH is copied to a range
value to the location specified by the CURRENT_FH. in the file specified by CURRENT_FH.
The SAVED_FH must be a regular file. If SAVED_FH is not a regular Both SAVED_FH and CURRENT_FH must be regular files. If either
file, the operation MUST fail and return NFS4ERR_WRONG_TYPE. SAVED_FH or CURRENT_FH are not regular files, the operation MUST fail
and return NFS4ERR_WRONG_TYPE.
SAVED_FH and CURRENT_FH must be differet files. If SAVED_FH and
CURRENT_FH refer to the same file, the operation will fail with
NFS4ERR_INVAL.
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 an inter-server-to-server copy, the source-fh If the request is for an inter-server-to-server copy, the source-fh
is a filehandle from the source server and the compound procedure is is a filehandle from the source server and the compound procedure is
being executed on the destination server. In this case, the source- being executed on the destination server. In this case, the source-
fh is a foreign filehandle on the server receiving the COPY request. fh is a foreign filehandle on the server receiving the COPY request.
If 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.
skipping to change at page 61, line 17 skipping to change at page 61, line 26
If the request is for an inter-server-to-server copy, the source-fh If the request is for an inter-server-to-server copy, the source-fh
is a filehandle from the source server and the compound procedure is is a filehandle from the source server and the compound procedure is
being executed on the destination server. In this case, the source- being executed on the destination server. In this case, the source-
fh is a foreign filehandle on the server receiving the COPY request. fh is a foreign filehandle on the server receiving the COPY request.
If 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 inter-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. CURRENT_FH and SAVED_FH may be validated in the context
context of the operation referencing them and an NFS4ERR_STALE error of the operation referencing them and an NFS4ERR_STALE error returned
returned for an invalid file handle at that point. for an invalid file handle at that point.
For an inter-server copy, the ca_dst_stateid MUST refer to either
delegation, locking, or open states provided earlier by the server
(see Section 4.4.1). The order of selection is explained in
Section 8.2.5 of [RFC5661]. And the ca_src_stateid MUST be the
cnr_stateid returned from the earlier COPY_NOTIFY. If either stateid
is invalid, then the operation MUST fail. If the request is for an
intra-server copy, then the ca_src_stateid can be ignored. If
ca_dst_stateid is invalid, then the operation MUST fail.
The CURRENT_FH specifies the destination of the copy operation. The The ca_dst_stateid MUST refer to a stateid that is valid for a WRITE
CURRENT_FH MUST be a regular file and not a directory. Note, the operation and follows the rules for stateids in Sections 8.2.5 and
file MUST exist before the COPY operation begins. It is the 18.32.3 of [RFC5661]. For an inter-server copy, the ca_src_stateid
responsibility of the client to create the file if necessary, MUST be the cnr_stateid returned from the earlier COPY_NOTIFY
regardless of the actual copy protocol used. If the file cannot be operation, while for an intra-server copy ca_src_stateid MUST refer
created in the destination file system (due to file name to a stateid that is valid for a READ operations and follows the
restrictions, such as case or length), the COPY operation MUST NOT be rules for stateids in Sections 8.2.5 and 18.22.3 of [RFC5661]. If
called. either stateid is invalid, then the operation MUST fail.
The ca_src_offset is the offset within the source file from which the The ca_src_offset is the offset within the source file from which the
data will be read, the ca_dst_offset is the offset within the data will be read, the ca_dst_offset is the offset within the
destination file to which the data will be written, and the ca_count destination file to which the data will be written, and the ca_count
is the number of bytes that will be copied. An offset of 0 (zero) is the number of bytes that will be copied. An offset of 0 (zero)
specifies the start of the file. A count of 0 (zero) requests that specifies the start of the file. A count of 0 (zero) requests that
all bytes from ca_src_offset through EOF be copied to the all bytes from ca_src_offset through EOF be copied to the
destination. If concurrent modifications to the source file overlap destination. If concurrent modifications to the source file overlap
with the source file region being copied, the data copied may include with the source file region being copied, the data copied may include
all, some, or none of the modifications. The client can use standard all, some, or none of the modifications. The client can use standard
NFS operations (e.g., OPEN with OPEN4_SHARE_DENY_WRITE or mandatory NFS operations (e.g., OPEN with OPEN4_SHARE_DENY_WRITE or mandatory
byte range locks) to protect against concurrent modifications if the byte range locks) to protect against concurrent modifications if the
client is concerned about this. If the source file's end of file is client is concerned about this. If the source file's end of file is
being modified in parallel with a copy that specifies a count of 0 being modified in parallel with a copy that specifies a count of 0
(zero) bytes, the amount of data copied is implementation dependent (zero) bytes, the amount of data copied is implementation dependent
(clients may guard against this case by specifying a non-zero count (clients may guard against this case by specifying a non-zero count
value or preventing modification of the source file as mentioned value or preventing modification of the source file as mentioned
above). above).
If the source offset or the source offset plus count is greater than If the source offset or the source offset plus count is greater than
or equal to the size of the source file, the operation will fail with the size of the source file, the operation will fail with
NFS4ERR_INVAL. The destination offset or destination offset plus NFS4ERR_INVAL. The destination offset or destination offset plus
count may be greater than the size of the destination file. This count may be greater than the size of the destination file. This
allows for the client to issue parallel copies to implement allows for the client to issue parallel copies to implement
operations such as operations such as
<CODE BEGINS> <CODE BEGINS>
% cat file1 file2 file3 file4 > dest % cat file1 file2 file3 file4 > dest
<CODE ENDS> <CODE ENDS>
skipping to change at page 63, line 15 skipping to change at page 63, line 15
determine both requirements at the same time. determine both requirements at the same time.
Upon receiving the NFS4ERR_OFFLOAD_NO_REQS error, the client has to Upon receiving the NFS4ERR_OFFLOAD_NO_REQS error, the client has to
determine if it wants to either re-request the copy with a relaxed determine if it wants to either re-request the copy with a relaxed
set of requirements or if it wants to revert to manually copying the set of requirements or if it wants to revert to manually copying the
data. If it decides to manually copy the data and this is a remote data. If it decides to manually copy the data and this is a remote
copy, then the client is responsible for informing the source that copy, then the client is responsible for informing the source that
the earlier COPY_NOTIFY is no longer valid by sending it an the earlier COPY_NOTIFY is no longer valid by sending it an
OFFLOAD_CANCEL. OFFLOAD_CANCEL.
The copying of any and all attributes on the source file is the
responsibility of both the client and the copy protocol. Any
attribute which is both exposed via the NFS protocol on the source
file and set SHOULD be copied to the destination file. Any attribute
supported by the destination server that is not set on the source
file SHOULD be left unset. If the client cannot copy an attribute
from the source to destination, it MAY fail the copy transaction.
Metadata attributes not exposed via the NFS protocol SHOULD be copied
to the destination file where appropriate via the copy protocol.
Note that if the copy protocol is NFSv4.x, then these attributes will
be lost.
The destination file's named attributes are not duplicated from the
source file. After the copy process completes, the client MAY
attempt to duplicate named attributes using standard NFSv4
operations. However, the destination file's named attribute
capabilities MAY be different from the source file's named attribute
capabilities.
If the operation does not result in an immediate failure, the server If the operation does not result in an immediate failure, the server
will return NFS4_OK, and the CURRENT_FH will remain the destination's will return NFS4_OK.
filehandle.
If the wr_callback_id is returned, this indicates that the operation If the wr_callback_id is returned, this indicates that the operation
was initiated and a CB_OFFLOAD callback will deliver the final was initiated and a CB_OFFLOAD callback will deliver the final
results of the operation. The wr_callback_id stateid is termed a results of the operation. The wr_callback_id stateid is termed a
copy stateid in this context. The server is given the option of copy stateid in this context. The server is given the option of
returning the results in a callback because the data may require a returning the results in a callback because the data may require a
relatively long period of time to copy. relatively long period of time to copy.
If no wr_callback_id is returned, the operation completed If no wr_callback_id is returned, the operation completed
synchronously and no callback will be issued by the server. The synchronously and no callback will be issued by the server. The
skipping to change at page 66, line 13 skipping to change at page 65, line 39
the same copy notification request to the source server. the same copy notification request to the source server.
The cnr_stateid is a copy stateid which uniquely describes the state The cnr_stateid is a copy stateid which uniquely describes the state
needed on the source server to track the proposed copy. As defined needed on the source server to track the proposed copy. As defined
in Section 8.2 of [RFC5661], a stateid is tied to the current in Section 8.2 of [RFC5661], a stateid is tied to the current
filehandle and if the same stateid is presented by two different filehandle and if the same stateid is presented by two different
clients, it may refer to different state. As the source does not clients, it may refer to different state. As the source does not
know which netloc4 network location the destinaton might use to know which netloc4 network location the destinaton might use to
establish the copy operation, it can use the cnr_stateid to identify establish the copy operation, it can use the cnr_stateid to identify
that the destination is operating on behalf of the client. Thus the that the destination is operating on behalf of the client. Thus the
source server MUST construct copy stateids such that they are unique source server MUST construct copy stateids such that they are
from all other stateids handed out to clients. These copy stateids distinct from all other stateids handed out to clients. These copy
MUST equate to each of the earlier delegation, locking, and open stateids MUST denote the same set of locks as each of the earlier
states for the client on the given file (see Section 4.4.1). delegation, locking, and open states for the client on the given file
(see Section 4.4.1).
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
be reachable from the client and might be located on networks to be reachable from the client and might be located on networks to
which the client has no connection. which the client has no connection.
For a copy only involving one server (the source and destination are For a copy only involving one server (the source and destination are
on the same server), this operation is unnecessary. on the same server), this operation is unnecessary.
skipping to change at page 93, line 34 skipping to change at page 93, line 34
Appendix A. Acknowledgments Appendix A. Acknowledgments
Tom Haynes would like to thank NetApp, Inc. for its funding of his Tom Haynes would like to thank NetApp, Inc. for its funding of his
time on this project. time on this project.
For the pNFS Access Permissions Check, the original draft was by For the pNFS Access Permissions Check, the original draft was by
Sorin Faibish, David Black, Mike Eisler, and Jason Glasgow. The work Sorin Faibish, David Black, Mike Eisler, and Jason Glasgow. The work
was influenced by discussions with Benny Halevy and Bruce Fields. A was influenced by discussions with Benny Halevy and Bruce Fields. A
review was done by Tom Haynes. review was done by Tom Haynes.
For the Sharing change attribute implementation details with NFSv4 For the Sharing change attribute implementation characteristics with
clients, the original draft was by Trond Myklebust. NFSv4 clients, the original draft was by Trond Myklebust.
For the NFS Server Side Copy, the original draft was by James For the NFS Server Side Copy, the original draft was by James
Lentini, Mike Eisler, Deepak Kenchammana, Anshul Madan, and Rahul Lentini, Mike Eisler, Deepak Kenchammana, Anshul Madan, and Rahul
Iyer. Tom Talpey co-authored an unpublished version of that Iyer. Tom Talpey co-authored an unpublished version of that
document. It was also was reviewed by a number of individuals: document. It was also was reviewed by a number of individuals:
Pranoop Erasani, Tom Haynes, Arthur Lent, Trond Myklebust, Dave Pranoop Erasani, Tom Haynes, Arthur Lent, Trond Myklebust, Dave
Noveck, Theresa Lingutla-Raj, Manjunath Shankararao, Satyam Vaghani, Noveck, Theresa Lingutla-Raj, Manjunath Shankararao, Satyam Vaghani,
and Nico Williams. Anna Schumaker's early prototyping experience and Nico Williams. Anna Schumaker's early prototyping experience
helped us avoid some traps. Also, both Olga Kornievskaia and Andy helped us avoid some traps. Also, both Olga Kornievskaia and Andy
Adamson brought implementation experience to the use of copy stateids Adamson brought implementation experience to the use of copy stateids
in inter-server copy. in inter-server copy. Jorge Mora was able to optimize the handling
of errors for the result of COPY.
For the NFS space reservation operations, the original draft was by For the NFS space reservation operations, the original draft was by
Mike Eisler, James Lentini, Manjunath Shankararao, and Rahul Iyer. Mike Eisler, James Lentini, Manjunath Shankararao, and Rahul Iyer.
For the sparse file support, the original draft was by Dean For the sparse file support, the original draft was by Dean
Hildebrand and Marc Eshel. Valuable input and advice was received Hildebrand and Marc Eshel. Valuable input and advice was received
from Sorin Faibish, Bruce Fields, Benny Halevy, Trond Myklebust, and from Sorin Faibish, Bruce Fields, Benny Halevy, Trond Myklebust, and
Richard Scheffenegger. Richard Scheffenegger.
For the Application IO Hints, the original draft was by Dean For the Application IO Hints, the original draft was by Dean
 End of changes. 18 change blocks. 
63 lines changed or deleted 42 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/