draft-ietf-nfsv4-rfc3530bis-11.txt   draft-ietf-nfsv4-rfc3530bis-12.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: October 6, 2011 EMC Expires: October 10, 2011 EMC
April 04, 2011 April 08, 2011
Network File System (NFS) Version 4 Protocol Network File System (NFS) Version 4 Protocol
draft-ietf-nfsv4-rfc3530bis-11.txt draft-ietf-nfsv4-rfc3530bis-12.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 48 skipping to change at page 1, line 48
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 October 6, 2011. This Internet-Draft will expire on October 10, 2011.
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 19 skipping to change at page 5, line 19
8.8. Security Policy and Name Space Presentation . . . . . . 105 8.8. Security Policy and Name Space Presentation . . . . . . 105
9. File Locking and Share Reservations . . . . . . . . . . . . . 106 9. File Locking and Share Reservations . . . . . . . . . . . . . 106
9.1. Opens and Byte-Range Locks . . . . . . . . . . . . . . . 107 9.1. Opens and Byte-Range Locks . . . . . . . . . . . . . . . 107
9.1.1. Client ID . . . . . . . . . . . . . . . . . . . . . 107 9.1.1. Client ID . . . . . . . . . . . . . . . . . . . . . 107
9.1.2. Server Release of Client ID . . . . . . . . . . . . 110 9.1.2. Server Release of Client ID . . . . . . . . . . . . 110
9.1.3. Stateid Definition . . . . . . . . . . . . . . . . . 111 9.1.3. Stateid Definition . . . . . . . . . . . . . . . . . 111
9.1.4. lock-owner . . . . . . . . . . . . . . . . . . . . . 118 9.1.4. lock-owner . . . . . . . . . . . . . . . . . . . . . 118
9.1.5. Use of the Stateid and Locking . . . . . . . . . . . 119 9.1.5. Use of the Stateid and Locking . . . . . . . . . . . 119
9.1.6. Sequencing of Lock Requests . . . . . . . . . . . . 121 9.1.6. Sequencing of Lock Requests . . . . . . . . . . . . 121
9.1.7. Recovery from Replayed Requests . . . . . . . . . . 122 9.1.7. Recovery from Replayed Requests . . . . . . . . . . 122
9.1.8. Releasing lock-owner State . . . . . . . . . . . . . 122 9.1.8. Releasing state-owner State . . . . . . . . . . . . 122
9.1.9. Use of Open Confirmation . . . . . . . . . . . . . . 123 9.1.9. Use of Open Confirmation . . . . . . . . . . . . . . 123
9.2. Lock Ranges . . . . . . . . . . . . . . . . . . . . . . 124 9.2. Lock Ranges . . . . . . . . . . . . . . . . . . . . . . 124
9.3. Upgrading and Downgrading Locks . . . . . . . . . . . . 124 9.3. Upgrading and Downgrading Locks . . . . . . . . . . . . 124
9.4. Blocking Locks . . . . . . . . . . . . . . . . . . . . . 125 9.4. Blocking Locks . . . . . . . . . . . . . . . . . . . . . 125
9.5. Lease Renewal . . . . . . . . . . . . . . . . . . . . . 126 9.5. Lease Renewal . . . . . . . . . . . . . . . . . . . . . 125
9.6. Crash Recovery . . . . . . . . . . . . . . . . . . . . . 126 9.6. Crash Recovery . . . . . . . . . . . . . . . . . . . . . 126
9.6.1. Client Failure and Recovery . . . . . . . . . . . . 127 9.6.1. Client Failure and Recovery . . . . . . . . . . . . 127
9.6.2. Server Failure and Recovery . . . . . . . . . . . . 127 9.6.2. Server Failure and Recovery . . . . . . . . . . . . 127
9.6.3. Network Partitions and Recovery . . . . . . . . . . 129 9.6.3. Network Partitions and Recovery . . . . . . . . . . 129
9.7. Recovery from a Lock Request Timeout or Abort . . . . . 136 9.7. Recovery from a Lock Request Timeout or Abort . . . . . 135
9.8. Server Revocation of Locks . . . . . . . . . . . . . . . 136 9.8. Server Revocation of Locks . . . . . . . . . . . . . . . 136
9.9. Share Reservations . . . . . . . . . . . . . . . . . . . 137 9.9. Share Reservations . . . . . . . . . . . . . . . . . . . 137
9.10. OPEN/CLOSE Operations . . . . . . . . . . . . . . . . . 138 9.10. OPEN/CLOSE Operations . . . . . . . . . . . . . . . . . 138
9.10.1. Close and Retention of State Information . . . . . . 139 9.10.1. Close and Retention of State Information . . . . . . 138
9.11. Open Upgrade and Downgrade . . . . . . . . . . . . . . . 139 9.11. Open Upgrade and Downgrade . . . . . . . . . . . . . . . 139
9.12. Short and Long Leases . . . . . . . . . . . . . . . . . 140 9.12. Short and Long Leases . . . . . . . . . . . . . . . . . 140
9.13. Clocks, Propagation Delay, and Calculating Lease 9.13. Clocks, Propagation Delay, and Calculating Lease
Expiration . . . . . . . . . . . . . . . . . . . . . . . 141 Expiration . . . . . . . . . . . . . . . . . . . . . . . 140
9.14. Migration, Replication and State . . . . . . . . . . . . 141 9.14. Migration, Replication and State . . . . . . . . . . . . 141
9.14.1. Migration and State . . . . . . . . . . . . . . . . 142 9.14.1. Migration and State . . . . . . . . . . . . . . . . 141
9.14.2. Replication and State . . . . . . . . . . . . . . . 142 9.14.2. Replication and State . . . . . . . . . . . . . . . 142
9.14.3. Notification of Migrated Lease . . . . . . . . . . . 143 9.14.3. Notification of Migrated Lease . . . . . . . . . . . 143
9.14.4. Migration and the Lease_time Attribute . . . . . . . 144 9.14.4. Migration and the Lease_time Attribute . . . . . . . 143
10. Client-Side Caching . . . . . . . . . . . . . . . . . . . . . 144 10. Client-Side Caching . . . . . . . . . . . . . . . . . . . . . 144
10.1. Performance Challenges for Client-Side Caching . . . . . 145 10.1. Performance Challenges for Client-Side Caching . . . . . 145
10.2. Delegation and Callbacks . . . . . . . . . . . . . . . . 146 10.2. Delegation and Callbacks . . . . . . . . . . . . . . . . 146
10.2.1. Delegation Recovery . . . . . . . . . . . . . . . . 147 10.2.1. Delegation Recovery . . . . . . . . . . . . . . . . 147
10.3. Data Caching . . . . . . . . . . . . . . . . . . . . . . 149 10.3. Data Caching . . . . . . . . . . . . . . . . . . . . . . 149
10.3.1. Data Caching and OPENs . . . . . . . . . . . . . . . 150 10.3.1. Data Caching and OPENs . . . . . . . . . . . . . . . 150
10.3.2. Data Caching and File Locking . . . . . . . . . . . 151 10.3.2. Data Caching and File Locking . . . . . . . . . . . 151
10.3.3. Data Caching and Mandatory File Locking . . . . . . 152 10.3.3. Data Caching and Mandatory File Locking . . . . . . 152
10.3.4. Data Caching and File Identity . . . . . . . . . . . 153 10.3.4. Data Caching and File Identity . . . . . . . . . . . 153
10.4. Open Delegation . . . . . . . . . . . . . . . . . . . . 154 10.4. Open Delegation . . . . . . . . . . . . . . . . . . . . 154
10.4.1. Open Delegation and Data Caching . . . . . . . . . . 156 10.4.1. Open Delegation and Data Caching . . . . . . . . . . 156
10.4.2. Open Delegation and File Locks . . . . . . . . . . . 158 10.4.2. Open Delegation and File Locks . . . . . . . . . . . 157
10.4.3. Handling of CB_GETATTR . . . . . . . . . . . . . . . 158 10.4.3. Handling of CB_GETATTR . . . . . . . . . . . . . . . 158
10.4.4. Recall of Open Delegation . . . . . . . . . . . . . 161 10.4.4. Recall of Open Delegation . . . . . . . . . . . . . 161
10.4.5. OPEN Delegation Race with CB_RECALL . . . . . . . . 163 10.4.5. OPEN Delegation Race with CB_RECALL . . . . . . . . 163
10.4.6. Clients that Fail to Honor Delegation Recalls . . . 164 10.4.6. Clients that Fail to Honor Delegation Recalls . . . 163
10.4.7. Delegation Revocation . . . . . . . . . . . . . . . 165 10.4.7. Delegation Revocation . . . . . . . . . . . . . . . 164
10.5. Data Caching and Revocation . . . . . . . . . . . . . . 165 10.5. Data Caching and Revocation . . . . . . . . . . . . . . 165
10.5.1. Revocation Recovery for Write Open Delegation . . . 166 10.5.1. Revocation Recovery for Write Open Delegation . . . 165
10.6. Attribute Caching . . . . . . . . . . . . . . . . . . . 166 10.6. Attribute Caching . . . . . . . . . . . . . . . . . . . 166
10.7. Data and Metadata Caching and Memory Mapped Files . . . 168 10.7. Data and Metadata Caching and Memory Mapped Files . . . 168
10.8. Name Caching . . . . . . . . . . . . . . . . . . . . . . 170 10.8. Name Caching . . . . . . . . . . . . . . . . . . . . . . 170
10.9. Directory Caching . . . . . . . . . . . . . . . . . . . 171 10.9. Directory Caching . . . . . . . . . . . . . . . . . . . 171
11. Minor Versioning . . . . . . . . . . . . . . . . . . . . . . 172 11. Minor Versioning . . . . . . . . . . . . . . . . . . . . . . 172
12. Internationalization . . . . . . . . . . . . . . . . . . . . 175 12. Internationalization . . . . . . . . . . . . . . . . . . . . 175
12.1. Use of UTF-8 . . . . . . . . . . . . . . . . . . . . . . 176 12.1. Use of UTF-8 . . . . . . . . . . . . . . . . . . . . . . 176
12.1.1. Relation to Stringprep . . . . . . . . . . . . . . . 176 12.1.1. Relation to Stringprep . . . . . . . . . . . . . . . 176
12.1.2. Normalization, Equivalence, and Confusability . . . 177 12.1.2. Normalization, Equivalence, and Confusability . . . 177
12.2. String Type Overview . . . . . . . . . . . . . . . . . . 180 12.2. String Type Overview . . . . . . . . . . . . . . . . . . 179
12.2.1. Overall String Class Divisions . . . . . . . . . . . 180 12.2.1. Overall String Class Divisions . . . . . . . . . . . 180
12.2.2. Divisions by Typedef Parent types . . . . . . . . . 181 12.2.2. Divisions by Typedef Parent types . . . . . . . . . 181
12.2.3. Individual Types and Their Handling . . . . . . . . 182 12.2.3. Individual Types and Their Handling . . . . . . . . 181
12.3. Errors Related to Strings . . . . . . . . . . . . . . . 183 12.3. Errors Related to Strings . . . . . . . . . . . . . . . 183
12.4. Types with Pre-processing to Resolve Mixture Issues . . 184 12.4. Types with Pre-processing to Resolve Mixture Issues . . 184
12.4.1. Processing of Principal Strings . . . . . . . . . . 184 12.4.1. Processing of Principal Strings . . . . . . . . . . 184
12.4.2. Processing of Server Id Strings . . . . . . . . . . 184 12.4.2. Processing of Server Id Strings . . . . . . . . . . 184
12.5. String Types without Internationalization Processing . . 185 12.5. String Types without Internationalization Processing . . 185
12.6. Types with Processing Defined by Other Internet Areas . 185 12.6. Types with Processing Defined by Other Internet Areas . 185
12.7. String Types with NFS-specific Processing . . . . . . . 186 12.7. String Types with NFS-specific Processing . . . . . . . 186
12.7.1. Handling of File Name Components . . . . . . . . . . 187 12.7.1. Handling of File Name Components . . . . . . . . . . 187
12.7.2. Processing of Link Text . . . . . . . . . . . . . . 196 12.7.2. Processing of Link Text . . . . . . . . . . . . . . 196
12.7.3. Processing of Principal Prefixes . . . . . . . . . . 197 12.7.3. Processing of Principal Prefixes . . . . . . . . . . 197
13. Error Values . . . . . . . . . . . . . . . . . . . . . . . . 198 13. Error Values . . . . . . . . . . . . . . . . . . . . . . . . 198
13.1. Error Definitions . . . . . . . . . . . . . . . . . . . 198 13.1. Error Definitions . . . . . . . . . . . . . . . . . . . 198
13.1.1. General Errors . . . . . . . . . . . . . . . . . . . 200 13.1.1. General Errors . . . . . . . . . . . . . . . . . . . 199
13.1.2. Filehandle Errors . . . . . . . . . . . . . . . . . 201 13.1.2. Filehandle Errors . . . . . . . . . . . . . . . . . 201
13.1.3. Compound Structure Errors . . . . . . . . . . . . . 202 13.1.3. Compound Structure Errors . . . . . . . . . . . . . 202
13.1.4. File System Errors . . . . . . . . . . . . . . . . . 203 13.1.4. File System Errors . . . . . . . . . . . . . . . . . 203
13.1.5. State Management Errors . . . . . . . . . . . . . . 205 13.1.5. State Management Errors . . . . . . . . . . . . . . 205
13.1.6. Security Errors . . . . . . . . . . . . . . . . . . 206 13.1.6. Security Errors . . . . . . . . . . . . . . . . . . 206
13.1.7. Name Errors . . . . . . . . . . . . . . . . . . . . 206 13.1.7. Name Errors . . . . . . . . . . . . . . . . . . . . 206
13.1.8. Locking Errors . . . . . . . . . . . . . . . . . . . 207 13.1.8. Locking Errors . . . . . . . . . . . . . . . . . . . 207
13.1.9. Reclaim Errors . . . . . . . . . . . . . . . . . . . 208 13.1.9. Reclaim Errors . . . . . . . . . . . . . . . . . . . 208
13.1.10. Client Management Errors . . . . . . . . . . . . . . 209 13.1.10. Client Management Errors . . . . . . . . . . . . . . 209
13.1.11. Attribute Handling Errors . . . . . . . . . . . . . 209 13.1.11. Attribute Handling Errors . . . . . . . . . . . . . 209
skipping to change at page 10, line 46 skipping to change at page 10, line 46
their size. their size.
o Added the mounted_on_filed attribute to allow Posix clients to o Added the mounted_on_filed attribute to allow Posix clients to
correctly construct local mounts. correctly construct local mounts.
o Modified the SETCLIENTID/SETCLIENTID_CONFIRM operations to deal o Modified the SETCLIENTID/SETCLIENTID_CONFIRM operations to deal
correctly with confirmation details along with adding the ability correctly with confirmation details along with adding the ability
to specify new client callback information. Also added to specify new client callback information. Also added
clarification of the callback information itself. clarification of the callback information itself.
o Added a new operation LOCKOWNER_RELEASE to enable notifying the o Added a new operation RELEASE_LOCKOWNER to enable notifying the
server that a lock_owner4 will no longer be used by the client. server that a lock_owner4 will no longer be used by the client.
o RENEW operation changes to identify the client correctly and allow o RENEW operation changes to identify the client correctly and allow
for additional error returns. for additional error returns.
o Verify error return possibilities for all operations. o Verify error return possibilities for all operations.
o Remove use of the pathname4 data type from LOOKUP and OPEN in o Remove use of the pathname4 data type from LOOKUP and OPEN in
favor of having the client construct a sequence of LOOKUP favor of having the client construct a sequence of LOOKUP
operations to achieve the same effect. operations to achieve the same effect.
skipping to change at page 18, line 15 skipping to change at page 18, line 15
(2) An immediate reply disk drive with battery-backed on-drive (2) An immediate reply disk drive with battery-backed on-drive
intermediate storage or uninterruptible power system (UPS). intermediate storage or uninterruptible power system (UPS).
(3) Server commit of data with battery-backed intermediate (3) Server commit of data with battery-backed intermediate
storage and recovery software. storage and recovery software.
(4) Cache commit with uninterruptible power system (UPS) and (4) Cache commit with uninterruptible power system (UPS) and
recovery software. recovery software.
Stateid: A stateid is a 128-bit quantity returned by a server that Stateid: A stateid is a 128-bit quantity returned by a server that
uniquely defines the open and locking states provided by the uniquely identifies the open and locking states provided by the
server for a specific open-owner or lock-owner/open-owner pair for server for a specific open-owner or lock-owner/open-owner pair for
a specific file and type of lock. a specific file and type of lock.
Verifier: A 64-bit quantity generated by the client that the server Verifier: A 64-bit quantity generated by the client that the server
can use to determine if the client has restarted and lost all can use to determine if the client has restarted and lost all
previous lock state. previous lock state.
2. Protocol Data Types 2. Protocol Data Types
The syntax and semantics to describe the data types of the NFS The syntax and semantics to describe the data types of the NFS
skipping to change at page 108, line 14 skipping to change at page 108, line 14
and remain separate even if the same opaque arrays are used to and remain separate even if the same opaque arrays are used to
designate owners of each. The protocol distinguishes between open- designate owners of each. The protocol distinguishes between open-
owners (represented by open_owner4 structures) and lock-owners owners (represented by open_owner4 structures) and lock-owners
(represented by lock_owner4 structures). (represented by lock_owner4 structures).
Each open is associated with a specific open-owner while each byte- Each open is associated with a specific open-owner while each byte-
range lock is associated with a lock-owner and an open-owner, the range lock is associated with a lock-owner and an open-owner, the
latter being the open-owner associated with the open file under which latter being the open-owner associated with the open file under which
the LOCK operation was done. the LOCK operation was done.
Unlike the text in NFSv4.1 [31], this text treats "lock-owner" as
meaning both a open-owner and a lock-owner. Also, a "lock" can refer
to both a byte-range and share lock.
Client identification is encapsulated in the following structure: Client identification is encapsulated in the following structure:
struct nfs_client_id4 { struct nfs_client_id4 {
verifier4 verifier; verifier4 verifier;
opaque id<NFS4_OPAQUE_LIMIT>; opaque id<NFS4_OPAQUE_LIMIT>;
}; };
The first field, verifier is a client incarnation verifier that is The first field, verifier is a client incarnation verifier that is
used to detect client reboots. Only if the verifier is different used to detect client reboots. Only if the verifier is different
from that which the server has previously recorded the client (as from that which the server has previously recorded the client (as
skipping to change at page 111, line 32 skipping to change at page 111, line 26
expired, rather than returning NFS4ERR_CLID_INUSE, the server MUST expired, rather than returning NFS4ERR_CLID_INUSE, the server MUST
allow the SETCLIENTID, and confirm the new client ID if followed by allow the SETCLIENTID, and confirm the new client ID if followed by
the appropriate SETCLIENTID_CONFIRM. the appropriate SETCLIENTID_CONFIRM.
9.1.3. Stateid Definition 9.1.3. Stateid Definition
When the server grants a lock of any type (including opens, byte- When the server grants a lock of any type (including opens, byte-
range locks, and delegations), it responds with a unique stateid that range locks, and delegations), it responds with a unique stateid that
represents a set of locks (often a single lock) for the same file, of represents a set of locks (often a single lock) for the same file, of
the same type, and sharing the same ownership characteristics. Thus, the same type, and sharing the same ownership characteristics. Thus,
opens of the same file by different open- owners each have an opens of the same file by different open-owners each have an
identifying stateid. Similarly, each set of byte-range locks on a identifying stateid. Similarly, each set of byte-range locks on a
file owned by a specific lock-owner has its own identifying stateid. file owned by a specific lock-owner has its own identifying stateid.
Delegations also have associated stateids by which they may be Delegations also have associated stateids by which they may be
referenced. The stateid is used as a shorthand reference to a lock referenced. The stateid is used as a shorthand reference to a lock
or set of locks, and given a stateid, the server can determine the or set of locks, and given a stateid, the server can determine the
associated state-owner or state-owners (in the case of an open-owner/ associated state-owner or state-owners (in the case of an open-owner/
lock-owner pair) and the associated filehandle. When stateids are lock-owner pair) and the associated filehandle. When stateids are
used, the current filehandle must be the one associated with that used, the current filehandle must be the one associated with that
stateid. stateid.
skipping to change at page 118, line 15 skipping to change at page 118, line 6
o If the client holds a delegation for the file in question, the o If the client holds a delegation for the file in question, the
delegation stateid SHOULD be used. delegation stateid SHOULD be used.
o Otherwise, if the entity corresponding to the lock-owner (e.g., a o Otherwise, if the entity corresponding to the lock-owner (e.g., a
process) sending the I/O has a byte-range lock stateid for the process) sending the I/O has a byte-range lock stateid for the
associated open file, then the byte-range lock stateid for that associated open file, then the byte-range lock stateid for that
lock-owner and open file SHOULD be used. lock-owner and open file SHOULD be used.
o If there is no byte-range lock stateid, then the OPEN stateid for o If there is no byte-range lock stateid, then the OPEN stateid for
the open file in question SHOULD be used. the current open-owner, and that OPEN stateid for the open file in
question SHOULD be used.
o Finally, if none of the above apply, then a special stateid SHOULD o Finally, if none of the above apply, then a special stateid SHOULD
be used. be used.
Ignoring these rules may result in situations in which the server Ignoring these rules may result in situations in which the server
does not have information necessary to properly process the request. does not have information necessary to properly process the request.
For example, when mandatory byte-range locks are in effect, if the For example, when mandatory byte-range locks are in effect, if the
stateid does not indicate the proper lock-owner, via a lock stateid, stateid does not indicate the proper lock-owner, via a lock stateid,
a request might be avoidably rejected. a request might be avoidably rejected.
skipping to change at page 119, line 22 skipping to change at page 119, line 13
the server will be maintaining the correspondence between them. the server will be maintaining the correspondence between them.
9.1.5. Use of the Stateid and Locking 9.1.5. Use of the Stateid and Locking
All READ, WRITE and SETATTR operations contain a stateid. For the All READ, WRITE and SETATTR operations contain a stateid. For the
purposes of this section, SETATTR operations which change the size purposes of this section, SETATTR operations which change the size
attribute of a file are treated as if they are writing the area attribute of a file are treated as if they are writing the area
between the old and new size (i.e., the range truncated or added to between the old and new size (i.e., the range truncated or added to
the file by means of the SETATTR), even where SETATTR is not the file by means of the SETATTR), even where SETATTR is not
explicitly mentioned in the text. The stateid passed to one of these explicitly mentioned in the text. The stateid passed to one of these
operations must be one that represents an OPEN, a set of byte-range operations must be one that represents an OPEN (e.g., via the open-
locks, or a delegation, or it may be a special stateid representing owner), a set of byte-range locks, or a delegation, or it may be a
anonymous access or the special bypass stateid. special stateid representing anonymous access or the special bypass
stateid.
If the lock-owner performs a READ or WRITE in a situation in which it If the state-owner performs a READ or WRITE in a situation in which
has established a lock or share reservation on the server (any OPEN it has established a lock or share reservation on the server (any
constitutes a share reservation) the stateid (previously returned by OPEN constitutes a share reservation) the stateid (previously
the server) must be used to indicate what locks, including both byte- returned by the server) must be used to indicate what locks,
range locks and share reservations, are held by the lockowner. If no including both byte-range locks and share reservations, are held by
state is established by the client, either byte-range lock or share the state-owner. If no state is established by the client, either
reservation, a stateid of all bits 0 is used. Regardless whether a byte-range lock or share reservation, a stateid of all bits 0 is
stateid of all bits 0, or a stateid returned by the server is used, used. Regardless whether a stateid of all bits 0, or a stateid
if there is a conflicting share reservation or mandatory byte-range returned by the server is used, if there is a conflicting share
lock held on the file, the server MUST refuse to service the READ or reservation or mandatory byte-range lock held on the file, the server
WRITE operation. MUST refuse to service the READ or WRITE operation.
Share reservations are established by OPEN operations and by their Share reservations are established by OPEN operations and by their
nature are mandatory in that when the OPEN denies READ or WRITE nature are mandatory in that when the OPEN denies READ or WRITE
operations, that denial results in such operations being rejected operations, that denial results in such operations being rejected
with error NFS4ERR_LOCKED. Byte-range locks may be implemented by with error NFS4ERR_LOCKED. Byte-range locks may be implemented by
the server as either mandatory or advisory, or the choice of the server as either mandatory or advisory, or the choice of
mandatory or advisory behavior may be determined by the server on the mandatory or advisory behavior may be determined by the server on the
basis of the file being accessed (for example, some UNIX-based basis of the file being accessed (for example, some UNIX-based
servers support a "mandatory lock bit" on the mode attribute such servers support a "mandatory lock bit" on the mode attribute such
that if set, byte-range locks are required on the file before I/O is that if set, byte-range locks are required on the file before I/O is
skipping to change at page 121, line 35 skipping to change at page 121, line 28
9.1.6. Sequencing of Lock Requests 9.1.6. Sequencing of Lock Requests
Locking is different than most NFS operations as it requires "at- Locking is different than most NFS operations as it requires "at-
most-one" semantics that are not provided by ONCRPC. ONCRPC over a most-one" semantics that are not provided by ONCRPC. ONCRPC over a
reliable transport is not sufficient because a sequence of locking reliable transport is not sufficient because a sequence of locking
requests may span multiple TCP connections. In the face of requests may span multiple TCP connections. In the face of
retransmission or reordering, lock or unlock requests must have a retransmission or reordering, lock or unlock requests must have a
well defined and consistent behavior. To accomplish this, each lock well defined and consistent behavior. To accomplish this, each lock
request contains a sequence number that is a consecutively increasing request contains a sequence number that is a consecutively increasing
integer. Different lock-owners have different sequences. The server integer. Different state-owners have different sequences. The
maintains the last sequence number (L) received and the response that server maintains the last sequence number (L) received and the
was returned. The server is free to assign any value for the first response that was returned. The server is free to assign any value
request issued for any given lock-owner. for the first request issued for any given state-owner.
Note that for requests that contain a sequence number, for each lock- Note that for requests that contain a sequence number, for each
owner, there should be no more than one outstanding request. state-owner, there should be no more than one outstanding request.
If a request (r) with a previous sequence number (r < L) is received, If a request (r) with a previous sequence number (r < L) is received,
it is rejected with the return of error NFS4ERR_BAD_SEQID. Given a it is rejected with the return of error NFS4ERR_BAD_SEQID. Given a
properly-functioning client, the response to (r) must have been properly-functioning client, the response to (r) must have been
received before the last request (L) was sent. If a duplicate of received before the last request (L) was sent. If a duplicate of
last request (r == L) is received, the stored response is returned. last request (r == L) is received, the stored response is returned.
If a request beyond the next sequence (r == L + 2) is received, it is If a request beyond the next sequence (r == L + 2) is received, it is
rejected with the return of error NFS4ERR_BAD_SEQID. Sequence rejected with the return of error NFS4ERR_BAD_SEQID. Sequence
history is reinitialized whenever the SETCLIENTID/SETCLIENTID_CONFIRM history is reinitialized whenever the SETCLIENTID/SETCLIENTID_CONFIRM
sequence changes the client verifier. sequence changes the client verifier.
skipping to change at page 122, line 15 skipping to change at page 122, line 7
Since the sequence number is represented with an unsigned 32-bit Since the sequence number is represented with an unsigned 32-bit
integer, the arithmetic involved with the sequence number is mod integer, the arithmetic involved with the sequence number is mod
2^32. For an example of modulo arithmetic involving sequence numbers 2^32. For an example of modulo arithmetic involving sequence numbers
see [33]. see [33].
It is critical the server maintain the last response sent to the It is critical the server maintain the last response sent to the
client to provide a more reliable cache of duplicate non-idempotent client to provide a more reliable cache of duplicate non-idempotent
requests than that of the traditional cache described in [34]. The requests than that of the traditional cache described in [34]. The
traditional duplicate request cache uses a least recently used traditional duplicate request cache uses a least recently used
algorithm for removing unneeded requests. However, the last lock algorithm for removing unneeded requests. However, the last lock
request and response on a given lock-owner must be cached as long as request and response on a given state-owner must be cached as long as
the lock state exists on the server. the lock state exists on the server.
The client MUST monotonically increment the sequence number for the The client MUST monotonically increment the sequence number for the
CLOSE, LOCK, LOCKU, OPEN, OPEN_CONFIRM, and OPEN_DOWNGRADE CLOSE, LOCK, LOCKU, OPEN, OPEN_CONFIRM, and OPEN_DOWNGRADE
operations. This is true even in the event that the previous operations. This is true even in the event that the previous
operation that used the sequence number received an error. The only operation that used the sequence number received an error. The only
exception to this rule is if the previous operation received one of exception to this rule is if the previous operation received one of
the following errors: NFS4ERR_STALE_CLIENTID, NFS4ERR_STALE_STATEID, the following errors: NFS4ERR_STALE_CLIENTID, NFS4ERR_STALE_STATEID,
NFS4ERR_BAD_STATEID, NFS4ERR_BAD_SEQID, NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID, NFS4ERR_BAD_SEQID, NFS4ERR_BADXDR,
NFS4ERR_RESOURCE, NFS4ERR_NOFILEHANDLE, or NFS4ERR_MOVED. NFS4ERR_RESOURCE, NFS4ERR_NOFILEHANDLE, or NFS4ERR_MOVED.
9.1.7. Recovery from Replayed Requests 9.1.7. Recovery from Replayed Requests
As described above, the sequence number is per lock-owner. As long As described above, the sequence number is per state-owner. As long
as the server maintains the last sequence number received and follows as the server maintains the last sequence number received and follows
the methods described above, there are no risks of a Byzantine router the methods described above, there are no risks of a Byzantine router
re-sending old requests. The server need only maintain the (lock- re-sending old requests. The server need only maintain the (state-
owner, sequence number) state as long as there are open files or owner, sequence number) state as long as there are open files or
closed files with locks outstanding. closed files with locks outstanding.
LOCK, LOCKU, OPEN, OPEN_DOWNGRADE, and CLOSE each contain a sequence LOCK, LOCKU, OPEN, OPEN_DOWNGRADE, and CLOSE each contain a sequence
number and therefore the risk of the replay of these operations number and therefore the risk of the replay of these operations
resulting in undesired effects is non-existent while the server resulting in undesired effects is non-existent while the server
maintains the lock-owner state. maintains the state-owner state.
9.1.8. Releasing lock-owner State 9.1.8. Releasing state-owner State
When a particular lock-owner no longer holds open or file locking When a particular state-owner no longer holds open or file locking
state at the server, the server may choose to release the sequence state at the server, the server may choose to release the sequence
number state associated with the lock-owner. The server may make number state associated with the state-owner. The server may make
this choice based on lease expiration, for the reclamation of server this choice based on lease expiration, for the reclamation of server
memory, or other implementation specific details. In any event, the memory, or other implementation specific details. In any event, the
server is able to do this safely only when the lock-owner no longer server is able to do this safely only when the state-owner no longer
is being utilized by the client. The server may choose to hold the is being utilized by the client. The server may choose to hold the
lock-owner state in the event that retransmitted requests are state-owner state in the event that retransmitted requests are
received. However, the period to hold this state is implementation received. However, the period to hold this state is implementation
specific. specific.
In the case that a LOCK, LOCKU, OPEN_DOWNGRADE, or CLOSE is In the case that a LOCK, LOCKU, OPEN_DOWNGRADE, or CLOSE is
retransmitted after the server has previously released the lock-owner retransmitted after the server has previously released the state-
state, the server will find that the lock-owner has no files open and owner state, the server will find that the state-owner has no files
an error will be returned to the client. If the lock-owner does have open and an error will be returned to the client. If the state-owner
a file open, the stateid will not match and again an error is does have a file open, the stateid will not match and again an error
returned to the client. is returned to the client.
9.1.9. Use of Open Confirmation 9.1.9. Use of Open Confirmation
In the case that an OPEN is retransmitted and the lock-owner is being In the case that an OPEN is retransmitted and the open-owner is being
used for the first time or the lock-owner state has been previously used for the first time or the open-owner state has been previously
released by the server, the use of the OPEN_CONFIRM operation will released by the server, the use of the OPEN_CONFIRM operation will
prevent incorrect behavior. When the server observes the use of the prevent incorrect behavior. When the server observes the use of the
lock-owner for the first time, it will direct the client to perform open-owner for the first time, it will direct the client to perform
the OPEN_CONFIRM for the corresponding OPEN. This sequence the OPEN_CONFIRM for the corresponding OPEN. This sequence
establishes the use of a lock-owner and associated sequence number. establishes the use of a open-owner and associated sequence number.
Since the OPEN_CONFIRM sequence connects a new open-owner on the Since the OPEN_CONFIRM sequence connects a new open-owner on the
server with an existing open-owner on a client, the sequence number server with an existing open-owner on a client, the sequence number
may have any value. The OPEN_CONFIRM step assures the server that may have any value. The OPEN_CONFIRM step assures the server that
the value received is the correct one. (see Section 15.20 for further the value received is the correct one. (see Section 15.20 for further
details.) details.)
There are a number of situations in which the requirement to confirm There are a number of situations in which the requirement to confirm
an OPEN would pose difficulties for the client and server, in that an OPEN would pose difficulties for the client and server, in that
they would be prevented from acting in a timely fashion on they would be prevented from acting in a timely fashion on
information received, because that information would be provisional, information received, because that information would be provisional,
skipping to change at page 136, line 14 skipping to change at page 135, line 52
9.7. Recovery from a Lock Request Timeout or Abort 9.7. Recovery from a Lock Request Timeout or Abort
In the event a lock request times out, a client may decide to not In the event a lock request times out, a client may decide to not
retry the request. The client may also abort the request when the retry the request. The client may also abort the request when the
process for which it was issued is terminated (e.g., in UNIX due to a process for which it was issued is terminated (e.g., in UNIX due to a
signal). It is possible though that the server received the request signal). It is possible though that the server received the request
and acted upon it. This would change the state on the server without and acted upon it. This would change the state on the server without
the client being aware of the change. It is paramount that the the client being aware of the change. It is paramount that the
client re-synchronize state with server before it attempts any other client re-synchronize state with server before it attempts any other
operation that takes a seqid and/or a stateid with the same lock- operation that takes a seqid and/or a stateid with the same state-
owner. This is straightforward to do without a special re- owner. This is straightforward to do without a special re-
synchronize operation. synchronize operation.
Since the server maintains the last lock request and response Since the server maintains the last lock request and response
received on the lock-owner, for each lock-owner, the client should received on the state-owner, for each state-owner, the client should
cache the last lock request it sent such that the lock request did cache the last lock request it sent such that the lock request did
not receive a response. From this, the next time the client does a not receive a response. From this, the next time the client does a
lock operation for the lock-owner, it can send the cached request, if lock operation for the state-owner, it can send the cached request,
there is one, and if the request was one that established state if there is one, and if the request was one that established state
(e.g., a LOCK or OPEN operation), the server will return the cached (e.g., a LOCK or OPEN operation), the server will return the cached
result or if never saw the request, perform it. The client can result or if never saw the request, perform it. The client can
follow up with a request to remove the state (e.g., a LOCKU or CLOSE follow up with a request to remove the state (e.g., a LOCKU or CLOSE
operation). With this approach, the sequencing and stateid operation). With this approach, the sequencing and stateid
information on the client and server for the given lock-owner will information on the client and server for the given state-owner will
re-synchronize and in turn the lock state will re-synchronize. re-synchronize and in turn the lock state will re-synchronize.
9.8. Server Revocation of Locks 9.8. Server Revocation of Locks
At any point, the server can revoke locks held by a client and the At any point, the server can revoke locks held by a client and the
client must be prepared for this event. When the client detects that client must be prepared for this event. When the client detects that
its locks have been or may have been revoked, the client is its locks have been or may have been revoked, the client is
responsible for validating the state information between itself and responsible for validating the state information between itself and
the server. Validating locking state for the client means that it the server. Validating locking state for the client means that it
must verify or reclaim state for each lock currently held. must verify or reclaim state for each lock currently held.
skipping to change at page 137, line 16 skipping to change at page 137, line 6
client should bound the time that the corresponding renewal could client should bound the time that the corresponding renewal could
have occurred on the server and thus determine if it is possible that have occurred on the server and thus determine if it is possible that
a lease period expiration could have occurred. a lease period expiration could have occurred.
The third lock revocation event can occur as a result of The third lock revocation event can occur as a result of
administrative intervention within the lease period. While this is administrative intervention within the lease period. While this is
considered a rare event, it is possible that the server's considered a rare event, it is possible that the server's
administrator has decided to release or revoke a particular lock held administrator has decided to release or revoke a particular lock held
by the client. As a result of revocation, the client will receive an by the client. As a result of revocation, the client will receive an
error of NFS4ERR_ADMIN_REVOKED. In this instance the client may error of NFS4ERR_ADMIN_REVOKED. In this instance the client may
assume that only the lock-owner's locks have been lost. The client assume that only the state-owner's locks have been lost. The client
notifies the lock holder appropriately. The client may not assume notifies the lock holder appropriately. The client may not assume
the lease period has been renewed as a result of a failed operation. the lease period has been renewed as a result of a failed operation.
When the client determines the lease period may have expired, the When the client determines the lease period may have expired, the
client must mark all locks held for the associated lease as client must mark all locks held for the associated lease as
"unvalidated". This means the client has been unable to re-establish "unvalidated". This means the client has been unable to re-establish
or confirm the appropriate lock state with the server. As described or confirm the appropriate lock state with the server. As described
in Section 9.6, there are scenarios in which the server may grant in Section 9.6, there are scenarios in which the server may grant
conflicting locks after the lease period has expired for a client. conflicting locks after the lease period has expired for a client.
When it is possible that the lease period has expired, the client When it is possible that the lease period has expired, the client
skipping to change at page 138, line 41 skipping to change at page 138, line 30
to use a stateid of all 0's or all 1's, it must still obtain the to use a stateid of all 0's or all 1's, it must still obtain the
filehandle for the regular file with the OPEN operation so the filehandle for the regular file with the OPEN operation so the
appropriate share semantics can be applied. Clients that do not have appropriate share semantics can be applied. Clients that do not have
a deny mode built into their programming interfaces for opening a a deny mode built into their programming interfaces for opening a
file should request a deny mode of OPEN4_SHARE_DENY_NONE. file should request a deny mode of OPEN4_SHARE_DENY_NONE.
The OPEN operation with the CREATE flag, also subsumes the CREATE The OPEN operation with the CREATE flag, also subsumes the CREATE
operation for regular files as used in previous versions of the NFS operation for regular files as used in previous versions of the NFS
protocol. This allows a create with a share to be done atomically. protocol. This allows a create with a share to be done atomically.
The CLOSE operation removes all share reservations held by the lock- The CLOSE operation removes all share reservations held by the open-
owner on that file. If byte-range locks are held, the client SHOULD owner on that file. If byte-range locks are held, the client SHOULD
release all locks before issuing a CLOSE. The server MAY free all release all locks before issuing a CLOSE. The server MAY free all
outstanding locks on CLOSE but some servers may not support the CLOSE outstanding locks on CLOSE but some servers may not support the CLOSE
of a file that still has byte-range locks held. The server MUST of a file that still has byte-range locks held. The server MUST
return failure, NFS4ERR_LOCKS_HELD, if any locks would exist after return failure, NFS4ERR_LOCKS_HELD, if any locks would exist after
the CLOSE. the CLOSE.
The LOOKUP operation will return a filehandle without establishing The LOOKUP operation will return a filehandle without establishing
any lock state on the server. Without a valid stateid, the server any lock state on the server. Without a valid stateid, the server
will assume the client has the least access. For example, if one will assume the client has the least access. For example, if one
skipping to change at page 247, line 24 skipping to change at page 247, line 24
LOCK operations are subject to permission checks and to checks LOCK operations are subject to permission checks and to checks
against the access type of the associated file. However, the against the access type of the associated file. However, the
specific right and modes required for various type of locks, reflect specific right and modes required for various type of locks, reflect
the semantics of the server-exported filesystem, and are not the semantics of the server-exported filesystem, and are not
specified by the protocol. For example, Windows 2000 allows a write specified by the protocol. For example, Windows 2000 allows a write
lock of a file open for READ, while a POSIX-compliant system does lock of a file open for READ, while a POSIX-compliant system does
not. not.
When the client makes a lock request that corresponds to a range that When the client makes a lock request that corresponds to a range that
the lockowner has locked already (with the same or different lock the lock-owner has locked already (with the same or different lock
type), or to a sub-region of such a range, or to a region which type), or to a sub-region of such a range, or to a region which
includes multiple locks already granted to that lockowner, in whole includes multiple locks already granted to that lock-owner, in whole
or in part, and the server does not support such locking operations or in part, and the server does not support such locking operations
(i.e., does not support POSIX locking semantics), the server will (i.e., does not support POSIX locking semantics), the server will
return the error NFS4ERR_LOCK_RANGE. In that case, the client may return the error NFS4ERR_LOCK_RANGE. In that case, the client may
return an error, or it may emulate the required operations, using return an error, or it may emulate the required operations, using
only LOCK for ranges that do not include any bytes already locked by only LOCK for ranges that do not include any bytes already locked by
that lock-owner and LOCKU of locks held by that lock-owner that lock-owner and LOCKU of locks held by that lock-owner
(specifying an exactly-matching range and type). Similarly, when the (specifying an exactly-matching range and type). Similarly, when the
client makes a lock request that amounts to upgrading (changing from client makes a lock request that amounts to upgrading (changing from
a read lock to a write lock) or downgrading (changing from write lock a read lock to a write lock) or downgrading (changing from write lock
to a read lock) an existing record lock, and the server does not to a read lock) an existing record lock, and the server does not
skipping to change at page 249, line 45 skipping to change at page 249, line 45
the conflicting lock, the same offset and length that were provided the conflicting lock, the same offset and length that were provided
in the arguments should be returned in the denied results. Section 9 in the arguments should be returned in the denied results. Section 9
contains further discussion of the file locking mechanisms. contains further discussion of the file locking mechanisms.
LOCKT uses a lock_owner4 rather a stateid4, as is used in LOCK to LOCKT uses a lock_owner4 rather a stateid4, as is used in LOCK to
identify the owner. This is because the client does not have to open identify the owner. This is because the client does not have to open
the file to test for the existence of a lock, so a stateid may not be the file to test for the existence of a lock, so a stateid may not be
available. available.
The test for conflicting locks SHOULD exclude locks for the current The test for conflicting locks SHOULD exclude locks for the current
lockowner. Note that since such locks are not examined the possible lock-owner. Note that since such locks are not examined the possible
existence of overlapping ranges may not affect the results of LOCKT. existence of overlapping ranges may not affect the results of LOCKT.
If the server does examine locks that match the lockowner for the If the server does examine locks that match the lock-owner for the
purpose of range checking, NFS4ERR_LOCK_RANGE may be returned.. In purpose of range checking, NFS4ERR_LOCK_RANGE may be returned. In
the event that it returns NFS4_OK, clients may do a LOCK and receive the event that it returns NFS4_OK, clients may do a LOCK and receive
NFS4ERR_LOCK_RANGE on the LOCK request because of the flexibility NFS4ERR_LOCK_RANGE on the LOCK request because of the flexibility
provided to the server. provided to the server.
When a client holds an OPEN_DELEGATE_WRITE delegation, it may choose When a client holds an OPEN_DELEGATE_WRITE delegation, it may choose
(see Section 15.12.5)) to handle LOCK requests locally. In such a (see Section 15.12.5)) to handle LOCK requests locally. In such a
case, LOCKT requests will similarly be handled locally. case, LOCKT requests will similarly be handled locally.
15.14. Operation 14: LOCKU - Unlock File 15.14. Operation 14: LOCKU - Unlock File
skipping to change at page 251, line 8 skipping to change at page 251, line 8
The ranges are specified as for LOCK. The NFS4ERR_INVAL and The ranges are specified as for LOCK. The NFS4ERR_INVAL and
NFS4ERR_BAD_RANGE errors are returned under the same circumstances as NFS4ERR_BAD_RANGE errors are returned under the same circumstances as
for LOCK. for LOCK.
On success, the current filehandle retains its value. On success, the current filehandle retains its value.
15.14.5. IMPLEMENTATION 15.14.5. IMPLEMENTATION
If the area to be unlocked does not correspond exactly to a lock If the area to be unlocked does not correspond exactly to a lock
actually held by the lockowner the server may return the error actually held by the lock-owner the server may return the error
NFS4ERR_LOCK_RANGE. This includes the case in which the area is not NFS4ERR_LOCK_RANGE. This includes the case in which the area is not
locked, where the area is a sub-range of the area locked, where it locked, where the area is a sub-range of the area locked, where it
overlaps the area locked without matching exactly or the area overlaps the area locked without matching exactly or the area
specified includes multiple locks held by the lockowner. In all of specified includes multiple locks held by the lock-owner. In all of
these cases, allowed by POSIX locking [35] semantics, a client these cases, allowed by POSIX locking [35] semantics, a client
receiving this error, should if it desires support for such receiving this error, should if it desires support for such
operations, simulate the operation using LOCKU on ranges operations, simulate the operation using LOCKU on ranges
corresponding to locks it actually holds, possibly followed by LOCK corresponding to locks it actually holds, possibly followed by LOCK
requests for the sub-ranges not being unlocked. requests for the sub-ranges not being unlocked.
When a client holds an OPEN_DELEGATE_WRITE delegation, it may choose When a client holds an OPEN_DELEGATE_WRITE delegation, it may choose
(see Section 15.12.5)) to handle LOCK requests locally. In such a (see Section 15.12.5)) to handle LOCK requests locally. In such a
case, LOCKU requests will similarly be handled locally. case, LOCKU requests will similarly be handled locally.
skipping to change at page 266, line 9 skipping to change at page 266, line 9
15.19.5. IMPLEMENTATION 15.19.5. IMPLEMENTATION
If the server does not support named attributes for the current If the server does not support named attributes for the current
filehandle, an error of NFS4ERR_NOTSUPP will be returned to the filehandle, an error of NFS4ERR_NOTSUPP will be returned to the
client. client.
15.20. Operation 20: OPEN_CONFIRM - Confirm Open 15.20. Operation 20: OPEN_CONFIRM - Confirm Open
15.20.1. SYNOPSIS 15.20.1. SYNOPSIS
(cfh), seqid, stateid-> stateid (cfh), seqid, stateid -> stateid
15.20.2. ARGUMENT 15.20.2. ARGUMENT
struct OPEN_CONFIRM4args { struct OPEN_CONFIRM4args {
/* CURRENT_FH: opened file */ /* CURRENT_FH: opened file */
stateid4 open_stateid; stateid4 open_stateid;
seqid4 seqid; seqid4 seqid;
}; };
15.20.3. RESULT 15.20.3. RESULT
skipping to change at page 304, line 21 skipping to change at page 304, line 21
lock and failed, it is pointless for the client to re-attempt the lock and failed, it is pointless for the client to re-attempt the
upgrade via the LOCK operation, because there might be another client upgrade via the LOCK operation, because there might be another client
also trying to upgrade. If two clients are blocked trying upgrade also trying to upgrade. If two clients are blocked trying upgrade
the same lock, the clients deadlock. If the server has no upgrade the same lock, the clients deadlock. If the server has no upgrade
capability, then it is pointless to try a LOCK operation to upgrade. capability, then it is pointless to try a LOCK operation to upgrade.
15.39. Operation 39: RELEASE_LOCKOWNER - Release Lockowner State 15.39. Operation 39: RELEASE_LOCKOWNER - Release Lockowner State
15.39.1. SYNOPSIS 15.39.1. SYNOPSIS
lockowner -> () lock-owner -> ()
15.39.2. ARGUMENT 15.39.2. ARGUMENT
struct RELEASE_LOCKOWNER4args { struct RELEASE_LOCKOWNER4args {
lock_owner4 lock_owner; lock_owner4 lock_owner;
}; };
15.39.3. RESULT 15.39.3. RESULT
struct RELEASE_LOCKOWNER4res { struct RELEASE_LOCKOWNER4res {
nfsstat4 status; nfsstat4 status;
}; };
15.39.4. DESCRIPTION 15.39.4. DESCRIPTION
This operation is used to notify the server that the lock-owner is no This operation is used to notify the server that the lock_owner is no
longer in use by the client. This allows the server to release longer in use by the client. This allows the server to release
cached state related to the specified lock-owner. If file locks, cached state related to the specified lock_owner. If file locks,
associated with the lock-owner, are held at the server, the error associated with the lock_owner, are held at the server, the error
NFS4ERR_LOCKS_HELD will be returned and no further action will be NFS4ERR_LOCKS_HELD will be returned and no further action will be
taken. taken.
15.39.5. IMPLEMENTATION 15.39.5. IMPLEMENTATION
The client may choose to use this operation to ease the amount of The client may choose to use this operation to ease the amount of
server state that is held. Depending on behavior of applications at server state that is held. Depending on behavior of applications at
the client, it may be important for the client to use this operation the client, it may be important for the client to use this operation
since the server has certain obligations with respect to holding a since the server has certain obligations with respect to holding a
reference to a lock-owner as long as the associated file is open. reference to a lock_owner as long as the associated file is open.
Therefore, if the client knows for certain that the lock-owner will Therefore, if the client knows for certain that the lock_owner will
no longer be used under the context of the associated open_owner4, it no longer be used under the context of the associated open_owner4, it
should use RELEASE_LOCKOWNER. should use RELEASE_LOCKOWNER.
15.40. Operation 10044: ILLEGAL - Illegal operation 15.40. Operation 10044: ILLEGAL - Illegal operation
15.40.1. SYNOPSIS 15.40.1. SYNOPSIS
<null> -> () <null> -> ()
15.40.2. ARGUMENT 15.40.2. ARGUMENT
 End of changes. 56 change blocks. 
85 lines changed or deleted 83 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/