draft-ietf-nfsv4-rfc3530bis-18.txt   draft-ietf-nfsv4-rfc3530bis-19.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: November 9, 2012 EMC Expires: March 7, 2013 EMC
May 08, 2012 September 03, 2012
Network File System (NFS) Version 4 Protocol Network File System (NFS) Version 4 Protocol
draft-ietf-nfsv4-rfc3530bis-18.txt draft-ietf-nfsv4-rfc3530bis-19.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 November 9, 2012. This Internet-Draft will expire on March 7, 2013.
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 5, line 32 skipping to change at page 5, line 32
9.2. Lock Ranges . . . . . . . . . . . . . . . . . . . . . . 121 9.2. Lock Ranges . . . . . . . . . . . . . . . . . . . . . . 121
9.3. Upgrading and Downgrading Locks . . . . . . . . . . . . 121 9.3. Upgrading and Downgrading Locks . . . . . . . . . . . . 121
9.4. Blocking Locks . . . . . . . . . . . . . . . . . . . . . 122 9.4. Blocking Locks . . . . . . . . . . . . . . . . . . . . . 122
9.5. Lease Renewal . . . . . . . . . . . . . . . . . . . . . 123 9.5. Lease Renewal . . . . . . . . . . . . . . . . . . . . . 123
9.6. Crash Recovery . . . . . . . . . . . . . . . . . . . . . 124 9.6. Crash Recovery . . . . . . . . . . . . . . . . . . . . . 124
9.6.1. Client Failure and Recovery . . . . . . . . . . . . 124 9.6.1. Client Failure and Recovery . . . . . . . . . . . . 124
9.6.2. Server Failure and Recovery . . . . . . . . . . . . 124 9.6.2. Server Failure and Recovery . . . . . . . . . . . . 124
9.6.3. Network Partitions and Recovery . . . . . . . . . . 126 9.6.3. Network Partitions and Recovery . . . . . . . . . . 126
9.7. Recovery from a Lock Request Timeout or Abort . . . . . 134 9.7. Recovery from a Lock Request Timeout or Abort . . . . . 134
9.8. Server Revocation of Locks . . . . . . . . . . . . . . . 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. OPEN/CLOSE Operations . . . . . . . . . . . . . . . . . 136
9.10.1. Close and Retention of State Information . . . . . . 137 9.10.1. Close and Retention of State Information . . . . . . 137
9.11. Open Upgrade and Downgrade . . . . . . . . . . . . . . . 138 9.11. Open Upgrade and Downgrade . . . . . . . . . . . . . . . 138
9.12. Short and Long Leases . . . . . . . . . . . . . . . . . 138 9.12. Short and Long Leases . . . . . . . . . . . . . . . . . 138
9.13. Clocks, Propagation Delay, and Calculating Lease 9.13. Clocks, Propagation Delay, and Calculating Lease
Expiration . . . . . . . . . . . . . . . . . . . . . . . 139 Expiration . . . . . . . . . . . . . . . . . . . . . . . 139
9.14. Migration, Replication and State . . . . . . . . . . . . 139 9.14. Migration, Replication and State . . . . . . . . . . . . 139
9.14.1. Migration and State . . . . . . . . . . . . . . . . 140 9.14.1. Migration and State . . . . . . . . . . . . . . . . 140
9.14.2. Replication and State . . . . . . . . . . . . . . . 141 9.14.2. Replication and State . . . . . . . . . . . . . . . 141
9.14.3. Notification of Migrated Lease . . . . . . . . . . . 141 9.14.3. Notification of Migrated Lease . . . . . . . . . . . 141
skipping to change at page 19, line 39 skipping to change at page 19, line 39
| | String expected to be UTF-8 but no | | | String expected to be UTF-8 but no |
| | validation | | | validation |
| utf8val_RECOMMENDED4 | typedef utf8string utf8val_RECOMMENDED4; | | utf8val_RECOMMENDED4 | typedef utf8string utf8val_RECOMMENDED4; |
| | String SHOULD be sent UTF-8 and SHOULD be | | | String SHOULD be sent UTF-8 and SHOULD be |
| | validated | | | validated |
| utf8val_REQUIRED4 | typedef utf8string utf8val_REQUIRED4; | | utf8val_REQUIRED4 | typedef utf8string utf8val_REQUIRED4; |
| | String MUST be sent UTF-8 and MUST be | | | String MUST be sent UTF-8 and MUST be |
| | validated | | | validated |
| ascii_REQUIRED4 | typedef utf8string ascii_REQUIRED4; | | ascii_REQUIRED4 | typedef utf8string ascii_REQUIRED4; |
| | String MUST be sent as ASCII and thus is | | | String MUST be sent as ASCII and thus is |
| | automatically UTF.8 | | | automatically UTF-8 |
| comptag4 | typedef utf8_expected comptag4; | | 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; | | component4 | typedef utf8val_RECOMMENDED4 component4; |
| | Represents path name components. | | | Represents path name components. |
| linktext4 | typedef utf8val_RECOMMENDED4 linktext4; | | linktext4 | typedef utf8val_RECOMMENDED4 linktext4; |
| | Symbolic link contents. | | | Symbolic link contents. |
| pathname4 | typedef component4 pathname4<>; | | pathname4 | typedef component4 pathname4<>; |
| | Represents path name for fs_locations. | | | Represents path name for fs_locations. |
| nfs_lockid4 | typedef uint64_t nfs_lockid4; | | nfs_lockid4 | typedef uint64_t nfs_lockid4; |
| verifier4 | typedef opaque | | verifier4 | typedef opaque |
| | verifier4[NFS4_VERIFIER_SIZE]; | | | verifier4[NFS4_VERIFIER_SIZE]; |
| | Verifier used for various operations | | | Verifier used for various operations |
skipping to change at page 53, line 40 skipping to change at page 53, line 40
(ACEs) that are associated with the file system object. Although the (ACEs) that are associated with the file system object. Although the
client can read and write the acl attribute, the server is client can read and write the acl attribute, the server is
responsible for using the ACL to perform access control. The client responsible for using the ACL to perform access control. The client
can use the OPEN or ACCESS operations to check access without can use the OPEN or ACCESS operations to check access without
modifying or reading data or metadata. modifying or reading data or metadata.
The NFS ACE structure is defined as follows: The NFS ACE structure is defined as follows:
typedef uint32_t acetype4; typedef uint32_t acetype4;
typedef uint32_t aceflag4; typedef uint32_t aceflag4;
typedef uint32_t acemask4; typedef uint32_t acemask4;
struct nfsace4 { struct nfsace4 {
acetype4 type; acetype4 type;
aceflag4 flag; aceflag4 flag;
acemask4 access_mask; acemask4 access_mask;
utf8val_REQUIRED4 who; utf8val_REQUIRED4 who;
}; };
To determine if a request succeeds, the server processes each nfsace4 To determine if a request succeeds, the server processes each nfsace4
skipping to change at page 123, line 16 skipping to change at page 123, line 16
them doing so. Also, clients must be prepared for the possibility them doing so. Also, clients must be prepared for the possibility
that this final locking request will be accepted. that this final locking request will be accepted.
9.5. Lease Renewal 9.5. Lease Renewal
The purpose of a lease is to allow a server to remove stale locks 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 that are held by a client that has crashed or is otherwise
unreachable. It is not a mechanism for cache consistency and lease unreachable. It is not a mechanism for cache consistency and lease
renewals may not be denied if the lease interval has not expired. renewals may not be denied if the lease interval has not expired.
The following events cause implicit renewal of all of the leases for The client can implicitly provide a a positive indication that it is
a given client (i.e., all those sharing a given client ID). Each of still active and that the associated state held at the server, for
these is a positive indication that the client is still active and the client, is still valid. Any operation made with a valid clientid
that the associated state held at the server, for the client, is (DELEGPURGE, RENEW, OPEN, LOCK) or a valid stateid (CLOSE,
still valid. DELEGRETURN, LOCK, LOCKU, OPEN, OPEN_CONFIRM, OPEN_DOWNGRADE, READ,
SETATTR, or WRITE) informs the server to renew all of the leases for
o An OPEN with a valid client ID. 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
o Any operation made with a valid clientid (DELEGPURGE, RENEW, OPEN, consisting of all bits 0 or all bits 1.
LOCK) or a valid stateid (CLOSE, DELEGRETURN, LOCK, LOCKU, OPEN,
OPEN_CONFIRM, OPEN_DOWNGRADE, READ, SETATTR, or WRITE). 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 Note that if the client had restarted or rebooted, the client would
would not be making these requests without issuing the not be making these requests without issuing the SETCLIENTID/
SETCLIENTID/SETCLIENTID_CONFIRM sequence. The use of the SETCLIENTID_CONFIRM sequence. The use of the SETCLIENTID/
SETCLIENTID/SETCLIENTID_CONFIRM sequence (one that changes the SETCLIENTID_CONFIRM sequence (one that changes the client verifier)
client verifier) notifies the server to drop the locking state notifies the server to drop the locking state associated with the
associated with the client. SETCLIENTID/SETCLIENTID_CONFIRM never client. SETCLIENTID/SETCLIENTID_CONFIRM never renews a lease.
renews a lease.
If the server has rebooted, the stateids (NFS4ERR_STALE_STATEID If the server has rebooted, the stateids (NFS4ERR_STALE_STATEID
error) or the client ID (NFS4ERR_STALE_CLIENTID error) will not be error) or the client ID (NFS4ERR_STALE_CLIENTID error) will not be
valid hence preventing spurious renewals. valid hence preventing spurious renewals.
This approach allows for low overhead lease renewal which scales This approach allows for low overhead lease renewal which scales
well. In the typical case no extra RPC calls are required for lease 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 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 (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 not a factor since all state for the client is involved with the
lease renewal action. lease renewal action.
Since all operations that create a new lease also renew existing Since all operations that create a new lease also renew existing
leases, the server must maintain a common lease expiration time for leases, the server must maintain a common lease expiration time for
 End of changes. 10 change blocks. 
31 lines changed or deleted 26 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/