--- 1/draft-ietf-nfsv4-rfc3530bis-18.txt 2012-09-04 22:15:21.149758953 +0200 +++ 2/draft-ietf-nfsv4-rfc3530bis-19.txt 2012-09-04 22:15:21.717758627 +0200 @@ -1,19 +1,19 @@ NFSv4 T. Haynes, Ed. Internet-Draft NetApp Intended status: Standards Track D. Noveck, Ed. -Expires: November 9, 2012 EMC - May 08, 2012 +Expires: March 7, 2013 EMC + September 03, 2012 Network File System (NFS) Version 4 Protocol - draft-ietf-nfsv4-rfc3530bis-18.txt + draft-ietf-nfsv4-rfc3530bis-19.txt Abstract The Network File System (NFS) version 4 is a distributed filesystem protocol which owes heritage to NFS protocol version 2, RFC 1094, and version 3, RFC 1813. Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the mount protocol. In addition, support for strong security (and its negotiation), compound operations, client caching, and internationalization have been added. Of course, @@ -38,21 +38,21 @@ 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 http://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 November 9, 2012. + This Internet-Draft will expire on March 7, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -191,21 +191,21 @@ 9.2. Lock Ranges . . . . . . . . . . . . . . . . . . . . . . 121 9.3. Upgrading and Downgrading Locks . . . . . . . . . . . . 121 9.4. Blocking Locks . . . . . . . . . . . . . . . . . . . . . 122 9.5. Lease Renewal . . . . . . . . . . . . . . . . . . . . . 123 9.6. Crash Recovery . . . . . . . . . . . . . . . . . . . . . 124 9.6.1. Client Failure and Recovery . . . . . . . . . . . . 124 9.6.2. Server Failure and Recovery . . . . . . . . . . . . 124 9.6.3. Network Partitions and Recovery . . . . . . . . . . 126 9.7. Recovery from a Lock Request Timeout or Abort . . . . . 134 9.8. Server Revocation of Locks . . . . . . . . . . . . . . . 134 - 9.9. Share Reservations . . . . . . . . . . . . . . . . . . . 136 + 9.9. Share Reservations . . . . . . . . . . . . . . . . . . . 135 9.10. OPEN/CLOSE Operations . . . . . . . . . . . . . . . . . 136 9.10.1. Close and Retention of State Information . . . . . . 137 9.11. Open Upgrade and Downgrade . . . . . . . . . . . . . . . 138 9.12. Short and Long Leases . . . . . . . . . . . . . . . . . 138 9.13. Clocks, Propagation Delay, and Calculating Lease Expiration . . . . . . . . . . . . . . . . . . . . . . . 139 9.14. Migration, Replication and State . . . . . . . . . . . . 139 9.14.1. Migration and State . . . . . . . . . . . . . . . . 140 9.14.2. Replication and State . . . . . . . . . . . . . . . 141 9.14.3. Notification of Migrated Lease . . . . . . . . . . . 141 @@ -840,23 +840,23 @@ | | String expected to be UTF-8 but no | | | validation | | utf8val_RECOMMENDED4 | typedef utf8string utf8val_RECOMMENDED4; | | | String SHOULD be sent UTF-8 and SHOULD be | | | validated | | utf8val_REQUIRED4 | typedef utf8string utf8val_REQUIRED4; | | | String MUST be sent UTF-8 and MUST be | | | validated | | ascii_REQUIRED4 | typedef utf8string ascii_REQUIRED4; | | | String MUST be sent as ASCII and thus is | - | | automatically UTF.8 | + | | automatically UTF-8 | | comptag4 | typedef utf8_expected comptag4; | - | | Tag should be UTF.8 but is not checked | + | | Tag should be UTF-8 but is not checked | | component4 | typedef utf8val_RECOMMENDED4 component4; | | | Represents path name components. | | linktext4 | typedef utf8val_RECOMMENDED4 linktext4; | | | Symbolic link contents. | | pathname4 | typedef component4 pathname4<>; | | | Represents path name for fs_locations. | | nfs_lockid4 | typedef uint64_t nfs_lockid4; | | verifier4 | typedef opaque | | | verifier4[NFS4_VERIFIER_SIZE]; | | | Verifier used for various operations | @@ -5722,41 +5722,36 @@ them doing so. Also, clients must be prepared for the possibility that this final locking request will be accepted. 9.5. Lease Renewal The purpose of a lease is to allow a server to remove stale locks that are held by a client that has crashed or is otherwise unreachable. It is not a mechanism for cache consistency and lease renewals may not be denied if the lease interval has not expired. - The following events cause implicit renewal of all of the leases for - a given client (i.e., all those sharing a given client ID). Each of - these is a positive indication that the client is still active and - that the associated state held at the server, for the client, is - still valid. - - o An OPEN with a valid client ID. - - o Any operation made with a valid clientid (DELEGPURGE, RENEW, OPEN, - LOCK) or a valid stateid (CLOSE, DELEGRETURN, LOCK, LOCKU, OPEN, - OPEN_CONFIRM, OPEN_DOWNGRADE, READ, SETATTR, or WRITE). In the + The client can implicitly provide a a positive indication that it is + still active and that the associated state held at the server, for + the client, is still valid. Any operation made with a valid clientid + (DELEGPURGE, RENEW, OPEN, LOCK) or a valid stateid (CLOSE, + DELEGRETURN, LOCK, LOCKU, OPEN, OPEN_CONFIRM, OPEN_DOWNGRADE, READ, + SETATTR, or WRITE) informs the server to renew all of the leases for + that client (i.e., all those sharing a given client ID). In the latter case, the stateid must not be one of the special stateids consisting of all bits 0 or all bits 1. - Note that if the client had restarted or rebooted, the client - would not be making these requests without issuing the - SETCLIENTID/SETCLIENTID_CONFIRM sequence. The use of the - SETCLIENTID/SETCLIENTID_CONFIRM sequence (one that changes the - client verifier) notifies the server to drop the locking state - associated with the client. SETCLIENTID/SETCLIENTID_CONFIRM never - renews a lease. + Note that if the client had restarted or rebooted, the client would + not be making these requests without issuing the SETCLIENTID/ + SETCLIENTID_CONFIRM sequence. The use of the SETCLIENTID/ + SETCLIENTID_CONFIRM sequence (one that changes the client verifier) + notifies the server to drop the locking state associated with the + client. SETCLIENTID/SETCLIENTID_CONFIRM never renews a lease. If the server has rebooted, the stateids (NFS4ERR_STALE_STATEID error) or the client ID (NFS4ERR_STALE_CLIENTID error) will not be valid hence preventing spurious renewals. This approach allows for low overhead lease renewal which scales well. In the typical case no extra RPC calls are required for lease renewal and in the worst case one RPC is required every lease period (i.e., a RENEW operation). The number of locks held by the client is not a factor since all state for the client is involved with the