draft-ietf-nfsv4-rfc3530bis-17.txt   draft-ietf-nfsv4-rfc3530bis-18.txt 
NFSv4 T. Haynes, Ed. NFSv4 T. Haynes, Ed.
Internet-Draft NetApp Internet-Draft NetApp
Intended status: Standards Track D. Noveck, Ed. Intended status: Standards Track D. Noveck, Ed.
Expires: September 13, 2012 EMC Expires: November 9, 2012 EMC
March 12, 2012 May 08, 2012
Network File System (NFS) Version 4 Protocol Network File System (NFS) Version 4 Protocol
draft-ietf-nfsv4-rfc3530bis-17.txt draft-ietf-nfsv4-rfc3530bis-18.txt
Abstract Abstract
The Network File System (NFS) version 4 is a distributed filesystem The Network File System (NFS) version 4 is a distributed filesystem
protocol which owes heritage to NFS protocol version 2, RFC 1094, and protocol which owes heritage to NFS protocol version 2, RFC 1094, and
version 3, RFC 1813. Unlike earlier versions, the NFS version 4 version 3, RFC 1813. Unlike earlier versions, the NFS version 4
protocol supports traditional file access while integrating support protocol supports traditional file access while integrating support
for file locking and the mount protocol. In addition, support for for file locking and the mount protocol. In addition, support for
strong security (and its negotiation), compound operations, client strong security (and its negotiation), compound operations, client
caching, and internationalization have been added. Of course, caching, and internationalization have been added. Of course,
skipping to change at page 1, line 49 skipping to change at page 1, line 49
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 13, 2012. This Internet-Draft will expire on November 9, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 133, line 43 skipping to change at page 133, line 43
2. However, to do so accurately it would have to ensure that 2. However, to do so accurately it would have to ensure that
additional information about individual locks held survives reboot. additional information about individual locks held survives reboot.
Server implementations are not required to do that, so the client Server implementations are not required to do that, so the client
must not assume that the server will. must not assume that the server will.
Instead, a client MUST reclaim only those locks which it successfully Instead, a client MUST reclaim only those locks which it successfully
acquired from the previous server instance, omitting any that it acquired from the previous server instance, omitting any that it
failed to reclaim before a new reboot. Thus, in the last step above, failed to reclaim before a new reboot. Thus, in the last step above,
client A should reclaim only lock 1. client A should reclaim only lock 1.
9.6.3.4.5. Client's Handling of reclaim errors 9.6.3.4.5. Client's Handling of Reclaim Errors
A mandate for the client's handling of the NFS4ERR_NO_GRACE and A mandate for the client's handling of the NFS4ERR_NO_GRACE and
NFS4ERR_RECLAIM_BAD errors is outside the scope of this NFS4ERR_RECLAIM_BAD errors is outside the scope of this
specification, since the strategies for such handling are very specification, since the strategies for such handling are very
dependent on the client's operating environment. However, one dependent on the client's operating environment. However, one
potential approach is described below. potential approach is described below.
When the client's reclaim fails, it could examine the change When the client's reclaim fails, it could examine the change
attribute of the objects the client is trying to reclaim state for, attribute of the objects the client is trying to reclaim state for,
and use that to determine whether to re-establish the state via and use that to determine whether to re-establish the state via
skipping to change at page 202, line 30 skipping to change at page 202, line 30
current operation does not allow a directory to be accepted as the current operation does not allow a directory to be accepted as the
target of this operation. target of this operation.
13.1.2.4. NFS4ERR_MOVED (Error Code 10019) 13.1.2.4. NFS4ERR_MOVED (Error Code 10019)
The file system which contains the current filehandle object is not The file system which contains the current filehandle object is not
present at the server. It may have been relocated, migrated to present at the server. It may have been relocated, migrated to
another server or may have never been present. The client may obtain another server or may have never been present. The client may obtain
the new file system location by obtaining the "fs_locations" or the new file system location by obtaining the "fs_locations" or
attribute for the current filehandle. For further discussion, refer attribute for the current filehandle. For further discussion, refer
to Section 7 to Section 7.
13.1.2.5. NFS4ERR_NOFILEHANDLE (Error Code 10020) 13.1.2.5. NFS4ERR_NOFILEHANDLE (Error Code 10020)
The logical current or saved filehandle value is required by the The logical current or saved filehandle value is required by the
current operation and is not set. This may be a result of a current operation and is not set. This may be a result of a
malformed COMPOUND operation (i.e., no PUTFH or PUTROOTFH before an malformed COMPOUND operation (i.e., no PUTFH or PUTROOTFH before an
operation that requires the current filehandle be set). operation that requires the current filehandle be set).
13.1.2.6. NFS4ERR_NOTDIR (Error Code 20) 13.1.2.6. NFS4ERR_NOTDIR (Error Code 20)
The current (or saved) filehandle designates an object which is not a The current (or saved) filehandle designates an object which is not a
directory for an operation in which a directory is required. directory for an operation in which a directory is required.
13.1.2.7. NFS4ERR_STALE (Error Code 70) 13.1.2.7. NFS4ERR_STALE (Error Code 70)
The current or saved filehandle value designating an argument to the The current or saved filehandle value designating an argument to the
current operation is invalid The file referred to by that filehandle current operation is invalid. The file referred to by that
no longer exists or access to it has been revoked. filehandle no longer exists or access to it has been revoked.
13.1.2.8. NFS4ERR_SYMLINK (Error Code 10029) 13.1.2.8. NFS4ERR_SYMLINK (Error Code 10029)
The current filehandle designates a symbolic link when the current The current filehandle designates a symbolic link when the current
operation does not allow a symbolic link as the target. operation does not allow a symbolic link as the target.
13.1.3. Compound Structure Errors 13.1.3. Compound Structure Errors
This section deals with errors that relate to overall structure of a This section deals with errors that relate to overall structure of a
Compound request (by which we mean to include both COMPOUND and Compound request (by which we mean to include both COMPOUND and
skipping to change at page 319, line 36 skipping to change at page 319, line 36
for WebNFS", RFC 2755, January 2000. for WebNFS", RFC 2755, January 2000.
[40] The Open Group, "Section 'unlink()' of System Interfaces of The [40] The Open Group, "Section 'unlink()' of System Interfaces of The
Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004 Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004
Edition, HTML Version (www.opengroup.org), ISBN 1931624232", Edition, HTML Version (www.opengroup.org), ISBN 1931624232",
2004. 2004.
[41] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [41] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[42] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
Appendix A. Acknowledgments Appendix A. Acknowledgments
A bis is certainly built on the shoulders of the first attempt. A bis is certainly built on the shoulders of the first attempt.
Spencer Shepler, Brent Callaghan, David Robinson, Robert Thurlow, Spencer Shepler, Brent Callaghan, David Robinson, Robert Thurlow,
Carl Beame, Mike Eisler, and David Noveck are responsible for a great Carl Beame, Mike Eisler, and David Noveck are responsible for a great
deal of the effort in this work. deal of the effort in this work.
Rob Thurlow clarified how a client should contact a new server if a Rob Thurlow clarified how a client should contact a new server if a
migration has occurred. migration has occurred.
 End of changes. 7 change blocks. 
11 lines changed or deleted 8 lines changed or added

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