draft-ietf-nfsv4-rfc3530bis-14.txt   draft-ietf-nfsv4-rfc3530bis-15.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: March 5, 2012 EMC Expires: March 10, 2012 EMC
September 02, 2011 September 07, 2011
Network File System (NFS) Version 4 Protocol Network File System (NFS) Version 4 Protocol
draft-ietf-nfsv4-rfc3530bis-14.txt draft-ietf-nfsv4-rfc3530bis-15.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 March 5, 2012. This Internet-Draft will expire on March 10, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 30 skipping to change at page 5, line 30
9.1.9. Releasing state-owner State . . . . . . . . . . . . 119 9.1.9. Releasing state-owner State . . . . . . . . . . . . 119
9.1.10. Use of Open Confirmation . . . . . . . . . . . . . . 120 9.1.10. Use of Open Confirmation . . . . . . . . . . . . . . 120
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 . . . . . . . . . . . . . . . . . . . . . 123 9.6. Crash Recovery . . . . . . . . . . . . . . . . . . . . . 123
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 . . . . . 133 9.7. Recovery from a Lock Request Timeout or Abort . . . . . 132
9.8. Server Revocation of Locks . . . . . . . . . . . . . . . 133 9.8. Server Revocation of Locks . . . . . . . . . . . . . . . 133
9.9. Share Reservations . . . . . . . . . . . . . . . . . . . 134 9.9. Share Reservations . . . . . . . . . . . . . . . . . . . 134
9.10. OPEN/CLOSE Operations . . . . . . . . . . . . . . . . . 135 9.10. OPEN/CLOSE Operations . . . . . . . . . . . . . . . . . 135
9.10.1. Close and Retention of State Information . . . . . . 136 9.10.1. Close and Retention of State Information . . . . . . 136
9.11. Open Upgrade and Downgrade . . . . . . . . . . . . . . . 136 9.11. Open Upgrade and Downgrade . . . . . . . . . . . . . . . 136
9.12. Short and Long Leases . . . . . . . . . . . . . . . . . 137 9.12. Short and Long Leases . . . . . . . . . . . . . . . . . 137
9.13. Clocks, Propagation Delay, and Calculating Lease 9.13. Clocks, Propagation Delay, and Calculating Lease
Expiration . . . . . . . . . . . . . . . . . . . . . . . 138 Expiration . . . . . . . . . . . . . . . . . . . . . . . 137
9.14. Migration, Replication and State . . . . . . . . . . . . 138 9.14. Migration, Replication and State . . . . . . . . . . . . 138
9.14.1. Migration and State . . . . . . . . . . . . . . . . 139 9.14.1. Migration and State . . . . . . . . . . . . . . . . 138
9.14.2. Replication and State . . . . . . . . . . . . . . . 139 9.14.2. Replication and State . . . . . . . . . . . . . . . 139
9.14.3. Notification of Migrated Lease . . . . . . . . . . . 140 9.14.3. Notification of Migrated Lease . . . . . . . . . . . 140
9.14.4. Migration and the Lease_time Attribute . . . . . . . 141 9.14.4. Migration and the Lease_time Attribute . . . . . . . 141
10. Client-Side Caching . . . . . . . . . . . . . . . . . . . . . 141 10. Client-Side Caching . . . . . . . . . . . . . . . . . . . . . 141
10.1. Performance Challenges for Client-Side Caching . . . . . 142 10.1. Performance Challenges for Client-Side Caching . . . . . 142
10.2. Delegation and Callbacks . . . . . . . . . . . . . . . . 143 10.2. Delegation and Callbacks . . . . . . . . . . . . . . . . 143
10.2.1. Delegation Recovery . . . . . . . . . . . . . . . . 144 10.2.1. Delegation Recovery . . . . . . . . . . . . . . . . 144
10.3. Data Caching . . . . . . . . . . . . . . . . . . . . . . 146 10.3. Data Caching . . . . . . . . . . . . . . . . . . . . . . 146
10.3.1. Data Caching and OPENs . . . . . . . . . . . . . . . 147 10.3.1. Data Caching and OPENs . . . . . . . . . . . . . . . 147
10.3.2. Data Caching and File Locking . . . . . . . . . . . 148 10.3.2. Data Caching and File Locking . . . . . . . . . . . 148
10.3.3. Data Caching and Mandatory File Locking . . . . . . 149 10.3.3. Data Caching and Mandatory File Locking . . . . . . 149
10.3.4. Data Caching and File Identity . . . . . . . . . . . 150 10.3.4. Data Caching and File Identity . . . . . . . . . . . 150
10.4. Open Delegation . . . . . . . . . . . . . . . . . . . . 151 10.4. Open Delegation . . . . . . . . . . . . . . . . . . . . 151
10.4.1. Open Delegation and Data Caching . . . . . . . . . . 153 10.4.1. Open Delegation and Data Caching . . . . . . . . . . 153
10.4.2. Open Delegation and File Locks . . . . . . . . . . . 155 10.4.2. Open Delegation and File Locks . . . . . . . . . . . 154
10.4.3. Handling of CB_GETATTR . . . . . . . . . . . . . . . 155 10.4.3. Handling of CB_GETATTR . . . . . . . . . . . . . . . 155
10.4.4. Recall of Open Delegation . . . . . . . . . . . . . 158 10.4.4. Recall of Open Delegation . . . . . . . . . . . . . 158
10.4.5. OPEN Delegation Race with CB_RECALL . . . . . . . . 160 10.4.5. OPEN Delegation Race with CB_RECALL . . . . . . . . 160
10.4.6. Clients that Fail to Honor Delegation Recalls . . . 161 10.4.6. Clients that Fail to Honor Delegation Recalls . . . 160
10.4.7. Delegation Revocation . . . . . . . . . . . . . . . 162 10.4.7. Delegation Revocation . . . . . . . . . . . . . . . 161
10.5. Data Caching and Revocation . . . . . . . . . . . . . . 162 10.5. Data Caching and Revocation . . . . . . . . . . . . . . 162
10.5.1. Revocation Recovery for Write Open Delegation . . . 163 10.5.1. Revocation Recovery for Write Open Delegation . . . 162
10.6. Attribute Caching . . . . . . . . . . . . . . . . . . . 163 10.6. Attribute Caching . . . . . . . . . . . . . . . . . . . 163
10.7. Data and Metadata Caching and Memory Mapped Files . . . 165 10.7. Data and Metadata Caching and Memory Mapped Files . . . 165
10.8. Name Caching . . . . . . . . . . . . . . . . . . . . . . 167 10.8. Name Caching . . . . . . . . . . . . . . . . . . . . . . 167
10.9. Directory Caching . . . . . . . . . . . . . . . . . . . 168 10.9. Directory Caching . . . . . . . . . . . . . . . . . . . 168
11. Minor Versioning . . . . . . . . . . . . . . . . . . . . . . 169 11. Minor Versioning . . . . . . . . . . . . . . . . . . . . . . 169
12. Internationalization . . . . . . . . . . . . . . . . . . . . 172 12. Internationalization . . . . . . . . . . . . . . . . . . . . 172
12.1. Use of UTF-8 . . . . . . . . . . . . . . . . . . . . . . 173 12.1. Use of UTF-8 . . . . . . . . . . . . . . . . . . . . . . 173
12.1.1. Relation to Stringprep . . . . . . . . . . . . . . . 173 12.1.1. Relation to Stringprep . . . . . . . . . . . . . . . 173
12.1.2. Normalization, Equivalence, and Confusability . . . 174 12.1.2. Normalization, Equivalence, and Confusability . . . 174
12.2. String Type Overview . . . . . . . . . . . . . . . . . . 177 12.2. String Type Overview . . . . . . . . . . . . . . . . . . 176
12.2.1. Overall String Class Divisions . . . . . . . . . . . 177 12.2.1. Overall String Class Divisions . . . . . . . . . . . 177
12.2.2. Divisions by Typedef Parent types . . . . . . . . . 178 12.2.2. Divisions by Typedef Parent types . . . . . . . . . 178
12.2.3. Individual Types and Their Handling . . . . . . . . 179 12.2.3. Individual Types and Their Handling . . . . . . . . 178
12.3. Errors Related to Strings . . . . . . . . . . . . . . . 180 12.3. Errors Related to Strings . . . . . . . . . . . . . . . 180
12.4. Types with Pre-processing to Resolve Mixture Issues . . 181 12.4. Types with Pre-processing to Resolve Mixture Issues . . 181
12.4.1. Processing of Principal Strings . . . . . . . . . . 181 12.4.1. Processing of Principal Strings . . . . . . . . . . 181
12.4.2. Processing of Server Id Strings . . . . . . . . . . 181 12.4.2. Processing of Server Id Strings . . . . . . . . . . 181
12.5. String Types without Internationalization Processing . . 182 12.5. String Types without Internationalization Processing . . 182
12.6. Types with Processing Defined by Other Internet Areas . 182 12.6. Types with Processing Defined by Other Internet Areas . 182
12.7. String Types with NFS-specific Processing . . . . . . . 183 12.7. String Types with NFS-specific Processing . . . . . . . 183
12.7.1. Handling of File Name Components . . . . . . . . . . 184 12.7.1. Handling of File Name Components . . . . . . . . . . 184
12.7.2. Processing of Link Text . . . . . . . . . . . . . . 193 12.7.2. Processing of Link Text . . . . . . . . . . . . . . 193
12.7.3. Processing of Principal Prefixes . . . . . . . . . . 194 12.7.3. Processing of Principal Prefixes . . . . . . . . . . 194
13. Error Values . . . . . . . . . . . . . . . . . . . . . . . . 195 13. Error Values . . . . . . . . . . . . . . . . . . . . . . . . 195
13.1. Error Definitions . . . . . . . . . . . . . . . . . . . 195 13.1. Error Definitions . . . . . . . . . . . . . . . . . . . 195
13.1.1. General Errors . . . . . . . . . . . . . . . . . . . 197 13.1.1. General Errors . . . . . . . . . . . . . . . . . . . 196
13.1.2. Filehandle Errors . . . . . . . . . . . . . . . . . 198 13.1.2. Filehandle Errors . . . . . . . . . . . . . . . . . 198
13.1.3. Compound Structure Errors . . . . . . . . . . . . . 199 13.1.3. Compound Structure Errors . . . . . . . . . . . . . 199
13.1.4. File System Errors . . . . . . . . . . . . . . . . . 200 13.1.4. File System Errors . . . . . . . . . . . . . . . . . 200
13.1.5. State Management Errors . . . . . . . . . . . . . . 202 13.1.5. State Management Errors . . . . . . . . . . . . . . 202
13.1.6. Security Errors . . . . . . . . . . . . . . . . . . 203 13.1.6. Security Errors . . . . . . . . . . . . . . . . . . 203
13.1.7. Name Errors . . . . . . . . . . . . . . . . . . . . 203 13.1.7. Name Errors . . . . . . . . . . . . . . . . . . . . 203
13.1.8. Locking Errors . . . . . . . . . . . . . . . . . . . 204 13.1.8. Locking Errors . . . . . . . . . . . . . . . . . . . 204
13.1.9. Reclaim Errors . . . . . . . . . . . . . . . . . . . 205 13.1.9. Reclaim Errors . . . . . . . . . . . . . . . . . . . 205
13.1.10. Client Management Errors . . . . . . . . . . . . . . 206 13.1.10. Client Management Errors . . . . . . . . . . . . . . 206
13.1.11. Attribute Handling Errors . . . . . . . . . . . . . 206 13.1.11. Attribute Handling Errors . . . . . . . . . . . . . 206
skipping to change at page 116, line 12 skipping to change at page 116, line 12
WRITE operation had also acquired the appropriate byte-range lock on WRITE operation had also acquired the appropriate byte-range lock on
the file. Thus there was no way to implement mandatory locking. the file. Thus there was no way to implement mandatory locking.
With the stateid construct, this barrier has been removed. With the stateid construct, this barrier has been removed.
Note that for UNIX environments that support mandatory file locking, Note that for UNIX environments that support mandatory file locking,
the distinction between advisory and mandatory locking is subtle. In the distinction between advisory and mandatory locking is subtle. In
fact, advisory and mandatory byte-range locks are exactly the same in fact, advisory and mandatory byte-range locks are exactly the same in
so far as the APIs and requirements on implementation. If the so far as the APIs and requirements on implementation. If the
mandatory lock attribute is set on the file, the server checks to see mandatory lock attribute is set on the file, the server checks to see
if the lockowner has an appropriate shared (read) or exclusive if the lock-owner has an appropriate shared (read) or exclusive
(write) byte-range lock on the region it wishes to read or write to. (write) byte-range lock on the region it wishes to read or write to.
If there is no appropriate lock, the server checks if there is a If there is no appropriate lock, the server checks if there is a
conflicting lock (which can be done by attempting to acquire the conflicting lock (which can be done by attempting to acquire the
conflicting lock on the behalf of the lockowner, and if successful, conflicting lock on the behalf of the lock-owner, and if successful,
release the lock after the READ or WRITE is done), and if there is, release the lock after the READ or WRITE is done), and if there is,
the server returns NFS4ERR_LOCKED. the server returns NFS4ERR_LOCKED.
For Windows environments, there are no advisory byte-range locks, so For Windows environments, there are no advisory byte-range locks, so
the server always checks for byte-range locks during I/O requests. the server always checks for byte-range locks during I/O requests.
Thus, the NFSv4 LOCK operation does not need to distinguish between Thus, the NFSv4 LOCK operation does not need to distinguish between
advisory and mandatory byte-range locks. It is the NFS version 4 advisory and mandatory byte-range locks. It is the NFS version 4
server's processing of the READ and WRITE operations that introduces server's processing of the READ and WRITE operations that introduces
the distinction. the distinction.
skipping to change at page 121, line 9 skipping to change at page 121, line 9
troublesome because recovering from non-confirmation adds undue troublesome because recovering from non-confirmation adds undue
complexity to the protocol while requiring confirmation on reclaim- complexity to the protocol while requiring confirmation on reclaim-
type opens poses difficulties in that the inability to resolve the type opens poses difficulties in that the inability to resolve the
status of the reclaim until lease expiration may make it difficult to status of the reclaim until lease expiration may make it difficult to
have timely determination of the set of locks being reclaimed (since have timely determination of the set of locks being reclaimed (since
the grace period may expire). the grace period may expire).
Requiring open confirmation on reclaim-type opens is avoidable Requiring open confirmation on reclaim-type opens is avoidable
because of the nature of the environments in which such opens are because of the nature of the environments in which such opens are
done. For CLAIM_PREVIOUS opens, this is immediately after server done. For CLAIM_PREVIOUS opens, this is immediately after server
reboot, so there should be no time for lockowners to be created, reboot, so there should be no time for open-owners to be created,
found to be unused, and recycled. For CLAIM_DELEGATE_PREV opens, we found to be unused, and recycled. For CLAIM_DELEGATE_PREV opens, we
are dealing with a client reboot situation. A server which supports are dealing with a client reboot situation. A server which supports
delegation can be sure that no lockowners for that client have been delegation can be sure that no open-owners for that client have been
recycled since client initialization and thus can ensure that recycled since client initialization and thus can ensure that
confirmation will not be required. confirmation will not be required.
9.2. Lock Ranges 9.2. Lock Ranges
The protocol allows a lock owner to request a lock with a byte range The protocol allows a lock owner to request a lock with a byte range
and then either upgrade or unlock a sub-range of the initial lock. and then either upgrade or unlock a sub-range of the initial lock.
It is expected that this will be an uncommon type of request. In any It is expected that this will be an uncommon type of request. In any
case, servers or server filesystems may not be able to support sub- case, servers or server filesystems may not be able to support sub-
range lock semantics. In the event that a server receives a locking range lock semantics. In the event that a server receives a locking
skipping to change at page 124, line 19 skipping to change at page 124, line 19
9.6.1. Client Failure and Recovery 9.6.1. Client Failure and Recovery
In the event that a client fails, the server may recover the client's In the event that a client fails, the server may recover the client's
locks when the associated leases have expired. Conflicting locks locks when the associated leases have expired. Conflicting locks
from another client may only be granted after this lease expiration. from another client may only be granted after this lease expiration.
If the client is able to restart or reinitialize within the lease If the client is able to restart or reinitialize within the lease
period the client may be forced to wait the remainder of the lease period the client may be forced to wait the remainder of the lease
period before obtaining new locks. period before obtaining new locks.
To minimize client delay upon restart, lock requests are associated To minimize client delay upon restart, open and lock requests are
with an instance of the client by a client supplied verifier. This associated with an instance of the client by a client supplied
verifier is part of the initial SETCLIENTID call made by the client. verifier. This verifier is part of the initial SETCLIENTID call made
The server returns a client ID as a result of the SETCLIENTID by the client. The server returns a client ID as a result of the
operation. The client then confirms the use of the client ID with SETCLIENTID operation. The client then confirms the use of the
SETCLIENTID_CONFIRM. The client ID in combination with an opaque client ID with SETCLIENTID_CONFIRM. The client ID in combination
owner field is then used by the client to identify the lock owner for with an opaque owner field is then used by the client to identify the
OPEN. This chain of associations is then used to identify all locks open owner for OPEN. This chain of associations is then used to
for a particular client. identify all locks for a particular client.
Since the verifier will be changed by the client upon each Since the verifier will be changed by the client upon each
initialization, the server can compare a new verifier to the verifier initialization, the server can compare a new verifier to the verifier
associated with currently held locks and determine that they do not associated with currently held locks and determine that they do not
match. This signifies the client's new instantiation and subsequent match. This signifies the client's new instantiation and subsequent
loss of locking state. As a result, the server is free to release loss of locking state. As a result, the server is free to release
all locks held which are associated with the old client ID which was all locks held which are associated with the old client ID which was
derived from the old verifier. derived from the old verifier.
Note that the verifier must have the same uniqueness properties of Note that the verifier must have the same uniqueness properties of
skipping to change at page 129, line 19 skipping to change at page 129, line 19
Solving these edge conditions requires that the server either assume Solving these edge conditions requires that the server either assume
after it reboots that edge condition occurs, and thus return after it reboots that edge condition occurs, and thus return
NFS4ERR_NO_GRACE for all reclaim attempts, or that the server record NFS4ERR_NO_GRACE for all reclaim attempts, or that the server record
some information in stable storage. The amount of information the some information in stable storage. The amount of information the
server records in stable storage is in inverse proportion to how server records in stable storage is in inverse proportion to how
harsh the server wants to be whenever the edge conditions occur. The harsh the server wants to be whenever the edge conditions occur. The
server that is completely tolerant of all edge conditions will record server that is completely tolerant of all edge conditions will record
in stable storage every lock that is acquired, removing the lock in stable storage every lock that is acquired, removing the lock
record from stable storage only when the lock is unlocked by the record from stable storage only when the lock is unlocked by the
client and the lock's lockowner advances the sequence number such client and the lock's owner advances the sequence number such that
that the lock release is not the last stateful event for the the lock release is not the last stateful event for the owner's
lockowner's sequence. For the two aforementioned edge conditions, sequence. For the two aforementioned edge conditions, the harshest a
the harshest a server can be, and still support a grace period for server can be, and still support a grace period for reclaims,
reclaims, requires that the server record in stable storage requires that the server record in stable storage information some
information some minimal information. For example, a server minimal information. For example, a server implementation could, for
implementation could, for each client, save in stable storage a each client, save in stable storage a record containing:
record containing:
o the client's id string o the client's id string
o a boolean that indicates if the client's lease expired or if there o a boolean that indicates if the client's lease expired or if there
was administrative intervention (see Section 9.8) to revoke a was administrative intervention (see Section 9.8) to revoke a
byte-range lock, share reservation, or delegation byte-range lock, share reservation, or delegation
o a timestamp that is updated the first time after a server boot or o a timestamp that is updated the first time after a server boot or
reboot the client acquires byte-range locking, share reservation, reboot the client acquires byte-range locking, share reservation,
or delegation state on the server. The timestamp need not be or delegation state on the server. The timestamp need not be
skipping to change at page 136, line 29 skipping to change at page 136, line 24
the greatest degree assurance that the protocol is being used the greatest degree assurance that the protocol is being used
properly, a server should, rather than deallocate the stateid, mark properly, a server should, rather than deallocate the stateid, mark
it as close-pending, and retain the stateid with this status, until it as close-pending, and retain the stateid with this status, until
later deallocation. In this way, a retransmitted CLOSE can be later deallocation. In this way, a retransmitted CLOSE can be
recognized since the stateid points to state information with this recognized since the stateid points to state information with this
distinctive status, so that it can be handled without error. distinctive status, so that it can be handled without error.
When adopting this strategy, a server should retain the state When adopting this strategy, a server should retain the state
information until the earliest of: information until the earliest of:
o Another validly sequenced request for the same lockowner, that is o Another validly sequenced request for the same open-owner, that is
not a retransmission. not a retransmission.
o The time that a lockowner is freed by the server due to period o The time that an open-owner is freed by the server due to period
with no activity. with no activity.
o All locks for the client are freed as a result of a SETCLIENTID. o All locks for the client are freed as a result of a SETCLIENTID.
Servers may avoid this complexity, at the cost of less complete Servers may avoid this complexity, at the cost of less complete
protocol error checking, by simply responding NFS4_OK in the event of protocol error checking, by simply responding NFS4_OK in the event of
a CLOSE for a deallocated stateid, on the assumption that this case a CLOSE for a deallocated stateid, on the assumption that this case
must be caused by a retransmitted close. When adopting this must be caused by a retransmitted close. When adopting this
approach, it is desirable to at least log an error when returning a approach, it is desirable to at least log an error when returning a
no-error indication in this situation. If the server maintains a no-error indication in this situation. If the server maintains a
reply-cache mechanism, it can verify the CLOSE is indeed a reply-cache mechanism, it can verify the CLOSE is indeed a
retransmission and avoid error logging in most cases. retransmission and avoid error logging in most cases.
9.11. Open Upgrade and Downgrade 9.11. Open Upgrade and Downgrade
When an OPEN is done for a file and the lockowner for which the open When an OPEN is done for a file and the open-owner for which the open
is being done already has the file open, the result is to upgrade the is being done already has the file open, the result is to upgrade the
open file status maintained on the server to include the access and open file status maintained on the server to include the access and
deny bits specified by the new OPEN as well as those for the existing deny bits specified by the new OPEN as well as those for the existing
OPEN. The result is that there is one open file, as far as the OPEN. The result is that there is one open file, as far as the
protocol is concerned, and it includes the union of the access and protocol is concerned, and it includes the union of the access and
deny bits for all of the OPEN requests completed. Only a single deny bits for all of the OPEN requests completed. Only a single
CLOSE will be done to reset the effects of both OPENs. Note that the CLOSE will be done to reset the effects of both OPENs. Note that the
client, when issuing the OPEN, may not know that the same file is in client, when issuing the OPEN, may not know that the same file is in
fact being opened. The above only applies if both OPENs result in fact being opened. The above only applies if both OPENs result in
the OPENed object being designated by the same filehandle. the OPENed object being designated by the same filehandle.
skipping to change at page 202, line 34 skipping to change at page 202, line 28
13.1.5.1. NFS4ERR_ADMIN_REVOKED (Error Code 10047) 13.1.5.1. NFS4ERR_ADMIN_REVOKED (Error Code 10047)
A stateid designates locking state of any type that has been revoked A stateid designates locking state of any type that has been revoked
due to administrative interaction, possibly while the lease is valid. due to administrative interaction, possibly while the lease is valid.
13.1.5.2. NFS4ERR_BAD_STATEID (Error Code 10026) 13.1.5.2. NFS4ERR_BAD_STATEID (Error Code 10026)
A stateid generated by the current server instance, but which does A stateid generated by the current server instance, but which does
not designate any locking state (either current or superseded) for a not designate any locking state (either current or superseded) for a
current lockowner-file pair, was used. current (state-owner, file) pair, was used.
13.1.5.3. NFS4ERR_EXPIRED (Error Code 10011) 13.1.5.3. NFS4ERR_EXPIRED (Error Code 10011)
A stateid designates locking state of any type that has been revoked A stateid designates locking state of any type that has been revoked
due to expiration of the client's lease, either immediately upon due to expiration of the client's lease, either immediately upon
lease expiration, or following a later request for a conflicting lease expiration, or following a later request for a conflicting
lock. lock.
13.1.5.4. NFS4ERR_LEASE_MOVED (Error Code 10031) 13.1.5.4. NFS4ERR_LEASE_MOVED (Error Code 10031)
skipping to change at page 244, line 18 skipping to change at page 244, line 18
The locker argument specifies the lock-owner that is associated with The locker argument specifies the lock-owner that is associated with
the LOCK request. The locker4 structure is a switched union that the LOCK request. The locker4 structure is a switched union that
indicates whether the client has already created byte-range locking indicates whether the client has already created byte-range locking
state associated with the current open file and lock-owner. There state associated with the current open file and lock-owner. There
are multiple cases to be considered, corresponding to possible are multiple cases to be considered, corresponding to possible
combinations of whether locking state has been created for the combinations of whether locking state has been created for the
current open file and lock-owner, and whether the boolean current open file and lock-owner, and whether the boolean
new_lock_owner is set. In all of the cases, there is a lock_seqid new_lock_owner is set. In all of the cases, there is a lock_seqid
specified, whether the lock-owner is specified explicitly or specified, whether the lock-owner is specified explicitly or
implicitly. This seqid value is used for checking lockowner implicitly. This seqid value is used for checking lock-owner
sequencing/replay issues. When the given lockowner is not known to sequencing/replay issues. When the given lock-owner is not known to
the server, this establishes an initial sequence value for the new the server, this establishes an initial sequence value for the new
lockowner. lock-owner.
o In the case in which the state has been created and the boolean is o In the case in which the state has been created and the boolean is
false, the only part of the argument other than lock_seqid is just false, the only part of the argument other than lock_seqid is just
a stateid representing the set of locks associated with that open a stateid representing the set of locks associated with that open
file and lock-owner. file and lock-owner.
o In the case in which the state has been created and the boolean is o In the case in which the state has been created and the boolean is
true, the server rejects the request with the error true, the server rejects the request with the error
NFS4ERR_BADSEQ. The only exception is where there is a NFS4ERR_BADSEQ. The only exception is where there is a
retransmission of a previous request in which the boolean was retransmission of a previous request in which the boolean was
skipping to change at page 265, line 21 skipping to change at page 265, line 21
union OPEN_DOWNGRADE4res switch(nfsstat4 status) { union OPEN_DOWNGRADE4res switch(nfsstat4 status) {
case NFS4_OK: case NFS4_OK:
OPEN_DOWNGRADE4resok resok4; OPEN_DOWNGRADE4resok resok4;
default: default:
void; void;
}; };
15.21.4. DESCRIPTION 15.21.4. DESCRIPTION
This operation is used to adjust the share_access and share_deny bits This operation is used to adjust the share_access and share_deny bits
for a given open. This is necessary when a given openowner opens the for a given open. This is necessary when a given open-owner opens
same file multiple times with different share_access and share_deny the same file multiple times with different share_access and
flags. In this situation, a close of one of the opens may change the share_deny flags. In this situation, a close of one of the opens may
appropriate share_access and share_deny flags to remove bits change the appropriate share_access and share_deny flags to remove
associated with opens no longer in effect. bits associated with opens no longer in effect.
The share_access and share_deny bits specified in this operation The share_access and share_deny bits specified in this operation
replace the current ones for the specified open file. The replace the current ones for the specified open file. The
share_access and share_deny bits specified must be exactly equal to share_access and share_deny bits specified must be exactly equal to
the union of the share_access and share_deny bits specified for some the union of the share_access and share_deny bits specified for some
subset of the OPENs in effect for current openowner on the current subset of the OPENs in effect for current open-owner on the current
file. If that constraint is not respected, the error NFS4ERR_INVAL file. If that constraint is not respected, the error NFS4ERR_INVAL
should be returned. Since share_access and share_deny bits are should be returned. Since share_access and share_deny bits are
subsets of those already granted, it is not possible for this request subsets of those already granted, it is not possible for this request
to be denied because of conflicting share reservations. to be denied because of conflicting share reservations.
As the OPEN_DOWNGRADE may change a file to be not-open-for-write and As the OPEN_DOWNGRADE may change a file to be not-open-for-write and
a write byte-range lock might be held, the server may have to reject a write byte-range lock might be held, the server may have to reject
the OPEN_DOWNGRADE with a NFS4ERR_LOCKS_HELD. the OPEN_DOWNGRADE with a NFS4ERR_LOCKS_HELD.
On success, the current filehandle retains its value. On success, the current filehandle retains its value.
 End of changes. 26 change blocks. 
48 lines changed or deleted 47 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/