NFSv4                                                         S. Shepler
Internet-Draft                                                 M. Eisler
Intended status: Standards Track                               D. Noveck
Expires: January 22, February 16, 2007                                       Editors
                                                           July 21,
                                                         August 15, 2006

                         NFSv4 Minor Version 1
                 draft-ietf-nfsv4-minorversion1-04.txt
                 draft-ietf-nfsv4-minorversion1-05.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 22, February 16, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This Internet-Draft describes NFSv4 minor version one, including
   features retained from the base protocol and protocol extensions made
   subsequently.  The current draft includes desciption of the major
   extensions, Sessions, Directory Delegations, and parallel NFS (pNFS).
   This Internet-Draft is an active work item of the NFSv4 working
   group.  Active and resolved issues may be found in the issue tracker
   at: http://www.nfsv4-editor.org/cgi-bin/roundup/nfsv4.  New issues
   related to this document should be raised with the NFSv4 Working
   Group nfsv4@ietf.org and logged in the issue tracker.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [1].

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .  10
     1.1.   The NFSv4.1 Protocol . . . . . . . . . . . . . . . . . .  10
     1.2.   NFS Version 4 Goals  . . . . . . . . . . . . . . . . . .  10
     1.3.   Minor Version 1 Goals  . . . . . . . . . . . . . . . . .  11
     1.4.   Inconsistencies of this Document with Section XX . . . .  11
     1.5.   Overview of NFS version 4.1 Features . . . . . . . . . .  11
       1.5.1.   RPC and Security . . . . . . . . . . . . . . . . . .  12
       1.5.2.   Protocol Structure . . . . . . . . . . . . . . . . .  12
       1.5.3.   File System Model  . . . . . . . . . . . . . . . . .  14
       1.5.4.   Locking Facilities . . . . . . . . . . . . . . . . .  15
     1.6.   General Definitions  . . . . . . . . . . . . . . . . . .  16
     1.7.   Differences from NFSv4.0 . . . . . . . . . . . . . . . .  18
   2.  Protocol Data Types . . . . . . . . . . . . . . . . . . . . .  10
     1.1.  18
     2.1.   Basic Data Types . . . . . . . . . . . . . . . . . . . .  10
     1.2.  18
     2.2.   Structured Data Types  . . . . . . . . . . . . . . . . .  11
   2.  20
   3.  RPC and Security Flavor . . . . . . . . . . . . . . . . . . .  20
     2.1.  29
     3.1.   Ports and Transports . . . . . . . . . . . . . . . . . .  20
       2.1.1.  29
       3.1.1.   Client Retransmission Behavior . . . . . . . . . . .  21
     2.2.  31
     3.2.   Security Flavors . . . . . . . . . . . . . . . . . . . .  22
       2.2.1.  31
       3.2.1.   Security mechanisms for NFS version 4  . . . . . . .  22
     2.3.  31
     3.3.   Security Negotiation . . . . . . . . . . . . . . . . . .  24
       2.3.1.  33
       3.3.1.   SECINFO and SECINFO_NO_NAME  . . . . . . . . . . . .  24
       2.3.2.  33
       3.3.2.   Security Error . . . . . . . . . . . . . . . . . . .  24
       2.3.3.  33
       3.3.3.   Callback RPC Authentication  . . . . . . . . . . . .  25
       2.3.4.  34
       3.3.4.   GSS Server Principal . . . . . . . . . . . . . . . .  25
   3.  34
   4.  Filehandles . . . . . . . . . . . . . . . . . . . . . . . . .  25
     3.1.  35
     4.1.   Obtaining the First Filehandle . . . . . . . . . . . . .  26
       3.1.1.  35
       4.1.1.   Root Filehandle  . . . . . . . . . . . . . . . . . .  26
       3.1.2.  35
       4.1.2.   Public Filehandle  . . . . . . . . . . . . . . . . .  26
     3.2.  35
     4.2.   Filehandle Types . . . . . . . . . . . . . . . . . . . .  27
       3.2.1.  36
       4.2.1.   General Properties of a Filehandle . . . . . . . . .  27
       3.2.2.  36
       4.2.2.   Persistent Filehandle  . . . . . . . . . . . . . . .  28
       3.2.3.  37
       4.2.3.   Volatile Filehandle  . . . . . . . . . . . . . . . .  28
     3.3.  37
     4.3.   One Method of Constructing a Volatile Filehandle . . . .  29
     3.4.  39
     4.4.   Client Recovery from Filehandle Expiration . . . . . . .  30
   4.  39
   5.  File Attributes . . . . . . . . . . . . . . . . . . . . . . .  31
     4.1.  40
     5.1.   Mandatory Attributes . . . . . . . . . . . . . . . . . .  32
     4.2.  41
     5.2.   Recommended Attributes . . . . . . . . . . . . . . . . .  32
     4.3.  41
     5.3.   Named Attributes . . . . . . . . . . . . . . . . . . . .  33
     4.4.  42
     5.4.   Classification of Attributes . . . . . . . . . . . . . .  33
     4.5.  42
     5.5.   Mandatory Attributes - Definitions . . . . . . . . . . .  34
     4.6.  44
     5.6.   Recommended Attributes - Definitions . . . . . . . . . .  36
     4.7.  45
     5.7.   Time Access  . . . . . . . . . . . . . . . . . . . . . .  43
     4.8.  54
     5.8.   Interpreting owner and owner_group . . . . . . . . . . .  44
     4.9.  54
     5.9.   Character Case Attributes  . . . . . . . . . . . . . . .  46
     4.10.  56
     5.10.  Quota Attributes . . . . . . . . . . . . . . . . . . . .  46
     4.11.  56
     5.11.  mounted_on_fileid  . . . . . . . . . . . . . . . . . . .  47
     4.12.  57
     5.12.  send_impl_id and recv_impl_id  . . . . . . . . . . . . .  48
     4.13.  58
     5.13.  fs_layout_type . . . . . . . . . . . . . . . . . . . . .  48
     4.14.  59
     5.14.  layout_type  . . . . . . . . . . . . . . . . . . . . . .  48
     4.15.  59
     5.15.  layout_hint  . . . . . . . . . . . . . . . . . . . . . .  49
   5.  59
     5.16.  mdsthreshold . . . . . . . . . . . . . . . . . . . . . .  59
   6.  Access Control Lists  . . . . . . . . . . . . . . . . . . . .  49
     5.1.  60
     6.1.   ACE type . . . . . . . . . . . . . . . . . . . . . . . .  51
     5.2.  62
     6.2.   ACE Access Mask  . . . . . . . . . . . . . . . . . . . .  52
       5.2.1.  63
       6.2.1.   ACE4_DELETE vs. ACE4_DELETE_CHILD  . . . . . . . . .  57
     5.3.  67
     6.3.   ACE flag . . . . . . . . . . . . . . . . . . . . . . . .  58
     5.4.  68
     6.4.   ACE who  . . . . . . . . . . . . . . . . . . . . . . . .  59
       5.4.1.  70
       6.4.1.   Discussion of EVERYONE@  . . . . . . . . . . . . . .  60
       5.4.2.  71
       6.4.2.   Discussion of OWNER@ and GROUP@  . . . . . . . . . .  60
     5.5.  71
     6.5.   Mode Attribute . . . . . . . . . . . . . . . . . . . . .  60
     5.6.  71
     6.6.   Interaction Between Mode and ACL Attributes  . . . . . .  61
       5.6.1.  72
       6.6.1.   Recomputing mode upon SETATTR of ACL . . . . . . . .  62
       5.6.2.  73
       6.6.2.   Applying the mode given to CREATE or OPEN to an
                inherited ACL  . . . . . . . . . . . . . . . . . . .  65
       5.6.3.  76
       6.6.3.   Applying a Mode to an Existing ACL . . . . . . . . .  67
       5.6.4.  77
       6.6.4.   ACL and mode in the same SETATTR . . . . . . . . . .  71
       5.6.5.  82
       6.6.5.   Inheritance and turning it off . . . . . . . . . . .  72
       5.6.6.  83
       6.6.6.   Deficiencies in a Mode Representation of an ACL  . .  73
   6.  84
   7.  Single-server Name Space  . . . . . . . . . . . . . . . . . .  74
     6.1.  85
     7.1.   Server Exports . . . . . . . . . . . . . . . . . . . . .  74
     6.2.  85
     7.2.   Browsing Exports . . . . . . . . . . . . . . . . . . . .  74
     6.3.  85
     7.3.   Server Pseudo Filesystem . File System  . . . . . . . . . . . . . . .  75
     6.4.  86
     7.4.   Multiple Roots . . . . . . . . . . . . . . . . . . . . .  76
     6.5.  86
     7.5.   Filehandle Volatility  . . . . . . . . . . . . . . . . .  76
     6.6.  87
     7.6.   Exported Root  . . . . . . . . . . . . . . . . . . . . .  76
     6.7.  87
     7.7.   Mount Point Crossing . . . . . . . . . . . . . . . . . .  76
     6.8.  87
     7.8.   Security Policy and Name Space Presentation  . . . . . .  77
   7.  88
   8.  File Locking and Share Reservations . . . . . . . . . . . . .  78
     7.1.  89
     8.1.   Locking  . . . . . . . . . . . . . . . . . . . . . . . .  78
       7.1.1.  89
       8.1.1.   Client ID  . . . . . . . . . . . . . . . . . . . . .  79
       7.1.2.  90
       8.1.2.   Server Release of Clientid . . . . . . . . . . . . .  81
       7.1.3.   lock_owner  93
       8.1.3.   State-owner and stateid Stateid Definition . . . . . . . . .  82
       7.1.4.  94
       8.1.4.   Use of the stateid Stateid and Locking . . . . . . . . . . .  84
       7.1.5.   Sequencing of Lock Requests  . . . . . . . . . . . .  86
       7.1.6.   Recovery from Replayed Requests  . . . . . . . . . .  87
       7.1.7.   Releasing lock_owner State . . . . . . . . . . . . .  87
       7.1.8.   Use of Open Confirmation . . . . . . . . . . . . . .  87
     7.2.  97
     8.2.   Lock Ranges  . . . . . . . . . . . . . . . . . . . . . .  89
     7.3.  99
     8.3.   Upgrading and Downgrading Locks  . . . . . . . . . . . .  89
     7.4.  99
     8.4.   Blocking Locks . . . . . . . . . . . . . . . . . . . . .  89
     7.5. 100
     8.5.   Lease Renewal  . . . . . . . . . . . . . . . . . . . . .  90
     7.6. 100
     8.6.   Crash Recovery . . . . . . . . . . . . . . . . . . . . .  91
       7.6.1. 101
       8.6.1.   Client Failure and Recovery  . . . . . . . . . . . .  91
       7.6.2. 101
       8.6.2.   Server Failure and Recovery  . . . . . . . . . . . .  92
       7.6.3. 102
       8.6.3.   Network Partitions and Recovery  . . . . . . . . . .  94
     7.7.   Recovery from a Lock Request Timeout or Abort  . . . . .  98
     7.8. 104
     8.7.   Server Revocation of Locks . . . . . . . . . . . . . . .  98
     7.9. 108
     8.8.   Share Reservations . . . . . . . . . . . . . . . . . . .  99
     7.10. 109
     8.9.   OPEN/CLOSE Operations  . . . . . . . . . . . . . . . . . 100
       7.10.1.  Close and Retention of State Information . . . . . . 101
     7.11. 110
     8.10.  Open Upgrade and Downgrade . . . . . . . . . . . . . . . 101
     7.12. 110
     8.11.  Short and Long Leases  . . . . . . . . . . . . . . . . . 102
     7.13. 111
     8.12.  Clocks, Propagation Delay, and Calculating Lease
            Expiration . . . . . . . . . . . . . . . . . . . . . . . 102
   8. 111
     8.13.  Vestigial Locking Infrastructure From V4.0 . . . . . . . 112
   9.  Client-Side Caching . . . . . . . . . . . . . . . . . . . . . 103
     8.1. 113
     9.1.   Performance Challenges for Client-Side Caching . . . . . 104
     8.2. 114
     9.2.   Delegation and Callbacks . . . . . . . . . . . . . . . . 104
       8.2.1. 114
       9.2.1.   Delegation Recovery  . . . . . . . . . . . . . . . . 106
     8.3. 116
     9.3.   Data Caching . . . . . . . . . . . . . . . . . . . . . . 108
       8.3.1. 118
       9.3.1.   Data Caching and OPENs . . . . . . . . . . . . . . . 108
       8.3.2. 118
       9.3.2.   Data Caching and File Locking  . . . . . . . . . . . 109
       8.3.3. 119
       9.3.3.   Data Caching and Mandatory File Locking  . . . . . . 111
       8.3.4. 121
       9.3.4.   Data Caching and File Identity . . . . . . . . . . . 111
     8.4. 121
     9.4.   Open Delegation  . . . . . . . . . . . . . . . . . . . . 112
       8.4.1. 122
       9.4.1.   Open Delegation and Data Caching . . . . . . . . . . 115
       8.4.2. 125
       9.4.2.   Open Delegation and File Locks . . . . . . . . . . . 116
       8.4.3. 126
       9.4.3.   Handling of CB_GETATTR . . . . . . . . . . . . . . . 116
       8.4.4. 126
       9.4.4.   Recall of Open Delegation  . . . . . . . . . . . . . 119
       8.4.5. 129
       9.4.5.   Clients that Fail to Honor Delegation Recalls  . . . 121
       8.4.6. 131
       9.4.6.   Delegation Revocation  . . . . . . . . . . . . . . . 122
     8.5. 132
     9.5.   Data Caching and Revocation  . . . . . . . . . . . . . . 122
       8.5.1. 132
       9.5.1.   Revocation Recovery for Write Open Delegation  . . . 123
     8.6. 133
     9.6.   Attribute Caching  . . . . . . . . . . . . . . . . . . . 124
     8.7. 134
     9.7.   Data and Metadata Caching and Memory Mapped Files  . . . 126
     8.8. 136
     9.8.   Name Caching . . . . . . . . . . . . . . . . . . . . . . 128
     8.9. 138
     9.9.   Directory Caching  . . . . . . . . . . . . . . . . . . . 129
   9. 139
   10. Security Negotiation  . . . . . . . . . . . . . . . . . . . . 130
   10. 140
   11. Clarification of Security Negotiation in NFSv4.1  . . . . . . 130
     10.1. 140
     11.1.  PUTFH + LOOKUP . . . . . . . . . . . . . . . . . . . . . 130
     10.2. 140
     11.2.  PUTFH + LOOKUPP  . . . . . . . . . . . . . . . . . . . . 131
     10.3. 141
     11.3.  PUTFH + SECINFO  . . . . . . . . . . . . . . . . . . . . 131
     10.4. 141
     11.4.  PUTFH + Anything Else  . . . . . . . . . . . . . . . . . 131
   11. 141
   12. NFSv4.1 Sessions  . . . . . . . . . . . . . . . . . . . . . . 132
     11.1. 142
     12.1.  Sessions Background  . . . . . . . . . . . . . . . . . . 132
       11.1.1. 142
       12.1.1.  Introduction to Sessions . . . . . . . . . . . . . . 132
       11.1.2.  Motivation . . . . . . . . . . . . . . . . . . . . . 133
       11.1.3.  Problem Statement  . . . . . . . . . . . . . . . . . 134
       11.1.4.  NFSv4 Session Extension Characteristics  . . . . . . 136
     11.2.  Transport Issues . . . . . . . . . . . . . . . . . . . . 136
       11.2.1. 142
       12.1.2.  Session Model  . . . . . . . . . . . . . . . . . . . 136
       11.2.2. 143
       12.1.3.  Connection State . . . . . . . . . . . . . . . . . . 137
       11.2.3. 144
       12.1.4.  NFSv4 Channels, Sessions and Connections . . . . . . 138
       11.2.4. 145
       12.1.5.  Reconnection, Trunking and Failover  . . . . . . . . 140
       11.2.5. 146
       12.1.6.  Server Duplicate Request Cache . . . . . . . . . . . 141
     11.3. 147
     12.2.  Session Initialization and Transfer Models . . . . . . . 142
       11.3.1. 148
       12.2.1.  Session Negotiation  . . . . . . . . . . . . . . . . 142
       11.3.2. 148
       12.2.2.  RDMA Requirements  . . . . . . . . . . . . . . . . . 144
       11.3.3. 150
       12.2.3.  RDMA Connection Resources  . . . . . . . . . . . . . 144
       11.3.4. 150
       12.2.4.  TCP and RDMA Inline Transfer Model . . . . . . . . . 145
       11.3.5. 151
       12.2.5.  RDMA Direct Transfer Model . . . . . . . . . . . . . 148
     11.4. 154
     12.3.  Connection Models  . . . . . . . . . . . . . . . . . . . 151
       11.4.1. 157
       12.3.1.  TCP Connection Model . . . . . . . . . . . . . . . . 152
       11.4.2. 158
       12.3.2.  Negotiated RDMA Connection Model . . . . . . . . . . 153
       11.4.3. 159
       12.3.3.  Automatic RDMA Connection Model  . . . . . . . . . . 154
     11.5. 160
     12.4.  Buffer Management, Transfer, Flow Control  . . . . . . . 154
     11.6. 160
     12.5.  Retry and Replay . . . . . . . . . . . . . . . . . . . . 157
     11.7. 163
     12.6.  The Back Channel . . . . . . . . . . . . . . . . . . . . 158
     11.8. 164
     12.7.  COMPOUND Sizing Issues . . . . . . . . . . . . . . . . . 159
     11.9. 165
     12.8.  Data Alignment . . . . . . . . . . . . . . . . . . . . . 159
     11.10. 165
     12.9.  NFSv4 Integration  . . . . . . . . . . . . . . . . . . . 161
       11.10.1. 167
       12.9.1.  Minor Versioning . . . . . . . . . . . . . . . . . . 161
       11.10.2. 167
       12.9.2.  Slot Identifiers and Server Duplicate Request
                Cache  . . . . . . . . . . . . . . . . . . . . . . . 161
       11.10.3. 167
       12.9.3.  Resolving server callback races with sessions  . . . 165
       11.10.4. 170
       12.9.4.  COMPOUND and CB_COMPOUND . . . . . . . . . . . . . . 166
       11.10.5. eXternal Data Representation Efficiency 171
     12.10. Sessions Security Considerations . . . . . . 167
       11.10.6. Effect of Sessions on Existing Operations . . . . . 167
       11.10.7. Authentication Efficiencies . 173
       12.10.1. Denial of Service via Unauthorized State Changes . . 173
     12.11. Session Mechanics - Steady State . . . . . . . . . . 168
     11.11. Sessions Security Considerations . . 177
       12.11.1. Obligations of the Server  . . . . . . . . . . . 169
       11.11.1. Denial . . 177
       12.11.2. Obligations of Service via Unauthorized State Changes the Client  . . 170
       11.11.2. Authentication . . . . . . . . . . . 177
       12.11.3. Steps the Client Takes To Establish a Session  . . . 178
     12.12. Session Mechanics - Recovery . . . . . 173
   12. . . . . . . . . . 178
       12.12.1. Events Requiring Client Action . . . . . . . . . . . 178
       12.12.2. Events Requiring Server Action . . . . . . . . . . . 180
   13. Multi-server Name Space . . . . . . . . . . . . . . . . . . . 174
     12.1. 180
     13.1.  Location attributes  . . . . . . . . . . . . . . . . . . 174
     12.2. 180
     13.2.  File System Presence or Absence  . . . . . . . . . . . . 175
     12.3. 181
     13.3.  Getting Attributes for an Absent File System . . . . . . 176
       12.3.1. 182
       13.3.1.  GETATTR Within an Absent File System . . . . . . . . 176
       12.3.2. 182
       13.3.2.  READDIR and Absent File Systems  . . . . . . . . . . 177
     12.4. 183
     13.4.  Uses of Location Information . . . . . . . . . . . . . . 178
       12.4.1. 184
       13.4.1.  File System Replication  . . . . . . . . . . . . . . 178
       12.4.2. 185
       13.4.2.  File System Migration  . . . . . . . . . . . . . . . 179
       12.4.3. 185
       13.4.3.  Referrals  . . . . . . . . . . . . . . . . . . . . . 180
     12.5. 186
     13.5.  Additional Client-side Considerations  . . . . . . . . . 180
     12.6. 187
     13.6.  Effecting File System Transitions  . . . . . . . . . . . 181
       12.6.1. 187
       13.6.1.  Transparent File System Transitions  . . . . . . . . 182
       12.6.2. 188
       13.6.2.  Filehandles and File System Transitions  . . . . . . 184
       12.6.3. 190
       13.6.3.  Fileid's and File System Transitions . . . . . . . . 184
       12.6.4. 191
       13.6.4.  Fsid's and File System Transitions . . . . . . . . . 185
       12.6.5. 191
       13.6.5.  The Change Attribute and File System Transitions . . 185
       12.6.6. 192
       13.6.6.  Lock State and File System Transitions . . . . . . . 186
       12.6.7. 192
       13.6.7.  Write Verifiers and File System Transitions  . . . . 189
     12.7. 196
     13.7.  Effecting File System Referrals  . . . . . . . . . . . . 190
       12.7.1. 196
       13.7.1.  Referral Example (LOOKUP)  . . . . . . . . . . . . . 190
       12.7.2. 196
       13.7.2.  Referral Example (READDIR) . . . . . . . . . . . . . 194
     12.8. 200
     13.8.  The Attribute fs_absent  . . . . . . . . . . . . . . . . 196
     12.9. 202
     13.9.  The Attribute fs_locations . . . . . . . . . . . . . . . 196
     12.10. 203
     13.10. The Attribute fs_locations_info  . . . . . . . . . . . . 198
     12.11. 205
     13.11. The Attribute fs_status  . . . . . . . . . . . . . . . . 207
   13. 213
   14. Directory Delegations . . . . . . . . . . . . . . . . . . . . 210
     13.1. 216
     14.1.  Introduction to Directory Delegations  . . . . . . . . . 211
     13.2. 217
     14.2.  Directory Delegation Design (in brief) . . . . . . . . . 212
     13.3. 218
     14.3.  Recommended Attributes in support of Directory
            Delegations  . . . . . . . . . . . . . . . . . . . . . . 213
     13.4. 219
     14.4.  Delegation Recall  . . . . . . . . . . . . . . . . . . . 214
     13.5. 220
     14.5.  Directory Delegation Recovery  . . . . . . . . . . . . . 220
   15. Parallel NFS (pNFS) . . . . . 214
   14. Introduction  . . . . . . . . . . . . . . . . . 220
     15.1.  Introduction . . . . . . . 214
   15. General Definitions . . . . . . . . . . . . . . . 220
     15.2.  General Definitions  . . . . . . 217
     15.1.  Metadata Server . . . . . . . . . . . . 223
       15.2.1.  Metadata Server  . . . . . . . . 217
     15.2.  Client . . . . . . . . . . 223
       15.2.2.  Client . . . . . . . . . . . . . . . 217
     15.3.  Storage Device . . . . . . . . 223
       15.2.3.  Storage Device . . . . . . . . . . . . . 217
     15.4.  Storage Protocol . . . . . . 223
       15.2.4.  Storage Protocol . . . . . . . . . . . . . . 217
     15.5.  Control Protocol . . . . 223
       15.2.5.  Control Protocol . . . . . . . . . . . . . . . . 218
     15.6.  Metadata . . 224
       15.2.6.  Metadata . . . . . . . . . . . . . . . . . . . . . . 218
     15.7. 224
       15.2.7.  Layout . . . . . . . . . . . . . . . . . . . . . . . . . 218
   16. 224
     15.3.  pNFS protocol semantics  . . . . . . . . . . . . . . . . . . . 219
     16.1. 225
       15.3.1.  Definitions  . . . . . . . . . . . . . . . . . . . . . . 219
       16.1.1.  Layout Types . . . . . . . . . . . . . . . . . . . . 219
       16.1.2.  Layout Iomode  . . . . . . . . . . . . . . . . . . . 219
       16.1.3.  Layout Segments  . . . . . . . . . . . . . . . . . . 220
       16.1.4.  Device IDs . . . . . . . . . . . . . . . . . . . . . 221
       16.1.5.  Aggregation Schemes  . . . . . . . . . . . . . . . . 221
     16.2. 225
       15.3.2.  Guarantees Provided by Layouts . . . . . . . . . . . . . 222
     16.3. 228
       15.3.3.  Getting a Layout . . . . . . . . . . . . . . . . . . . . 223
     16.4. 229
       15.3.4.  Committing a Layout  . . . . . . . . . . . . . . . . . . 224
       16.4.1.  LAYOUTCOMMIT and mtime/atime/change  . . . . . . . . 224
       16.4.2.  LAYOUTCOMMIT and size  . . . . . . . . . . . . . . . 225
       16.4.3.  LAYOUTCOMMIT and layoutupdate  . . . . . . . . . . . 226
     16.5. 230
       15.3.5.  Recalling a Layout . . . . . . . . . . . . . . . . . . . 226
       16.5.1.  Basic Operation  . . . . . . . . . . . . . . . . . . 226
       16.5.2.  Recall Callback Robustness . . . . . . . . . . . . . 228
       16.5.3.  Recall/Return Sequencing . . . . . . . . . . . . . . 229
     16.6. 232
       15.3.6.  Metadata Server Write Propagation  . . . . . . . . . . . 231
     16.7. 237
       15.3.7.  Crash Recovery . . . . . . . . . . . . . . . . . . . . . 231
       16.7.1.  Leases . . . . . . . . . . . . . . . . . . . . . . . 232
       16.7.2.  Client Recovery  . . . . . . . . . . . . . . . . . . 233
       16.7.3.  Metadata Server Recovery . . . . . . . . . . . . . . 233
       16.7.4.  Storage Device Recovery  . . . . . . . . . . . . . . 236
     16.8. 238
       15.3.8.  Security Considerations  . . . . . . . . . . . . . . . . 237
   17. 243
     15.4.  The NFSv4 File Layout Type . . . . . . . . . . . . . . . . . 238
     17.1. 244
       15.4.1.  File Striping and Data Access  . . . . . . . . . . . . . 238
       17.1.1.  Sparse and Dense Storage Device Data Layouts . . . . 240
       17.1.2.  Metadata and Storage Device Roles  . . . . . . . . . 242
       17.1.3.  Device Multipathing  . . . . . . . . . . . . . . . . 243
       17.1.4.  Operations Issued to Storage Devices . . . . . . . . 243
       17.1.5.  COMMIT through metadata server . . . . . . . . . . . 244
     17.2.
       15.4.2.  Global Stateid Requirements  . . . . . . . . . . . . . . 244
     17.3. 253
       15.4.3.  The Layout Iomode  . . . . . . . . . . . . . . . . . . . 245
     17.4. 253
       15.4.4.  Storage Device State Propagation . . . . . . . . . . . . 245
       17.4.1.  Lock State Propagation . . . . . . . . . . . . . . . 246
       17.4.2.  Open-mode Validation . . . . . . . . . . . . . . . . 246
       17.4.3.  File Attributes  . . . . . . . . . . . . . . . . . . 246
     17.5. 253
       15.4.5.  Storage Device Component File Size . . . . . . . . . . . 247
     17.6. 256
       15.4.6.  Crash Recovery Considerations  . . . . . . . . . . . . . 248
     17.7. 256
       15.4.7.  Security Considerations for the File Layout Type . . . . . . . . . . . . . . . . 249
     17.8. 257
       15.4.8.  Alternate Approaches . . . . . . . . . . . . . . . . . . 249
   18. 257
   16. Minor Versioning  . . . . . . . . . . . . . . . . . . . . . . 250
   19. 258
   17. Internationalization  . . . . . . . . . . . . . . . . . . . . 252
     19.1. 261
     17.1.  Stringprep profile for the utf8str_cs type . . . . . . . 253
     19.2. 262
     17.2.  Stringprep profile for the utf8str_cis type  . . . . . . 255
     19.3. 264
     17.3.  Stringprep profile for the utf8str_mixed type  . . . . . 256
     19.4. 265
     17.4.  UTF-8 Related Errors . . . . . . . . . . . . . . . . . . 258
   20. 266
   18. Error Values  . . . . . . . . . . . . . . . . . . . . . . . . 258
     20.1. 267
     18.1.  Error Definitions  . . . . . . . . . . . . . . . . . . . 258
     20.2. 267
     18.2.  Operations and their valid errors  . . . . . . . . . . . 270
     20.3. 279
     18.3.  Callback operations and their valid errors . . . . . . . 279
     20.4. 287
     18.4.  Errors and the operations that use them  . . . . . . . . 279
   21. 287
   19. NFS version 4.1 Procedures  . . . . . . . . . . . . . . . . . 284
     21.1. 293
     19.1.  Procedure 0: NULL - No Operation . . . . . . . . . . . . 284
     21.2. 293
     19.2.  Procedure 1: COMPOUND - Compound Operations  . . . . . . 285
   22. 294
   20. NFS version 4.1 Operations  . . . . . . . . . . . . . . . . . 287
     22.1. 298
     20.1.  Operation 3: ACCESS - Check Access Rights  . . . . . . . 288
     22.2. 299
     20.2.  Operation 4: CLOSE - Close File  . . . . . . . . . . . . 290
     22.3. 301
     20.3.  Operation 5: COMMIT - Commit Cached Data . . . . . . . . 291
     22.4. 302
     20.4.  Operation 6: CREATE - Create a Non-Regular File Object . 294
     22.5. 305
     20.5.  Operation 7: DELEGPURGE - Purge Delegations Awaiting
            Recovery . . . . . . . . . . . . . . . . . . . . . . . . 296
     22.6. 307
     20.6.  Operation 8: DELEGRETURN - Return Delegation . . . . . . 297
     22.7. 308
     20.7.  Operation 9: GETATTR - Get Attributes  . . . . . . . . . 298
     22.8. 309
     20.8.  Operation 10: GETFH - Get Current Filehandle . . . . . . 299
     22.9. 310
     20.9.  Operation 11: LINK - Create Link to a File . . . . . . . 300
     22.10. 311
     20.10. Operation 12: LOCK - Create Lock . . . . . . . . . . . . 301
     22.11. 312
     20.11. Operation 13: LOCKT - Test For Lock  . . . . . . . . . . 305
     22.12. 316
     20.12. Operation 14: LOCKU - Unlock File  . . . . . . . . . . . 306
     22.13. 317
     20.13. Operation 15: LOOKUP - Lookup Filename . . . . . . . . . 307
     22.14. 318
     20.14. Operation 16: LOOKUPP - Lookup Parent Directory  . . . . 309
     22.15. 320
     20.15. Operation 17: NVERIFY - Verify Difference in
            Attributes . . . . . . . . . . . . . . . . . . . . . . . 310
     22.16. 321
     20.16. Operation 18: OPEN - Open a Regular File . . . . . . . . 311
     22.17. 322
     20.17. Operation 19: OPENATTR - Open Named Attribute
            Directory  . . . . . . . . . . . . . . . . . . . . . . . 325
     22.18. Operation 20: OPEN_CONFIRM - Confirm Open  . . . . . . . 326
     22.19. 336
     20.18. Operation 21: OPEN_DOWNGRADE - Reduce Open File Access . 328
     22.20. 337
     20.19. Operation 22: PUTFH - Set Current Filehandle . . . . . . 329
     22.21. 338
     20.20. Operation 23: PUTPUBFH - Set Public Filehandle . . . . . 330
     22.22. 339
     20.21. Operation 24: PUTROOTFH - Set Root Filehandle  . . . . . 331
     22.23. 341
     20.22. Operation 25: READ - Read from File  . . . . . . . . . . 332
     22.24. 341
     20.23. Operation 26: READDIR - Read Directory . . . . . . . . . 334
     22.25. 343
     20.24. Operation 27: READLINK - Read Symbolic Link  . . . . . . 338
     22.26. 347
     20.25. Operation 28: REMOVE - Remove Filesystem File System Object . . . . 339
     22.27. 348
     20.26. Operation 29: RENAME - Rename Directory Entry  . . . . . 340
     22.28. Operation 30: RENEW - Renew a Lease  . . . . . . . . . . 342
     22.29. 350
     20.27. Operation 31: RESTOREFH - Restore Saved Filehandle . . . 343
     22.30. 351
     20.28. Operation 32: SAVEFH - Save Current Filehandle . . . . . 344
     22.31. 352
     20.29. Operation 33: SECINFO - Obtain Available Security  . . . 345
     22.32. 353
     20.30. Operation 34: SETATTR - Set Attributes . . . . . . . . . 348
     22.33. Operation 35: SETCLIENTID - Negotiate Clientid . . . . . 350
     22.34. Operation 36: SETCLIENTID_CONFIRM - Confirm Clientid . . 354
     22.35. 356
     20.31. Operation 37: VERIFY - Verify Same Attributes  . . . . . 357
     22.36. 358
     20.32. Operation 38: WRITE - Write to File  . . . . . . . . . . 359
     22.37. 360
     20.33. Operation 39: RELEASE_LOCKOWNER 40: BACKCHANNEL_CTL - Release Lockowner
            State  . . . . . . . . . . Backchannel control  . . 364
     20.34. Operation 41: BIND_CONN_TO_SESSION . . . . . . . . . . . 364
     20.35. Operation 42: CREATE_CLIENTID - Instantiate Clientid . . 363
     22.38. 368
     20.36. Operation 40: BIND_BACKCHANNEL 43: CREATE_SESSION - Create a callback
            channel binding New Session and
            Confirm Clientid . . . . . . . . . . . . . . . . . . . . 363
     22.39. 374
     20.37. Operation 41: BIND_CONN_TO_SESSION . . . . . . . . . 44: DESTROY_SESSION - Destroy existing
            session  . . 369
     22.40. Operation 42: CREATECLIENTID - Instantiate Clientid . . 372
     22.41. Operation 43: CREATESESSION - Create New Session and
            Confirm Clientid . . . . . . . . . . . . . . . . . . . . 377
     22.42. 382
     20.38. Operation 44: DESTROYSESSION 45: FREE_STATEID - Destroy existing
            session Free stateid with no
            locks  . . . . . . . . . . . . . . . . . . . . . . . . . 383
     22.43.
     20.39. Operation 45: 46: GET_DIR_DELEGATION - Get a directory
            delegation . . . . . . . . . . . . . . . . . . . . . . . 384
     22.44.
     20.40. Operation 46: 47: GETDEVICEINFO - Get Device Information . . 388
     22.45.
     20.41. Operation 47: 48: GETDEVICELIST  . . . . . . . . . . . . . . 389
     22.46.
     20.42. Operation 48: 49: LAYOUTCOMMIT - Commit writes made using
            a layout . . . . . . . . . . . . . . . . . . . . . . . . 390
     22.47.
     20.43. Operation 49: 50: LAYOUTGET - Get Layout Information . . . . 394
     22.48.
     20.44. Operation 50: 51: LAYOUTRETURN - Release Layout
            Information  . . . . . . . . . . . . . . . . . . . . . . 396
     22.49.
     20.45. Operation 51: 52: SECINFO_NO_NAME - Get Security on
            Unnamed Object . . . . . . . . . . . . . . . . . . . . . 398
     22.50. 399
     20.46. Operation 52: 53: SEQUENCE - Supply per-procedure
            sequencing and control . . . . . . . . . . . . . . . . . 399
     22.51. 400
     20.47. Operation 53: 54: SET_SSV  . . . . . . . . . . . . . . . . . 400
     22.52. 403
     20.48. Operation 54: 55: TEST_STATEID - Test stateids for
            validity . . . . . . . . . . . . . . . . . . . . . . . . 405
     20.49. Operation 56: WANT_DELEGATION  . . . . . . . . . . . . . 402
     22.53. 406
     20.50. Operation 10044: ILLEGAL - Illegal operation . . . . . . 405
   23. 409
   21. NFS version 4.1 Callback Procedures . . . . . . . . . . . . . 406
     23.1. 409
     21.1.  Procedure 0: CB_NULL - No Operation  . . . . . . . . . . 406
     23.2. 410
     21.2.  Procedure 1: CB_COMPOUND - Compound Operations . . . . . 406
   24. 410
   22. NFS version 4.1 Callback Operations . . . . . . . . . . . . . 408
     24.1. 412
     22.1.  Operation 3: CB_GETATTR - Get Attributes . . . . . . . . 408
     24.2. 412
     22.2.  Operation 4: CB_RECALL - Recall an Open Delegation . . . 409
     24.3. 413
     22.3.  Operation 5: CB_LAYOUTRECALL . . . . . . . . . . . . . . 410
     24.4. 414
     22.4.  Operation 6: CB_NOTIFY - Notify directory changes  . . . 412
     24.5. 417
     22.5.  Operation 7: CB_PUSH_DELEG . . . . . . . . . . . . . . . 416
     24.6. 420
     22.6.  Operation 8: CB_RECALL_ANY - Keep any N delegations  . . 417
     24.7. 421
     22.7.  Operation 9: CB_RECALLABLE_OBJ_AVAIL . . . . . . . . . . 419
     24.8. 424
     22.8.  Operation 10: CB_RECALLCREDIT CB_RECALL_CREDIT - change flow control
            limits . . . . . . . . . . . . . . . . . . . . . . . . . 420
     24.9. 425
     22.9.  Operation 11: CB_SEQUENCE - Supply callback channel
            sequencing and control . . . . . . . . . . . . . . . . . 421
     24.10. 425
     22.10. Operation 12: CB_SIZECHANGED . . CB_WANTS_CANCELLED . . . . . . . . . . . . 422
     24.11. 427
     22.11. Operation 10044: CB_ILLEGAL - Illegal Callback
            Operation  . . . . . . . . . . . . . . . . . . . . . . . 423 428
   23. Security Considerations . . . . . . . . . . . . . . . . . . . 428
   24. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 429
     24.1.  Defining new layout types  . . . . . . . . . . . . . . . 429
   25. References  . . . . . . . . . . . . . . . . . . . . . . . . . 424 429
     25.1.  Normative References . . . . . . . . . . . . . . . . . . 424 429
     25.2.  Informative References . . . . . . . . . . . . . . . . . 425 431
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . . 425 432
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . 426 432
   Intellectual Property and Copyright Statements  . . . . . . . . . 427 434

1.  Introduction

1.1.  The NFSv4.1 Protocol Data Types

   The syntax and semantics to describe the data types NFSv4.1 protocol is a minor version of the NFS
   version 4 NFSv4 protocol are defined
   described in [2].  It generally follows the XDR RFC4506 [2] guidelines for minor
   versioning model laid in Section 10 of RFC 3530.  However, it
   diverges from guidelines 11 ("a client and RPC RFC1831
   [3] documents.  The next sections build upon the XDR data types to
   define types server that supports minor
   version X must support minor versions 0 through X-1"), and structures specific 12 ("no
   features may be introduced as mandatory in a minor version").  These
   divergences are due to this protocol.

1.1.  Basic Data Types the introduction of the sessions model for
   managing non-idempotent operations and the RECLAIM_COMPLETE
   operation.  These two new features are infrastructural in nature and
   simplify implementation of existing and other new features.  Making
   them optional would add undue complexity to protocol definition and
   implementation.  NFSv4.1 accordingly updates the base NFSv4 data types.

   +---------------+---------------------------------------------------+
   | Data Type     | Definition                                        |
   +---------------+---------------------------------------------------+
   | int32_t       | typedef int int32_t;                              |
   | uint32_t      | typedef unsigned int uint32_t;                    |
   | int64_t       | typedef hyper int64_t;                            |
   | uint64_t      | typedef unsigned hyper uint64_t;                  |
   | attrlist4     | typedef opaque attrlist4<>;                       |
   |               | Used for file/directory attributes                |
   | bitmap4       | typedef uint32_t bitmap4<>;                       |
   |               | Used in attribute array encoding.                 |
   | changeid4     | typedef uint64_t changeid4;                       |
   |               | Used in definition of change_info                 |
   | clientid4     | typedef uint64_t clientid4;                       |
   |               | Shorthand reference to client identification      |
   | component4    | typedef utf8str_cs component4;                    |
   |               | Represents path name components                   |
   | count4        | typedef uint32_t count4;                          |
   |               | Various count parameters (READ, WRITE, COMMIT)    |
   | length4       | typedef uint64_t length4;                         |
   |               | Describes LOCK lengths                            |
   | linktext4     | typedef utf8str_cs linktext4;                     |
   |               | Symbolic link contents                            |
   | mode4         | typedef uint32_t mode4;                           |
   |               | Mode attribute data type                          |
   | nfs_cookie4   | typedef uint64_t nfs_cookie4;                     |
   |               | Opaque cookie value for READDIR                   |
   | nfs_fh4       | typedef opaque nfs_fh4<NFS4_FHSIZE>               |
   |               | Filehandle definition; NFS4_FHSIZE is defined Minor Versioning
   guidelines (Section 16).

   NFSv4.1, as  |
   |               | 128                                               |
   | nfs_ftype4    | enum nfs_ftype4;                                  |
   |               | Various defined file types                        |
   | nfsstat4      | enum nfsstat4;                                    |
   |               | Return value for operations                       |
   | offset4       | typedef uint64_t offset4;                         |
   |               | Various offset designations (READ, WRITE, LOCK,   |
   |               | COMMIT)                                           |
   | pathname4     | typedef component4 pathname4<>;                   |
   |               | Represents path name a minor version, is consistent with the overall goals for fs_locations             |
   | qop4          | typedef uint32_t qop4;                            |
   |               | Quality
   NFS Version 4, but extends the protocol so as to better meet those
   goals, based on experiences with NFSv4.0.  In addition, NFSv4.1 has
   adopted some additional goals, which motivate some of protection designation the major
   extensions in SECINFO      |
   | sec_oid4      | typedef opaque sec_oid4<>;                        |
   |               | Security Object Identifier minor version 1.

1.2.  NFS Version 4 Goals

   The sec_oid4 data type |
   |               | NFS version 4 protocol is not really opaque. Instead contains an ASN.1   |
   |               | OBJECT IDENTIFIER as used a further revision of the NFS protocol
   defined already by GSS-API in versions 2 [17]] and 3 [18].  It retains the       |
   |               | mech_type argument to GSS_Init_sec_context. See   |
   |               | RFC2743 [4] for details.                          |
   | seqid4        | typedef uint32_t seqid4;                          |
   |               | Sequence identifier used
   essential characteristics of previous versions: design for easy
   recovery, independent of transport protocols, operating systems and
   file locking         |
   | utf8string    | typedef opaque utf8string<>;                      |
   |               | UTF-8 encoding for strings                        |
   | utf8str_cis   | typedef opaque utf8str_cis;                       |
   |               | Case-insensitive UTF-8 string                     |
   | utf8str_cs    | typedef opaque utf8str_cs;                        |
   |               | Case-sensitive UTF-8 string                       |
   | utf8str_mixed | typedef opaque utf8str_mixed;                     |
   |               | UTF-8 strings with a case sensitive prefix systems, simplicity, and a  |
   |               | case insensitive suffix.                          |
   | verifier4     | typedef opaque verifier4[NFS4_VERIFIER_SIZE];     |
   |               | Verifier used for various operations (COMMIT,     |
   |               | CREATE, OPEN, READDIR, SETCLIENTID,               |
   |               | SETCLIENTID_CONFIRM, WRITE) NFS4_VERIFIER_SIZE good performance.  The NFS version 4
   revision has the following goals:

   o  Improved access and good performance on the Internet.

      The protocol is |
   |               | defined as 8.                                     |
   +---------------+---------------------------------------------------+

                          End designed to transit firewalls easily, perform well
      where latency is high and bandwidth is low, and scale to very
      large numbers of Base Data Types

                                  Table 1

1.2.  Structured Data Types

1.2.1.  nfstime4

   struct nfstime4 {
       int64_t seconds;
       uint32_t nseconds;
   } clients per server.

   o  Strong security with negotiation built into the protocol.

      The nfstime4 structure gives protocol builds on the number work of seconds the ONCRPC working group in
      supporting the RPCSEC_GSS protocol.  Additionally, the NFS version
      4 protocol provides a mechanism to allow clients and nanoseconds
   since midnight servers the
      ability to negotiate security and require clients and servers to
      support a minimal set of security schemes.

   o  Good cross-platform interoperability.

      The protocol features a file system model that provides a useful,
      common set of features that does not unduly favor one file system
      or 0 hour January 1, 1970 Coordinated Universal Time
   (UTC).  Values greater than zero operating system over another.

   o  Designed for protocol extensions.

      The protocol is designed to accept standard extensions within a
      framework that enable and encourages backward compatibility.

1.3.  Minor Version 1 Goals

   Minor version one has the seconds field denote dates
   after following goals, within the 0 hour January 1, 1970.  Values less than zero for framework
   established by the
   seconds field denote dates before overall version 4 goals.

   o  To correct significant structtural weaknesses and oversights
      discovered in the 0 hour January 1, 1970.  In
   both cases, base protocol.

   o  To add clarity and specificity to areas left unaddressed or not
      addressed in sufficient detail in the nseconds field is base protocol.

   o  To add specific features based on experience with the existing
      protocol and recent industry developments.

   o  To provide protocol support to be added take advantage of clustered server
      deployments including the ability to provide scalabale parallel
      access to files distributed among multiple servers.

1.4.  Inconsistencies of this Document with Section XX

   Section XX, RPC Definition File, contains the seconds field
   for definitions in XDR
   description language of the final time representation.  For example, if constructs used by the time protocol.  Prior
   to be
   represented is one-half second before 0 hour January 1, 1970, this section, several of the
   seconds field would have a value constructs are reproduced for
   purposes of negative one (-1) explanation.  Although every effort has been made to
   assure a correct and consistent description, the
   nseconds fields would have a value possibility of one-half second (500000000).
   Values greater than 999,999,999 for nseconds are considered invalid.

   This data type
   inconsistencies exists.  For any part of the document that is
   inconsistent with Section XX, Section XX is used to pass time and date information.  A server
   converts to and from its local representation be considered
   authoritative.

1.5.  Overview of time when processing
   time values, preserving as much accuracy as possible.  If NFS version 4.1 Features

   To provide a reasonable context for the
   precision reader, the major features of timestamps stored
   NFS version 4.1 protocol will be reviewed in brief.  This will be
   done to provide an appropriate context for a filesystem object both the reader who is less than
   defined, loss
   familiar with the previous versions of precision can occur.  An adjunct time maintenance the NFS protocol and the
   reader that is recommended new to reduce client and server time skew.

1.2.2.  time_how4

   enum time_how4 {
       SET_TO_SERVER_TIME4 = 0,
       SET_TO_CLIENT_TIME4 = 1
   };

1.2.3.  settime4

   union settime4 switch (time_how4 set_it) {
       case SET_TO_CLIENT_TIME4:
           nfstime4       time;
       default:
           void;
   };

   The above definitions are used as the attribute definitions NFS protocols.  For the reader new to the
   NFS protocols, there is still a set
   time values.  If set_it of fundamental knowledge that is SET_TO_SERVER_TIME4, then
   expected.  The reader should be familiar with the server uses
   its local representation XDR and RPC
   protocols as described in [3] and [4].  A basic knowledge of time for file
   systems and distributed file systems is expected as well.

   This description of version 4.1 features will not distinguish those
   added in minor version one from those present in the time value.

1.2.4.  specdata4

   struct specdata4 {
       uint32_t specdata1; /* major device number */
       uint32_t specdata2; /* base protocol
   but will treat minor device number */
   };

   This data type represents additional information version 1 as a unified whole See Section 1.7 for
   a description of the device file
   types NF4CHR differences between the two minor versions.

1.5.1.  RPC and NF4BLK.

1.2.5.  fsid4

   struct fsid4 {
       uint64_t        major;
       uint64_t        minor;
   };

1.2.6.  fs_location4

   struct fs_location4 {
       utf8str_cis    server<>;
       pathname4     rootpath;
   };

1.2.7.  fs_locations4

   struct fs_locations4 {
       pathname4     fs_root;
       fs_location4  locations<>;
   };

   The fs_location4 Security

   As with previous versions of NFS, the External Data Representation
   (XDR) and fs_locations4 data types are Remote Procedure Call (RPC) mechanisms used for the
   fs_locations recommended attribute which is used for migration NFS
   version 4.1 protocol are those defined in [3] and
   replication support.

1.2.8.  fattr4

   struct fattr4 {
       bitmap4       attrmask;
       attrlist4     attr_vals;
   };

   The fattr4 structure is [4].  To meet end-
   to-end security requirements, the RPCSEC_GSS framework [5] will be
   used to represent file and directory
   attributes.

   The bitmap is a counted array extend the basic RPC security.  With the use of 32 bit integers RPCSEC_GSS,
   various mechanisms can be provided to offer authentication,
   integrity, and privacy to the NFS version 4 protocol.  Kerberos V5
   will be used as described in [6] to contain bit
   values. provide one security framework.
   The position LIPKEY GSS-API mechanism described in [7] will be used to provide
   for the use of user password and server public key by the integer in NFS version
   4 protocol.  With the array that contains bit n
   can use of RPCSEC_GSS, other mechanisms may also be computed from the expression (n / 32)
   specified and its bit within that
   integer is (n mod 32).

   0            1
   +-----------+-----------+-----------+--
   |  count    | 31  ..  0 | 63  .. 32 |
   +-----------+-----------+-----------+--

1.2.9.  change_info4

   struct change_info4 {
       bool          atomic;
       changeid4     before;
       changeid4     after;
   };

   This structure is used with for NFS version 4.1 security.

   To enable in-band security negotiation, the CREATE, LINK, REMOVE, RENAME NFS version 4.1 protocol
   has operations to let which provide the client know the value a method of querying the change attribute
   for the directory in
   server about its policies regarding which the target filesystem object resides.

1.2.10.  clientaddr4

   struct clientaddr4 {
       /* see struct rpcb in RFC1833 */
       string r_netid<>;    /* network id */
       string r_addr<>;     /* universal address */
   };

   The clientaddr4 structure is security mechanisms must be
   used as part of the SETCLIENTID
   operation for access to either specify the address of server's file system resources.  With this,
   the client can securely match the security mechanism that is using a
   clientid or as part of meets the callback registration.  The r_netid and
   r_addr fields are
   policies specified in RFC1833 [10], but they are
   underspecified in RFC1833 [10] as far as what they should look like
   for specific protocols.

   For TCP over IPv4 and for UDP over IPv4, the format of r_addr is the
   US-ASCII string:

   h1.h2.h3.h4.p1.p2

   The prefix, "h1.h2.h3.h4", is the standard textual form for
   representing an IPv4 address, which is always four octets long.
   Assuming big-endian ordering, h1, h2, h3, and h4, are respectively, at both the first through fourth octets each converted to ASCII-decimal.
   Assuming big-endian ordering, p1 client and p2 are, respectively, the first server.

1.5.2.  Protocol Structure

1.5.2.1.  Core Protocol

   Unlike NFS Versions 2 and second octets each converted to ASCII-decimal.  For example, if 3, which used a
   host, in big-endian order, has an address series of 0x0A010307 and there is ancillary
   protocols (e.g.  NLM, NSM, MOUNT), within all minor versions of NFS
   version 4 only a service listening on, in big endian order, port 0x020F (decimal
   527), then complete universal address single RPC protocol is "10.1.3.7.2.15".

   For TCP over IPv4 the value used to make requests of r_netid is the string "tcp".  For UDP
   over IPv4
   server.  Facilties, that had been separate protocols, such as
   locking, are now intergrated within a single unified protocol.

   A significant departure from the value versions of r_netid is the string "udp".

   For TCP over IPv6 and for UDP over IPv6, NFS protocol before
   version 4 is the format introduction of r_addr is the
   US-ASCII string:

   x1:x2:x3:x4:x5:x6:x7:x8.p1.p2

   The suffix "p1.p2" is COMPOUND procedure.  For the service port, NFS
   version 4 protocol, in all minor versions, there are two RPC
   procedures, NULL and COMPOUND.  The COMPOUND procedure is computed the same way defined as with universal addresses for TCP
   a series of individual operations and UDP over IPv4.  The prefix,
   "x1:x2:x3:x4:x5:x6:x7:x8", is these operations perform the standard textual form for
   representing an IPv6 address as defined
   sorts of functions performed by traditional NFS procedures.

   The operations combined within a COMPOUND request are evaluated in Section 2.2
   order by the server, without any atomicity guarantees.  A limited set
   of RFC1884
   [5].  Additionally, facilities exist to pass results from one operation to another.
   Once an operation returns a failing result, the two alternative forms specified in Section
   2.2 evaluation ends and
   the results of RFC1884 [5] all evaluated operations are also acceptable.

   For TCP over IPv6 returned to the value client.

   With the use of r_netid is the string "tcp6".  For UDP
   over IPv6 COMPOUND procedure, the value of r_netid client is able to build
   simple or complex requests.  These COMPOUND requests allow for a
   reduction in the string "udp6".

1.2.11.  cb_client4

   struct cb_client4 {
       unsigned int  cb_program;
       clientaddr4   cb_location;
   };

   This structure is used number of RPCs needed for logical file system
   operations.  For example, multi-component lookup requests can be
   constructed by the client combining multiple LOOKUP operations.  Those can be
   further combined with operations such as GETATTR, READDIR, or OPEN
   plus READ to inform do more complicated sets of operation without incurring
   additional latency.

   NFS Version 4.1 also contains a a considerable set of callback
   operations in which the server of its call
   back address; includes makes an RPC directed at the program number and client address.

1.2.12.  nfs_client_id4

   struct nfs_client_id4 {
       verifier4     verifier;
       opaque        id<NFS4_OPAQUE_LIMIT>
   };

   This client.
   Callback RPC's have a similar structure is part to that of the arguments to normal server
   requests.  For the SETCLIENTID operation.
   NFS4_OPAQUE_LIMIT NFS version 4 protocol callbacks in all minor
   versions, there are two RPC procedures, NULL and CB_COMPOUND.  The
   CB_COMPOUND procedure is defined as 1024.

1.2.13.  open_owner4

   struct open_owner4 {
       clientid4     clientid;
       opaque        owner<NFS4_OPAQUE_LIMIT>
   };

   This structure is used in analogous fashion to identify the owner that of open state.
   NFS4_OPAQUE_LIMIT is defined as 1024.

1.2.14.  lock_owner4

   struct lock_owner4 {
       clientid4     clientid;
       opaque        owner<NFS4_OPAQUE_LIMIT>
   };

   This structure is used to identify the owner
   COMPOUND with its own set of file locking state.
   NFS4_OPAQUE_LIMIT is defined as 1024.

1.2.15.  open_to_lock_owner4

   struct open_to_lock_owner4 {
       seqid4          open_seqid;
       stateid4        open_stateid;
       seqid4          lock_seqid;
       lock_owner4     lock_owner;
   };

   This structure is used for the first LOCK operation done for an
   open_owner4.  It provides both the open_stateid and lock_owner such
   that the transition is made from a valid open_stateid sequence to
   that callback operations.

   Addition of the new lock_stateid sequence.  Using this mechanism avoids server and callback operation within the confirmation COMPOUND and
   CB_COMPOUND request framework provide means of extending the lock_owner/lock_seqid pair since it is tied
   to established state protocol
   in the form subsequent minor versions.

   Except for a small number of the open_stateid/open_seqid.

1.2.16.  stateid4

   struct stateid4 {
       uint32_t        seqid;
       opaque          other[12];
   };

   This structure is used operations needed for session creation,
   server requests and callback requests are performed within the various state sharing mechanisms
   between the
   context of a session.  Sessions provide a client context for every
   request and server.  For the client, this support robust replay protection for non-idempotent
   requests.

1.5.2.2.  Parallel Access

   Minor version one supports high-performance data structure
   is read-only.  The starting value of the seqid field is undefined.
   The server is required access to increment the seqid field monotonically at
   each transition a
   clustered server implementation by enabling a separation of metadata
   access and data access, with the stateid.  This latter done to multiple servers in
   parallel.

   Such parallel data access is important since the client
   will inspect controlled by recallable objects known
   as "layouts", which are integrated into the seqid in OPEN stateids protocol locking model.
   Clients direct requests for data access to determine the order a set of
   OPEN processing done data servers
   specified by the server.

1.2.17.  layouttype4

   enum layouttype4 {
       LAYOUT_NFSV4_FILES  = 1,
       LAYOUT_OSD2_OBJECTS = 2,
       LAYOUT_BLOCK_VOLUME = 3
   };

   A layout type specifies the layout being used.  The implication is
   that clients have "layout drivers" that support one via a data storage protocol which may be
   NFSv4.1 or more layout
   types. may be another protocol.

1.5.3.  File System Model

   The general file server advertises system model used for the layout types it supports
   through NFS version 4.1 protocol
   is the LAYOUT_TYPES same as previous versions.  The server file system attribute.  A client asks for
   layouts of is
   hierarchical with the regular files contained within being treated as
   opaque byte streams.  In a particular type in LAYOUTGET, slight departure, file and passes those layouts directory names
   are encoded with UTF-8 to its layout driver.  The set deal with the basics of well known layout types must be
   defined.  As well,
   internationalization.

   The NFS version 4.1 protocol does not require a private range of layout types is separate protocol to be defined
   provide for the initial mapping between path name and filehandle.
   All file systems exported by this document. a server are presented as a tree so that
   all file systems are reachable from a special per-server global root
   filefilandle.  This would allow custom installations allows LOOKUP operations to introduce
   new layout types.

   [[Comment.1: Determine private range of layout types]]

   New layout types must be specified in RFCs approved used to perform
   functions previously provided by the IESG
   before becoming part of the pNFS specification. MOUNT protocol.  The LAYOUT_NFSV4_FILES enumeration specifies server
   provides any necessary pseudo fileystems to bridge any gaps that
   arise due unexported gaps between exported file systems.

1.5.3.1.  Filehandles

   As in previous versions of the NFSv4 NFS protocol, opaque filehandles are
   used to identify individual files and directories.  Lookup-type and
   create operations are used to go from file
   layout type and directory names to the
   filehandle which is then used to be used.  The LAYOUT_OSD2_OBJECTS enumeration
   specifies that identify the object layout, as defined in [11], is to subsequent
   operations.

   The NFS version 4.1 protocol provides support for both persistent
   filehandles, guaranteed to be used.
   Similarly, valid for the LAYOUT_BLOCK_VOLUME enumeration that lifetime of the block/volume
   layout, as defined in [12], is file
   system object designated.  In addition it provides support to be used.

1.2.18.  pnfs_deviceid4

   typedef uint32_t pnfs_deviceid4;  /* 32-bit device ID */

   Layout information includes device IDs that specify a storage device
   through servers
   to provide filehandles with more limited validity guarantees, called
   volatile filehandles.

1.5.3.2.  File Attributes

   The NFS version 4.1 protocol has a compact handle.  Addressing rich and type information is
   obtained with extensible attribute
   structure.  Only a small set of the GETDEVICEINFO operation.  A client must not assume
   that device IDs defined attributes are valid across metadata mandatory
   and must be provided by all server reboots. implementations.  The device
   ID other
   attributes are known as "recommended" attributes.

   One significant recommended file attribute is qualified by the layout type Access Control List
   (ACL) attribute.  This attribute provides for directory and are unique per file system
   (FSID).  This allows different layout drivers to generate device IDs
   without
   access control beyond the need model used in NFS Versions 2 and 3.  The
   ACL definition allows for co-ordination.  See Section 16.1.4 specification specific sets of permissions
   for more
   details.

1.2.19.  pnfs_netaddr4

   struct pnfs_netaddr4 {
       string  r_netid<>; /* network ID */
       string  r_addr<>;  /* universal address */
   };

   For a description individual users and groups.  In addition, ACL inheritance allows
   propagation of the r_netid access permissions and r_addr fields see the
   descriptions provided in the clientaddr4 structure description.

1.2.20.  pnfs_devlist_item4

   struct pnfs_devlist_item4 {
           pnfs_deviceid4          id;
           opaque                  device_addr<>;
   };

   An array restriction down a directory
   tree as fileystsme objects are created.

   One other type of these values attribute is returned by the GETDEVICELIST operation.
   They define the set of devices named attribute.  A named
   attribute is an opaque byte stream that is associated with a
   directory or file system for the
   layout type specified in the GETDEVICELIST4args.

   The device address is used and referred to set up by a communication channel with the
   storage device.  Different layout types will require different types
   of structures string name.  Named attributes
   are meant to define how they communicate with storage devices.

   The opaque device_addr field must be interpreted based on the
   specified layout type.

   This document defines the device address for the NFSv4 used by client applications as a method to associate
   application specific data with a regular file layout
   (struct pnfs_netaddr4), which identifies or directory.

1.5.3.3.  Multi-server Namespace

   NFS Version 4.1 contains a storage device by network
   IP address and port number (similar of features to struct clientaddr4).  This is
   sufficient for the clients allow implementation
   of namespaces that cross server boundaries and that allow to communicate with the NFSv4 storage
   devices, and may be sufficient
   facilitate a non-disruptive transfer of support for other layout types as well.
   Device types individual file
   systems between servers.  They are all based upon attributes that
   allow one file system to specify alternate or new locations for object storage devices and block storage devices
   (e.g., SCSI volume labels) will be defined by their respective layout
   specifications.

1.2.21.  pnfs_layout4

   struct pnfs_layout4 {
       offset4                 offset;
       length4                 length;
       pnfs_layoutiomode4      iomode;
       pnfs_layouttype4        type;
       opaque                  layout<>;
   };

   The pnfs_layout4 structure defines a layout for a file.  The layout
   type specific data is opaque within this structure and must be
   interepreted based on the layout type.  Currently, only the NFSv4 that
   file layout type is defined; see Section 17.1 for its definition.
   Since layouts are sub-dividable, the offset and length system.

   These attributes may be used together with the file's filehandle, the clientid, iomode, and layout type,
   identifies the layout.

   [[Comment.2: there is concept of absent file
   system which provide specifications for additional locations but no
   actual file system content.  This allows a discussion number of moving the striping
   information, or more generally the "aggregation scheme", up important
   facilties:

   o  Location attributes may be used with absent file systems to
      implement referrals whereby one server may direct the
   generic layout level.  This creates client to a two-layer
      file system where the top
   level is a switch on different data placement layouts, and the next
   level down is a switch on different data storage types. provided by another server.  This lets
   different layouts (e.g., striping or mirroring allows extensive
      mult-server namspaces to be constructed.

   o  Location attributes may be provided for present file systems to
      provide the locations alternate file system instances or redundant servers) replicas
      to be layered over different storage devices.  This would move
   geometry information out of nfsv4_file_layouttype4 and up into a
   generic pnfs_striped_layout type used in the event that would specify the current file system instance
      becomes unavailable.

   o  Location attributes may be provided when a set previously present file
      system becomes absent.  This allows non-disruptive migration of
   pnfs_deviceid4 and pnfs_devicetype4
      file systems to use alternate servers.

1.5.4.  Locking Facilities

   As mentioned previously, NFS v4.1, is a single protocol which
   includes locking facilities.  These locking facilities include
   support for storage.  Instead many types of
   nfsv4_file_layouttype4, there would be pnfs_nfsv4_devicetype4.]]

1.2.22.  pnfs_layoutupdate4

   struct pnfs_layoutupdate4 {
       pnfs_layouttype4        type;
       opaque                  layoutupdate_data<>;
   };
   The pnfs_layoutupdate4 structure is used by locks including a number of sorts of
   recallable locks.  Recallable locks such as delegations allow the
   client to return
   'updated' layout information to be assured that certain events will not occur so long as
   that lock is held.  When circumstances change, the metadata server at LAYOUTCOMMIT
   time.  This structure provides lock is recalled
   via a channel to pass layout type specific
   information back callback via a callback request.  The assurances provided by
   delegations allow more extensive caching to be done safely when
   circumstances allow it.

   o  Share reservations as established by OPEN operations.

   o  Byte-range locks.

   o  File delegations which are recallable locks that assure the metadata server.  E.g., for block/volume
   layout types this could include the list of reserved blocks holder
      that were
   written.  The contents of inconsitent opens and file changes cannot occur so long as
      the opaque layoutupdate_data argument delegation is held.

   o  Directory delegations which are
   determined by recallable delegations that assure
      the layout type and are defined in their context.  The
   NFSv4 file-based layout does not use this structure, thus holder that inconsistent directory modifications cannot occur
      so long as the
   update_data field should have a zero length.

1.2.23.  layouthint4

   struct pnfs_layouthint4 {
       pnfs_layouttype4      type;
       opaque                layouthint_data<>;
   };

   The layouthint4 structure deleagtion is used by held.

   o  Layouts which are recallable objects that assure the client holder that
      direct access to pass in a hint
   about the type of layout it would like created for a particular file.
   It is the structure specified file data may be performed directly by the FILE_LAYOUT_HINT attribute
   described below.  The metadata server may ignore
      client and that no change to the hint, or data's location inconsistent with
      that access may
   selectively ignore fields within the hint.  This hint should be
   provided at create time made so long as part of the initial attributes within
   OPEN.  The NFSv4 file-based layout uses the "nfsv4_file_layouthint"
   structure as defined in Section 17.1.

1.2.24.  pnfs_layoutiomode4

   enum pnfs_layoutiomode4 {
       LAYOUTIOMODE_READ          = 1,
       LAYOUTIOMODE_RW            = 2,
       LAYOUTIOMODE_ANY           = 3
   };

   The iomode specifies whether is held.

   All locks for a given client are tied together under a single client-
   wide lease.  All requests made on sessions associated with the client intends
   renew that lease.  When leases are not promptly renewed lock are
   subject to read or write
   (with revocation.  In the possibility event of reading) the data represented by server reinitialization,
   clients have the layout. opportunity to safely reclaim their locks within a
   special grace period.

1.6.  General Definitions

   The ANY iomode MUST NOT be used following definitions are provided for LAYOUTGET, however, it can be
   used the purpose of providing
   an appropriate context for LAYOUTRETURN and LAYOUTRECALL.  The ANY iomode specifies
   that layouts pertaining to both READ and RW iomodes are being
   returned or recalled, respectively. the reader.

   Client  The metadata server's use of "client" is the
   iomode may depend on entity that accesses the layout type being used. NFS server's
      resources.  The storage devices client may validate I/O accesses against be an application which contains the iomode and reject invalid
   accesses.

1.2.25.  nfs_impl_id4

   struct nfs_impl_id4 {
       utf8str_cis   nii_domain;
       utf8str_cs    nii_name;
       nfstime4      nii_date;
   };

   This structure is used
      logic to identify client and access the NFS server implementation
   detail. directly.  The nii_domain field is the DNS domain name that client may also be
      the
   implementer is associated with.  The nii_name field is traditional operating system client remote file system
      services for a set of applications.

      In the product
   name case of file locking the implementation and client is completely free form.  It the entity that
      maintains a set of locks on behalf of one or more applications.
      This client is
   encouraged responsible for crash or failure recovery for those
      locks it manages.

      Note that multiple clients may share the nii_name be same transport and
      multiple clients may exist on the same network node.

   Clientid  A 64-bit quantity used as a unique, short-hand reference to distinguish machine
   architecture, machine platforms, revisions, versions,
      a client supplied Verifier and patch
   levels. ID.  The nii_date field server is responsible for
      supplying the timestamp Clientid.

   Lease  An interval of when time defined by the software
   instance was published or built.

1.2.26.  impl_ident4

   struct impl_ident4 {
       clientid4           ii_clientid;
       struct nfs_impl_id4 ii_impl_id;
   };

   This is used server for exchanging implementation identification between which the client and server.

2.  RPC and Security Flavor

   The NFS version 4.1 protocol
      is irrevocably granted a Remote Procedure Call (RPC)
   application that uses RPC version 2 and lock.  At the corresponding eXternal
   Data Representation (XDR) as defined in [RFC1831] and [RFC4506]. end of a lease period the
      lock may be revoked if the lease has not been extended.  The
   RPCSEC_GSS security flavor as defined in [RFC2203] MUST lock
      must be used as revoked if a conflicting lock has been granted after the mechanism
      lease interval.

      All leases granted by a server have the same fixed interval.  Note
      that the fixed interval was chosen to deliver stronger security for alleviate the NFS version 4
   protocol.

2.1.  Ports and Transports

   Historically, NFS version 2 and version 3 servers expense a
      server would have resided on
   port 2049. in maintaining state about variable length
      leases across server failures.

   Lock  The registered port 2049 [RFC3232] for the NFS protocol
   should be the default configuration.  NFSv4 clients SHOULD NOT use term "lock" is used to refer any of record (byte- range)
      locks, share reservations, delegations or layouts unless
      specifically stated otherwise.

   Server  The "Server" is the RPC binding protocols as described in [RFC1833].

   Where an entity responsible for coordinating
      client access to a set of file systems.

   Stable Storage  NFS version 4 implementation supports operation over the IP
   network protocol, the supported transports between NFS and IP MUST
   have the following two attributes:

   1.  The transport must support reliable delivery of data in the order
       it was sent.

   2.  The transport servers must be among the IETF-approved congestion control
       transport protocols.

   At the time this document was written, the only two transports able to recover without
      data loss from multiple power failures (including cascading power
      failures, that
   had the above attributes were TCP is, several power failures in quick succession),
      operating system failures, and SCTP.  To enhance hardware failure of components
      other than the
   possibilities storage medium itself (for example, disk,
      nonvolatile RAM).

      Some examples of stable storage that are allowable for interoperability, an NFS version 4 implementation
   MUST support operation over the TCP transport protocol.

   If TCP is used as the transport, the client and
      server SHOULD use
   persistent connections for at least two reasons: include:

      1.  This will prevent the weakening  Media commit of TCP's congestion control via
       short lived connections and will improve performance for data, that is, the WAN
       environment by eliminating modified data has been
          successfully written to the need disk media, for SYN handshakes. example, the disk
          platter.

      2.  The NFSv4.1 callback model has changed from NFSv4.0,  An immediate reply disk drive with battery-backed on- drive
          intermediate storage or uninterruptible power system (UPS).

      3.  Server commit of data with battery-backed intermediate storage
          and requires
       the client recovery software.

      4.  Cache commit with uninterruptible power system (UPS) and server to maintain
          recovery software.

   Stateid  A 128-bit quantity returned by a client-created channel for
       the server to use.

   As noted in the Security Considerations section, the authentication
   model for NFS version 4 has moved from machine-based to principal-
   based.  However, this modification of that uniquely
      defines the authentication model does
   not imply a technical requirement to move open and locking state provided by the transport connection
   management model from whole machine-based to one based on a per user
   model.  In particular, NFS over TCP client implementations have
   traditionally multiplexed traffic server for multiple users over a common
   TCP connection between an NFS client and server.  This has been true,
   regardless whether the NFS client is using AUTH_SYS, AUTH_DH,
   RPCSEC_GSS
      specific open or any other flavor.  Similarly, NFS over TCP server
   implementations have assumed such lock owner for a model specific file. meaning and thus scale the
   implementation of TCP connection management in proportion to are
      reserved values.

   Verifier  A 64-bit quantity generated by the
   number of expected client machines.  NFS version 4.1 will not modify
   this connection management model.  NFS version 4.1 clients that
   violate this assumption can expect scaling issues on the server and
   hence reduced service.

   Note that for various timers, the client and server should avoid
   inadvertent synchronization of those timers.  For further discussion
   of the general issue refer
      can use to [Floyd].

2.1.1.  Client Retransmission Behavior

   When processing a request received over a reliable transport such as
   TCP, the NFS version 4.1 server MUST NOT silently drop the request,
   except determine if the transport connection client has been broken.  Given such a
   contract between NFS version 4.1 clients restarted and servers, clients MUST
   NOT retry a request unless one or both of the following are true:

   o  The transport connection has been broken

   o lost all
      previous lock state.

1.7.  Differences from NFSv4.0

   The procedure being retried is the NULL procedure

   Since reliable transports, such as TCP, do not always synchronously
   inform a peer when the other peer has broken the connection (for
   example, when an NFS server reboots), following summarizes the NFS differences between minor version 4.1 client may
   want to actively "probe" one
   and the connection to see if has been broken.
   Use base protocol:

   o  Implementation of the NULL procedure is one recommended way sessions model.

   o  Support for parallel access to do so.  So, when
   a client experiences a remote procedure call timeout (of some
   arbitrary implementation specific amount), rather than retrying data.

   o  Addition of the
   remote procedure call, it could instead issue a NULL procedure call RECLAIM_COMPLETE operation to better structiure
      the server.  If the server has died, the transport connection
   break will eventually be indicated lock reclamation process.

   o  < Support for directory delegation.

   o  Operations to the NFS version 4.1 client.
   The client can then reconnect, and then retry the original request.
   If the NULL procedure call gets re-obtain a response, the connection has not
   broken.  The client can decide to wait longer delegation.

   o  Support for the original
   request's response, or it can break the transport connection client and
   reconnect before re-sending the original request.

   For callbacks from the server to the client, the same rules apply,
   but the server doing the callback becomes the client, and the client
   receiving the callback becomes the server.

2.2.  Security Flavors

   Traditional RPC implementations have included AUTH_NONE, AUTH_SYS,
   AUTH_DH, implementation id's.

2.  Protocol Data Types

   The syntax and AUTH_KRB4 as security flavors.  With [RFC2203] an
   additional security flavor of RPCSEC_GSS has been introduced which
   uses the functionality of GSS-API [RFC2743].  This allows for semantics to describe the use data types of various security mechanisms by the RPC layer without the
   additional implementation overhead of adding RPC security flavors.
   For NFS
   version 4, the RPCSEC_GSS security flavor MUST be implemented
   to enable 4 protocol are defined in the mandatory security mechanism.  Other flavors, such as,
   AUTH_NONE, AUTH_SYS, XDR RFC4506 [3] and AUTH_DH MAY be implemented as well.

2.2.1.  Security mechanisms for NFS version 4 RPC RFC1831
   [4] documents.  The use of RPCSEC_GSS requires selection of: mechanism, quality of
   protection, next sections build upon the XDR data types to
   define types and service (authentication, integrity, privacy).  The
   remainder of this document will refer structures specific to these three parameters of
   the RPCSEC_GSS security as this protocol.

2.1.  Basic Data Types

                   These are the security triple.

2.2.1.1.  Kerberos V5

   The Kerberos V5 GSS-API mechanism as described in [RFC1964] MUST be
   implemented.

    column descriptions:
    1 == number of pseudo flavor
    2 == name of pseudo flavor
    3 == mechanism's OID
    4 == RPCSEC_GSS service

    1      2     3                    4
    --------------------------------------------------------------------
    390003 krb5  1.2.840.113554.1.2.2 rpc_gss_svc_none
    390004 krb5i 1.2.840.113554.1.2.2 rpc_gss_svc_integrity
    390005 krb5p 1.2.840.113554.1.2.2 rpc_gss_svc_privacy

   Note that the pseudo flavor is presented here as a mapping aid to the
   implementor.  Because this NFS protocol includes a method base NFSv4 data types.

   +---------------+---------------------------------------------------+
   | Data Type     | Definition                                        |
   +---------------+---------------------------------------------------+
   | int32_t       | typedef int int32_t;                              |
   | uint32_t      | typedef unsigned int uint32_t;                    |
   | int64_t       | typedef hyper int64_t;                            |
   | uint64_t      | typedef unsigned hyper uint64_t;                  |
   | attrlist4     | typedef opaque attrlist4<>;                       |
   |               | Used for file/directory attributes                |
   | bitmap4       | typedef uint32_t bitmap4<>;                       |
   |               | Used in attribute array encoding.                 |
   | changeid4     | typedef uint64_t changeid4;                       |
   |               | Used in definition of change_info                 |
   | clientid4     | typedef uint64_t clientid4;                       |
   |               | Shorthand reference to
   negotiate security and it understands the GSS-API mechanism, the
   pseudo flavor is not needed.  The pseudo flavor client identification      |
   | component4    | typedef utf8str_cs component4;                    |
   |               | Represents path name components                   |
   | count4        | typedef uint32_t count4;                          |
   |               | Various count parameters (READ, WRITE, COMMIT)    |
   | length4       | typedef uint64_t length4;                         |
   |               | Describes LOCK lengths                            |
   | linktext4     | typedef utf8str_cs linktext4;                     |
   |               | Symbolic link contents                            |
   | mode4         | typedef uint32_t mode4;                           |
   |               | Mode attribute data type                          |
   | nfs_cookie4   | typedef uint64_t nfs_cookie4;                     |
   |               | Opaque cookie value for READDIR                   |
   | nfs_fh4       | typedef opaque nfs_fh4<NFS4_FHSIZE>               |
   |               | Filehandle definition; NFS4_FHSIZE is needed defined as  |
   |               | 128                                               |
   | nfs_ftype4    | enum nfs_ftype4;                                  |
   |               | Various defined file types                        |
   | nfsstat4      | enum nfsstat4;                                    |
   |               | Return value for NFS
   version 3 since the security negotiation operations                       |
   | offset4       | typedef uint64_t offset4;                         |
   |               | Various offset designations (READ, WRITE, LOCK,   |
   |               | COMMIT)                                           |
   | pathname4     | typedef component4 pathname4<>;                   |
   |               | Represents path name for fs_locations             |
   | qop4          | typedef uint32_t qop4;                            |
   |               | Quality of protection designation in SECINFO      |
   | sec_oid4      | typedef opaque sec_oid4<>;                        |
   |               | Security Object Identifier The sec_oid4 data type |
   |               | is done via not really opaque. Instead contains an ASN.1   |
   |               | OBJECT IDENTIFIER as used by GSS-API in the MOUNT
   protocol.

   For       |
   |               | mech_type argument to GSS_Init_sec_context. See   |
   |               | RFC2743 [8] for details.                          |
   | seqid4        | typedef uint32_t seqid4;                          |
   |               | Sequence identifier used for file locking         |
   | utf8string    | typedef opaque utf8string<>;                      |
   |               | UTF-8 encoding for strings                        |
   | utf8str_cis   | typedef opaque utf8str_cis;                       |
   |               | Case-insensitive UTF-8 string                     |
   | utf8str_cs    | typedef opaque utf8str_cs;                        |
   |               | Case-sensitive UTF-8 string                       |
   | utf8str_mixed | typedef opaque utf8str_mixed;                     |
   |               | UTF-8 strings with a discussion of NFS' use of RPCSEC_GSS case sensitive prefix and Kerberos V5, please
   see [RFC2623].

2.2.1.2.  LIPKEY as a security triple

   The LIPKEY GSS-API mechanism  |
   |               | case insensitive suffix.                          |
   | verifier4     | typedef opaque verifier4[NFS4_VERIFIER_SIZE];     |
   |               | Verifier used for various operations (COMMIT,     |
   |               | CREATE, OPEN, READDIR, SETCLIENTID,               |
   |               | SETCLIENTID_CONFIRM, WRITE) NFS4_VERIFIER_SIZE is |
   |               | defined as described in [RFC2847] MUST be
   implemented and provide the following security triples.  The
   definition 8.                                     |
   +---------------+---------------------------------------------------+

                          End of the columns matches the previous subsection "Kerberos
   V5 as security triple" Base Data Types

                                  Table 1      2        3                   4
    --------------------------------------------------------------------
    390006 lipkey   1.3.6.1.5.5.9       rpc_gss_svc_none
    390007 lipkey-i 1.3.6.1.5.5.9       rpc_gss_svc_integrity
    390008 lipkey-p 1.3.6.1.5.5.9       rpc_gss_svc_privacy

2.2.1.3.  SPKM-3 as a security triple

2.2.  Structured Data Types

2.2.1.  nfstime4

   struct nfstime4 {
       int64_t seconds;
       uint32_t nseconds;
   }

   The SPKM-3 GSS-API mechanism as described in [RFC2847] MUST be
   implemented and provide nfstime4 structure gives the following security triples.  The
   definition number of seconds and nanoseconds
   since midnight or 0 hour January 1, 1970 Coordinated Universal Time
   (UTC).  Values greater than zero for the columns matches seconds field denote dates
   after the previous subsection "Kerberos
   V5 as security triple".

    1      2        3                   5
    --------------------------------------------------------------------
    390009 spkm3    1.3.6.1.5.5.1.3     rpc_gss_svc_none
    390010 spkm3i   1.3.6.1.5.5.1.3     rpc_gss_svc_integrity
    390011 spkm3p   1.3.6.1.5.5.1.3     rpc_gss_svc_privacy

2.3.  Security Negotiation

   With 0 hour January 1, 1970.  Values less than zero for the NFS version 4 server potentially offering multiple security
   mechanisms,
   seconds field denote dates before the client needs a method to determine or negotiate which
   mechanism 0 hour January 1, 1970.  In
   both cases, the nseconds field is to be used for its communication with added to the server.  The
   NFS server may have multiple points within its filesystem name space
   that are available seconds field
   for use by NFS clients.  In turn the NFS server
   may final time representation.  For example, if the time to be configured such that each of these entry points may
   represented is one-half second before 0 hour January 1, 1970, the
   seconds field would have
   different or multiple security mechanisms in use.

   The security negotiation between client and server must be done with a secure channel to eliminate the possibility value of a third party
   intercepting the negotiation sequence negative one (-1) and forcing the client and
   server to choose
   nseconds fields would have a lower level value of security one-half second (500000000).
   Values greater than required or desired.
   See the section "Security Considerations" 999,999,999 for further discussion.

2.3.1.  SECINFO nseconds are considered invalid.

   This data type is used to pass time and SECINFO_NO_NAME

   The SECINFO date information.  A server
   converts to and SECINFO_NO_NAME operations allow from its local representation of time when processing
   time values, preserving as much accuracy as possible.  If the client to
   determine, on
   precision of timestamps stored for a per filehandle basis, what security triple file system object is less than
   defined, loss of precision can occur.  An adjunct time maintenance
   protocol is recommended to be
   used for reduce client and server access.  In general, time skew.

2.2.2.  time_how4

   enum time_how4 {
       SET_TO_SERVER_TIME4 = 0,
       SET_TO_CLIENT_TIME4 = 1
   };

2.2.3.  settime4

   union settime4 switch (time_how4 set_it) {
       case SET_TO_CLIENT_TIME4:
           nfstime4       time;
       default:
           void;
   };

   The above definitions are used as the client will not have attribute definitions to use
   either operation except during initial communication with set
   time values.  If set_it is SET_TO_SERVER_TIME4, then the server
   or when uses
   its local representation of time for the client crosses policy boundaries at time value.

2.2.4.  specdata4

   struct specdata4 {
       uint32_t specdata1; /* major device number */
       uint32_t specdata2; /* minor device number */
   };

   This data type represents additional information for the server.  It is
   possible that the server's policies change during the client's
   interaction therefore forcing device file
   types NF4CHR and NF4BLK.

2.2.5.  fsid4

   struct fsid4 {
       uint64_t        major;
       uint64_t        minor;
   };

2.2.6.  fs_location4

   struct fs_location4 {
       utf8str_cis    server<>;
       pathname4     rootpath;
   };

2.2.7.  fs_locations4

   struct fs_locations4 {
       pathname4     fs_root;
       fs_location4  locations<>;
   };

   The fs_location4 and fs_locations4 data types are used for the client
   fs_locations recommended attribute which is used for migration and
   replication support.

2.2.8.  fattr4

   struct fattr4 {
       bitmap4       attrmask;
       attrlist4     attr_vals;
   };

   The fattr4 structure is used to negotiate a new security
   triple.

2.3.2.  Security Error

   Based on the assumption that each NFS version 4 client represent file and server
   must support directory
   attributes.

   The bitmap is a minimum set counted array of security (i.e., LIPKEY, SPKM-3, and
   Kerberos-V5 all under RPCSEC_GSS), the NFS client will start its
   communication with the server with one 32 bit integers used to contain bit
   values.  The position of the minimal security
   triples.  During communication with integer in the server, array that contains bit n
   can be computed from the client may
   receive an NFS error of NFS4ERR_WRONGSEC. expression (n / 32) and its bit within that
   integer is (n mod 32).

   0            1
   +-----------+-----------+-----------+--
   |  count    | 31  ..  0 | 63  .. 32 |
   +-----------+-----------+-----------+--

2.2.9.  change_info4

   struct change_info4 {
       bool          atomic;
       changeid4     before;
       changeid4     after;
   };

   This error allows structure is used with the
   server CREATE, LINK, REMOVE, RENAME
   operations to notify let the client that know the security triple currently being
   used is not appropriate value of the change attribute
   for access to the server's filesystem
   resources. directory in which the target file system object resides.

2.2.10.  netaddr4

   struct netaddr4 {
       /* see struct rpcb in RFC1833 */
       string r_netid<>;    /* network id */
       string r_addr<>;     /* universal address */
   };

   The client netaddr4 structure is then responsible for determining what
   security triples used to identify TCP/IP based endpoints.
   The r_netid and r_addr fields are available at the server specified in RFC1833 [19], but they
   are underspecified in RFC1833 [19] as far as what they should look
   like for specific protocols.

   For TCP over IPv4 and choose one which is
   appropriate for UDP over IPv4, the client.  See format of r_addr is the section for
   US-ASCII string:

   h1.h2.h3.h4.p1.p2

   The prefix, "h1.h2.h3.h4", is the "SECINFO"
   operation standard textual form for further discussion of how
   representing an IPv4 address, which is always four octets long.
   Assuming big-endian ordering, h1, h2, h3, and h4, are respectively,
   the client will respond first through fourth octets each converted to
   the NFS4ERR_WRONGSEC error ASCII-decimal.
   Assuming big-endian ordering, p1 and use SECINFO.

2.3.3.  Callback RPC Authentication

   Callback authentication has changed in NFSv4.1 from NFSv4.0.

   NFSv4.0 required p2 are, respectively, the NFS server first
   and second octets each converted to create ASCII-decimal.  For example, if a security context for
   RPCSEC_GSS, AUTH_DH, and AUTH_KERB4,
   host, in big-endian order, has an address of 0x0A010307 and any other security flavor
   that had there is
   a security context.  It also required that principal issuing service listening on, in big endian order, port 0x020F (decimal
   527), then complete universal address is "10.1.3.7.2.15".

   For TCP over IPv4 the callback be value of r_netid is the same as string "tcp".  For UDP
   over IPv4 the principal that accepted value of r_netid is the callback
   parameters (via SETCLIENTID), string "udp".

   For TCP over IPv6 and that the client principal accepting
   the callback be the same as that which issued for UDP over IPv6, the SETCLIENTID.  This
   required format of r_addr is the NFS client to have an assigned machine credential.
   NFSv4.1 does not require a machine credential.  Instead, NFSv4.1
   allows an RPCSEC_GSS security context initiated by
   US-ASCII string:

   x1:x2:x3:x4:x5:x6:x7:x8.p1.p2

   The suffix "p1.p2" is the client service port, and
   eswtablished on both is computed the client same way
   as with universal addresses for TCP and server to be used on callback
   RPCs sent by the server to the client. UDP over IPv4.  The BIND_BACKCHANNEL
   operation prefix,
   "x1:x2:x3:x4:x5:x6:x7:x8", is used establish RPCSEC_GSS contexts (if the client so
   desires) on the server.  No support standard textual form for AUTH_DH, or AUTH_KERB4 is
   specified.

2.3.4.  GSS Server Principal

   Regardless
   representing an IPv6 address as defined in Section 2.2 of what security mechanism under RPCSEC_GSS is being used, RFC1884
   [9].  Additionally, the NFS server, MUST identify itself two alternative forms specified in GSS-API via a
   GSS_C_NT_HOSTBASED_SERVICE name type.  GSS_C_NT_HOSTBASED_SERVICE
   names are Section
   2.2 of the form:

   service@hostname RFC1884 [9] are also acceptable.

   For NFS, TCP over IPv6 the "service" element is

   nfs

   Implementations value of security mechanisms will convert nfs@hostname to
   various different forms. r_netid is the string "tcp6".  For Kerberos V5, LIPKEY, and SPKM-3, UDP
   over IPv6 the
   following form value of r_netid is RECOMMENDED:

   nfs/hostname

3.  Filehandles

   The filehandle in the NFS protocol is a per server unique identifier
   for a filesystem object. string "udp6".

2.2.11.  clientaddr4

   typedef netaddr4 clientaddr4;

   The contents clientaddr4 structure is used as part of the filehandle are opaque SETCLIENTID
   operation to either specify the client.  Therefore, the server is responsible for translating
   the filehandle to an internal representation address of the filesystem
   object.

3.1.  Obtaining the First Filehandle

   The operations client that is using a
   clientid or as part of the NFS protocol are defined in terms of one or
   more filehandles.  Therefore, callback registration.

2.2.12.  cb_client4

   struct cb_client4 {
       unsigned int  cb_program;
       netaddr4      cb_location;
   };

   This structure is used by the client needs a filehandle to
   initiate communication with the server.  With inform the NFS version 2
   protocol [RFC1094] and server of its call
   back address; includes the NFS version 3 protocol [RFC1813], there
   exists an ancillary protocol to obtain this first filehandle.  The
   MOUNT protocol, RPC program number 100005, provides the mechanism and client address.

2.2.13.  nfs_client_id4

   struct nfs_client_id4 {
       verifier4     verifier;
       opaque        id<NFS4_OPAQUE_LIMIT>
   };

   This structure is part of
   translating a string based filesystem path name the arguments to a filehandle which
   can then be the SETCLIENTID operation.
   NFS4_OPAQUE_LIMIT is defined as 1024.

2.2.14.  open_owner4

   struct open_owner4 {
       clientid4     clientid;
       opaque        owner<NFS4_OPAQUE_LIMIT>
   };

   This structure is used by to identify the NFS protocols.

   The MOUNT protocol has deficiencies in owner of open state.
   NFS4_OPAQUE_LIMIT is defined as 1024.

2.2.15.  lock_owner4

   struct lock_owner4 {
       clientid4     clientid;
       opaque        owner<NFS4_OPAQUE_LIMIT>
   };

   This structure is used to identify the area owner of security and use
   via firewalls. file locking state.
   NFS4_OPAQUE_LIMIT is defined as 1024.

2.2.16.  open_to_lock_owner4

   struct open_to_lock_owner4 {
       seqid4          open_seqid;
       stateid4        open_stateid;
       seqid4          lock_seqid;
       lock_owner4     lock_owner;
   };

   This structure is one reason used for the first LOCK operation done for an
   open_owner4.  It provides both the open_stateid and lock_owner such
   that the use transition is made from a valid open_stateid sequence to
   that of the public
   filehandle was introduced in [RFC2054] and [RFC2055].  With new lock_stateid sequence.  Using this mechanism avoids
   the use confirmation of the public filehandle lock_owner/lock_seqid pair since it is tied
   to established state in combination with the LOOKUP operation in
   the NFS version 2 and 3 protocols, it has been demonstrated that form of the
   MOUNT protocol open_stateid/open_seqid.

2.2.17.  stateid4

   struct stateid4 {
       uint32_t        seqid;
       opaque          other[12];
   };

   This structure is unnecessary used for viable interaction the various state sharing mechanisms
   between NFS the client and server.

   Therefore, the NFS version 4 protocol will not use an ancillary
   protocol for translation from string based path names to a
   filehandle.  Two special filehandles will be used as starting points
   for  For the NFS client.

3.1.1.  Root Filehandle client, this data structure
   is read-only.  The first starting value of the special filehandles seqid field is the ROOT filehandle. undefined.
   The
   ROOT filehandle server is required to increment the "conceptual" root seqid field monotonically at
   each transition of the filesystem name space
   at stateid.  This is important since the NFS server.  The client uses or starts with the ROOT
   filehandle by employing the PUTROOTFH operation.  The PUTROOTFH
   operation instructs the server to set
   will inspect the "current" filehandle seqid in OPEN stateids to determine the
   ROOT order of
   OPEN processing done by the server's file tree.  Once this PUTROOTFH operation is
   used, server.

2.2.18.  layouttype4

   enum layouttype4 {
       LAYOUT_NFSV4_FILES  = 1,
       LAYOUT_OSD2_OBJECTS = 2,
       LAYOUT_BLOCK_VOLUME = 3
   };

   A layout type specifies the client can then traverse layout being used.  The implication is
   that clients have "layout drivers" that support one or more layout
   types.  The file server advertises the entirety of layout types it supports
   through the server's LAYOUT_TYPES file
   tree with the LOOKUP operation. system attribute.  A complete discussion client asks for
   layouts of the server
   name space is a particular type in the section "NFS Server Name Space".

3.1.2.  Public Filehandle LAYOUTGET, and passes those layouts
   to its layout driver.

   The second special filehandle layouttype4 structure is 32 bits in length.  The range
   represented by the PUBLIC filehandle.  Unlike layout type is split into two parts.  Types within
   the
   ROOT filehandle, range 0x00000000-0x7FFFFFFF are globally unique and are assigned
   according to the PUBLIC filehandle may be bound or represent an
   arbitrary filesystem object at description in Section 24.1; they are maintained by
   IANA.  Types within the server.  The server is responsible range 0x8000000-0xFFFFFFFF are site specific
   and for this binding.  It may be "private use" only.

   The LAYOUT_NFSV4_FILES enumeration specifies that the PUBLIC filehandle and the ROOT
   filehandle refer NFSv4 file
   layout type is to be used.  The LAYOUT_OSD2_OBJECTS enumeration
   specifies that the same filesystem object.  However, it object layout, as defined in [20], is up to be used.
   Similarly, the administrative software at the server and the policies of LAYOUT_BLOCK_VOLUME enumeration that the
   server administrator block/volume
   layout, as defined in [21], is to define the binding of the PUBLIC filehandle be used.

2.2.19.  deviceid4

   typedef uint32_t deviceid4;  /* 32-bit device ID */

   Layout information includes device IDs that specify a storage device
   through a compact handle.  Addressing and server filesystem object.  The type information is
   obtained with the GETDEVICEINFO operation.  A client may must not make any
   assumptions about this binding. assume
   that device IDs are valid across metadata server reboots.  The client uses the PUBLIC
   filehandle via the PUTPUBFH operation.

3.2.  Filehandle Types

   In device
   ID is qualified by the NFS version 2 and 3 protocols, there was one layout type of
   filehandle with a single set of semantics. and are unique per file system
   (FSID).  This type allows different layout drivers to generate device IDs
   without the need for co-ordination.  See Section 15.3.1.4 for more
   details.

2.2.20.  devlist_item4

   struct devlist_item4 {
           deviceid4          dli_id;
           opaque             dli_device_addr<>;
   };

   An array of filehandle these values is termed "persistent" in NFS Version 4.  The semantics returned by the GETDEVICELIST operation.
   They define the set of devices associated with a
   persistent filehandle remain file system for the same as before.  A new
   layout type of
   filehandle introduced specified in NFS Version 4 is the "volatile" filehandle,
   which attempts to accommodate certain server environments. GETDEVICELIST4args.

   The volatile filehandle type was introduced to device address server
   functionality or implementation issues which make correct
   implementation of a persistent filehandle infeasible.  Some server
   environments do not provide a filesystem level invariant that can be is used to construct set up a persistent filehandle. communication channel with the
   storage device.  Different layout types will require different types
   of structures to define how they communicate with storage devices.
   The underlying server
   filesystem may not provide opaque device_addr field must be interpreted based on the invariant or
   specified layout type.

   This document defines the server's filesystem
   programming interfaces may not provide access device address for the NFSv4 file layout
   (struct netaddr4 (Section 2.2.10)), which identifies a storage device
   by network IP address and port number.  This is sufficient for the
   clients to communicate with the needed
   invariant.  Volatile filehandles NFSv4 storage devices, and may ease the implementation of
   server functionality such be
   sufficient for other layout types as hierarchical well.  Device types for object
   storage management or
   filesystem reorganization or migration.  However, devices and block storage devices (e.g., SCSI volume labels)
   will be defined by their respective layout specifications.

2.2.21.  layout4

   struct layout4 {
       offset4                 lo_offset;
       length4                 lo_length;
       layoutiomode4           lo_iomode;
       layouttype4             lo_type;
       opaque                  lo_layout<>;
   };

   The layout4 structure defines a layout for a file.  The layout type
   specific data is opaque within this structure and must be
   interepreted based on the volatile
   filehandle increases layout type.  Currently, only the implementation burden NFSv4
   file layout type is defined; see Section 15.4.1 for the client. its definition.
   Since layouts are sub-dividable, the client will need to handle persistent offset and volatile
   filehandles differently, a file attribute length together with
   the file's filehandle, the clientid, iomode, and layout type,
   identifies the layout.

2.2.22.  layoutupdate4

   struct layoutupdate4 {
       layouttype4             lou_type;
       opaque                  lou_data<>;
   };

   The layoutupdate4 structure is defined which may be used by the client to determine return 'updated'
   layout information to the filehandle types being returned
   by metadata server at LAYOUTCOMMIT time.  This
   structure provides a channel to pass layout type specific information
   back to the metadata server.

3.2.1.  General Properties  E.g., for block/volume layout types
   this could include the list of a Filehandle reserved blocks that were written.
   The filehandle contains all the information contents of the server needs to
   distinguish an individual file.  To opaque lou_data argument are determined by the client,
   layout type and are defined in their context.  The NFSv4 file-based
   layout does not use this structure, thus the filehandle is
   opaque. update_data field should
   have a zero length.

2.2.23.  layouthint4

   struct layouthint4 {
       layouttype4           loh_type;
       opaque                loh_data<>;
   };

   The layouthint4 structure is used by the client stores filehandles for use to pass in a later request and
   can compare two filehandles from hint
   about the same server type of layout it would like created for equality by
   doing a byte-by-byte comparison.  However, the client MUST NOT
   otherwise interpret particular file.
   It is the contents of filehandles.  If two filehandles
   from structure specified by the same FILE_LAYOUT_HINT attribute
   described below.  The metadata server are equal, they MUST refer to may ignore the same file.
   Servers SHOULD try to maintain a one-to-one correspondence between
   filehandles and files but this is not required.  Clients MUST use
   filehandle comparisons only to improve performance, not for correct
   behavior.  All clients need to hint, or may
   selectively ignore fields within the hint.  This hint should be prepared for situations
   provided at create time as part of the initial attributes within
   OPEN.  The NFSv4 file-based layout uses the "nfsv4_file_layouthint"
   structure as defined in which it
   cannot be determined Section 15.4.1.

2.2.24.  layoutiomode4

   enum layoutiomode4 {
       LAYOUTIOMODE_READ          = 1,
       LAYOUTIOMODE_RW            = 2,
       LAYOUTIOMODE_ANY           = 3
   };

   The iomode specifies whether two filehandles denote the same object
   and in such cases, avoid making invalid assumptions which might cause
   incorrect behavior.  Further discussion of filehandle and attribute
   comparison in client intends to read or write
   (with the context possibility of reading) the data caching is presented in represented by the section
   "Data Caching layout.
   The ANY iomode MUST NOT be used for LAYOUTGET, however, it can be
   used for LAYOUTRETURN and File Identity".

   As an example, in the case LAYOUTRECALL.  The ANY iomode specifies
   that two different path names when
   traversed at the server terminate at layouts pertaining to both READ and RW iomodes are being
   returned or recalled, respectively.  The metadata server's use of the same filesystem object,
   iomode may depend on the
   server SHOULD return layout type being used.  The storage devices
   may validate I/O accesses against the same filehandle for each path. iomode and reject invalid
   accesses.

2.2.25.  nfs_impl_id4

   struct nfs_impl_id4 {
       utf8str_cis   nii_domain;
       utf8str_cs    nii_name;
       nfstime4      nii_date;
   };

   This can
   occur if a hard link structure is used to create two file names which refer to
   the same underlying file object and associated data.  For example, if
   paths /a/b/c identify client and /a/d/c refer to the same file, the server SHOULD
   return implementation
   detail.  The nii_domain field is the same filehandle for both path names traversals.

3.2.2.  Persistent Filehandle

   A persistent filehandle DNS domain name that the
   implementer is associated with.  The nii_name field is defined as having a fixed value for the
   lifetime product
   name of the filesystem object implementation and is completely free form.  It is
   encouraged that the nii_name be used to which it refers.  Once distinguish machine
   architecture, machine platforms, revisions, versions, and patch
   levels.  The nii_date field is the
   server creates timestamp of when the filehandle software
   instance was published or built.

2.2.26.  impl_ident4

   struct impl_ident4 {
       clientid4           ii_clientid;
       struct nfs_impl_id4 ii_impl_id;
   };

   This is used for exchanging implementation identification between
   client and server.

2.2.27.  threshold_item4

   struct threshold_item4 {
           layouttype4     thi_layout_type;
           bitmap4         thi_hintset;
           opaque          thi_hintlist<>;
   };

   This structure contains a filesystem object, the server
   MUST accept the same filehandle for the object for the lifetime list of hints specific to a layout type for
   helping the object.  If client determine when it should issue I/O directly
   through the metadata server restarts or reboots vs. the NFS server must
   honor data servers.  The hint structure
   consists of the same filehandle value as it did in layout type, a bitmap describing the server's previous
   instantiation.  Similarly, if set of hints
   supported by the filesystem is migrated, server, they may differ based on the new NFS
   server must honor layout type,
   and a list of hints, whose structure is determined by the same filehandle as hintset
   bitmap.  See the old NFS server. mdsthreshold attribute for more details.

   The persistent filehandle will be become stale or invalid when the
   filesystem object is removed.  When the server hintset is presented with a
   persistent filehandle that refers to a deleted object, it MUST return
   an error bitmap of NFS4ERR_STALE.  A filehandle may become stale when the
   filesystem containing the object is no longer available. following values:

   +-------------------------+---+---------+---------------------------+
   | name                    | # | Data    | Description               |
   |                         |   | Type    |                           |
   +-------------------------+---+---------+---------------------------+
   | threshold4_read_size    | 0 | length4 | The file
   system may become unavailable if size below which |
   |                         |   |         | it exists on removable media and the
   media is no longer available at the server or the filesystem in whole
   has been destroyed or the filesystem has simply been removed from the
   server's name space (i.e. unmounted in a UNIX environment).

3.2.3.  Volatile Filehandle

   A volatile filehandle does not share recommended to read |
   |                         |   |         | data through the same longevity
   characteristics of a persistent filehandle. MDS.     |
   | threshold4_write_size   | 1 | length4 | The server may determine
   that a volatile filehandle file size below which |
   |                         |   |         | it is no longer valid at many different
   points in time.  If the server can definitively determine that a
   volatile filehandle refers recommended to an object that has been removed,      |
   |                         |   |         | write data through the
   server should return NFS4ERR_STALE    |
   |                         |   |         | MDS.                      |
   | threshold4_read_iosize  | 2 | length4 | For read I/O sizes below  |
   |                         |   |         | this threshold it is      |
   |                         |   |         | recommended to read data  |
   |                         |   |         | through the client (as MDS           |
   | threshold4_write_iosize | 3 | length4 | For write I/O sizes below |
   |                         |   |         | this threshold it is      |
   |                         |   |         | recommended to write data |
   |                         |   |         | through the case for
   persistent filehandles).  In all other cases where the server
   determines that a volatile filehandle can no longer be used, it
   should return MDS           |
   +-------------------------+---+---------+---------------------------+

2.2.28.  mdsthreshold4

   struct mdsthreshold4 {
           threshold_item4 mth_hints<>;
   };

   This structure holds an error array of NFS4ERR_FHEXPIRED.

   The mandatory attribute "fh_expire_type" is used by the client to
   determine what type threshold_item4 structures each of filehandle the server
   which is providing valid for a particular filesystem.  This attribute layout type.  An array is necessary
   since a bitmask with the
   following values:

   FH4_PERSISTENT server can support multiple layout types for a single file.

3.  RPC and Security Flavor

   The value of FH4_PERSISTENT NFS version 4.1 protocol is used to indicate a
      persistent filehandle, which is valid until the object is removed
      from Remote Procedure Call (RPC)
   application that uses RPC version 2 and the filesystem.  The server will not return NFS4ERR_FHEXPIRED
      for this filehandle.  FH4_PERSISTENT is defined corresponding eXternal
   Data Representation (XDR) as a value defined in
      which none of the bits specified below are set.

   FH4_VOLATILE_ANY RFC1831 [4] and RFC4506 [3].
   The filehandle may expire at any time, except RPCSEC_GSS security flavor as
      specifically excluded (i.e.  FH4_NO_EXPIRE_WITH_OPEN).

   FH4_NOEXPIRE_WITH_OPEN  May only defined in RFC2203 [5] MUST be set when FH4_VOLATILE_ANY is set.
      If this bit is set, then used
   as the meaning of FH4_VOLATILE_ANY is
      qualified mechanism to exclude any expiration of deliver stronger security for the filehandle when it is
      open.

   FH4_VOL_MIGRATION NFS version 4
   protocol.

3.1.  Ports and Transports

   Historically, NFS version 2 and version 3 servers have resided on
   port 2049.  The filehandle will expire as a result of a file
      system transition (migration or replication), in those case in
      which registered port 2049 RFC3232 [22] for the continuity of filehandle use is not specified by
      _handle_ class information within NFS
   protocol should be the fs_locations_info attribute.
      When this bit is set, default configuration.  NFSv4 clients without access to fs_locations_info
      information should assume file handles will expire on file system
      transitions.

   FH4_VOL_RENAME  The filehandle will expire during rename.  This
      includes a rename by SHOULD
   NOT use the requesting client or a rename by any
      other client.  If FH4_VOL_ANY is set, FH4_VOL_RENAME is redundant.

   Servers which provide volatile filehandles that may expire while open
   (i.e. if FH4_VOL_MIGRATION or FH4_VOL_RENAME is set or if
   FH4_VOLATILE_ANY is set and FH4_NOEXPIRE_WITH_OPEN not set), should
   deny a RENAME or REMOVE that would affect RPC binding protocols as described in RFC1833 [19].

   Where an OPEN file of any NFS version 4 implementation supports operation over the IP
   network protocol, the supported transports between NFS and IP MUST
   have the following two attributes:

   1.  The transport must support reliable delivery of data in the
   components leading to order
       it was sent.

   2.  The transport must be among the OPEN file.  In addition, IETF-approved congestion control
       transport protocols.

   At the server should
   deny all RENAME or REMOVE requests during time this document was written, the grace period upon
   server restart.

   Servers which provide volatile filehandles only two transports that may expire while open
   require special care as regards handling of RENAMESs and REMOVEs.
   This situation can arise if FH4_VOL_MIGRATION or FH4_VOL_RENAME is
   set, if FH4_VOLATILE_ANY is set
   had the above attributes were TCP and FH4_NOEXPIRE_WITH_OPEN not set,
   or if a non-readonly file system has a transition target in a
   different _handle _ class.  In these cases, SCTP.  To enhance the server should deny a
   RENAME or REMOVE that would affect
   possibilities for interoperability, an OPEN file of any of NFS version 4 implementation
   MUST support operation over the
   components leading to TCP transport protocol.

   If TCP is used as the OPEN file.  In addition, transport, the client and server should
   deny all RENAME or REMOVE requests during the grace period, in order
   to make sure that reclaims of files where filehandles may have
   expired do not do a reclaim SHOULD use
   persistent connections for at least two reasons:

   1.  This will prevent the wrong file.

3.3.  One Method weakening of Constructing a Volatile Filehandle

   A volatile filehandle, while opaque to the client could contain:

   [volatile bit = 1 | server boot time | slot | generation number]
   o  slot is an index in TCP's congestion control via
       short lived connections and will improve performance for the server volatile filehandle table

   o  generation number is WAN
       environment by eliminating the generation number need for the table entry/
      slot

   When SYN handshakes.

   2.  The NFSv4.1 callback model has changed from NFSv4.0, and requires
       the client presents and server to maintain a volatile filehandle, client-created channel for
       the server makes to use.

   As noted in the
   following checks, which assume that Security Considerations section, the check authentication
   model for the volatile bit NFS version 4 has passed.  If the server boot time is less than the current server
   boot time, return NFS4ERR_FHEXPIRED.  If slot is out moved from machine-based to principal-
   based.  However, this modification of range, return
   NFS4ERR_BADHANDLE.  If the generation number authentication model does
   not match, return
   NFS4ERR_FHEXPIRED.

   When the server reboots, imply a technical requirement to move the table is gone (it is volatile).

   If volatile bit is 0, then it is transport connection
   management model from whole machine-based to one based on a persistent filehandle with per user
   model.  In particular, NFS over TCP client implementations have
   traditionally multiplexed traffic for multiple users over a
   different structure following it.

3.4.  Client Recovery from Filehandle Expiration

   If possible, common
   TCP connection between an NFS client and server.  This has been true,
   regardless whether the NFS client SHOULD recover from is using AUTH_SYS, AUTH_DH,
   RPCSEC_GSS or any other flavor.  Similarly, NFS over TCP server
   implementations have assumed such a model and thus scale the receipt
   implementation of an
   NFS4ERR_FHEXPIRED error.  The client must take on additional
   responsibility so that it may prepare itself TCP connection management in proportion to recover from the
   expiration
   number of a volatile filehandle.  If expected client machines.  NFS version 4.1 will not modify
   this connection management model.  NFS version 4.1 clients that
   violate this assumption can expect scaling issues on the server returns
   persistent filehandles, and
   hence reduced service.

   Note that for various timers, the client does not need these additional
   steps. and server should avoid
   inadvertent synchronization of those timers.  For volatile filehandles, most commonly further discussion
   of the client will need general issue refer to store [Floyd].

3.1.1.  Client Retransmission Behavior

   When processing a request received over a reliable transport such as
   TCP, the component names leading up to and including NFS version 4.1 server MUST NOT silently drop the filesystem object
   in question.  With these names, request,
   except if the client should be able to recover
   by finding transport connection has been broken.  Given such a filehandle in the name space that is still available
   contract between NFS version 4.1 clients and servers, clients MUST
   NOT retry a request unless one or
   by starting at the root both of the server's filesystem name space.

   If the expired filehandle refers to an object that following are true:

   o  The transport connection has been removed
   from broken

   o  The procedure being retried is the filesystem, obviously NULL procedure

   Since reliable transports, such as TCP, do not always synchronously
   inform a peer when the other peer has broken the connection (for
   example, when an NFS server reboots), the NFS version 4.1 client will not be able may
   want to recover
   from the expired filehandle.

   It is also possible that actively "probe" the expired filehandle refers connection to a file that see if has been renamed.  If broken.
   Use of the file was renamed by another client, again
   it NULL procedure is possible that the original client will not be able one recommended way to recover.
   However, in the case that the do so.  So, when
   a client itself is renaming the file and experiences a remote procedure call timeout (of some
   arbitrary implementation specific amount), rather than retrying the file is open,
   remote procedure call, it is possible that the client may be able could instead issue a NULL procedure call
   to
   recover.  The client can determine the new path name based on server.  If the
   processing of server has died, the rename request. transport connection
   break will eventually be indicated to the NFS version 4.1 client.
   The client can then regenerate reconnect, and then retry the
   new filehandle based on original request.
   If the new path name. NULL procedure call gets a response, the connection has not
   broken.  The client could also use can decide to wait longer for the compound operation mechanism original
   request's response, or it can break the transport connection and
   reconnect before re-sending the original request.

   For callbacks from the server to construct a set the client, the same rules apply,
   but the server doing the callback becomes the client, and the client
   receiving the callback becomes the server.

3.2.  Security Flavors

   Traditional RPC implementations have included AUTH_NONE, AUTH_SYS,
   AUTH_DH, and AUTH_KRB4 as security flavors.  With RFC2203 [5] an
   additional security flavor of operations
   like:

             RENAME A B
             LOOKUP B
             GETFH

   Note that RPCSEC_GSS has been introduced which
   uses the COMPOUND procedure does not provide atomicity. functionality of GSS-API RFC2743 [8].  This
   example only reduces allows for the overhead
   use of recovering from an expired
   filehandle.

4.  File Attributes

   To meet various security mechanisms by the requirements RPC layer without the
   additional implementation overhead of extensibility adding RPC security flavors.
   For NFS version 4, the RPCSEC_GSS security flavor MUST be implemented
   to enable the mandatory security mechanism.  Other flavors, such as,
   AUTH_NONE, AUTH_SYS, and increased
   interoperability with non-UNIX platforms, attributes must AUTH_DH MAY be handled
   in a flexible manner.  The implemented as well.

3.2.1.  Security mechanisms for NFS version 3 fattr3 structure contains a
   fixed list 4

   The use of attributes that not all clients RPCSEC_GSS requires selection of: mechanism, quality of
   protection, and servers are able service (authentication, integrity, privacy).  The
   remainder of this document will refer to
   support or care about. these three parameters of
   the RPCSEC_GSS security as the security triple.

3.2.1.1.  Kerberos V5

   The fattr3 structure can not Kerberos V5 GSS-API mechanism as described in RFC1964 [6] MUST be extended
   implemented.

    column descriptions:
    1 == number of pseudo flavor
    2 == name of pseudo flavor
    3 == mechanism's OID
    4 == RPCSEC_GSS service

    1      2     3                    4
    --------------------------------------------------------------------
    390003 krb5  1.2.840.113554.1.2.2 rpc_gss_svc_none
    390004 krb5i 1.2.840.113554.1.2.2 rpc_gss_svc_integrity
    390005 krb5p 1.2.840.113554.1.2.2 rpc_gss_svc_privacy

   Note that the pseudo flavor is presented here as
   new needs arise a mapping aid to the
   implementor.  Because this NFS protocol includes a method to
   negotiate security and it provides no way to indicate non-support.  With understands the GSS-API mechanism, the
   pseudo flavor is not needed.  The pseudo flavor is needed for NFS
   version 4 protocol, 3 since the client security negotiation is able query what attributes done via the server supports and construct requests with only those supported
   attributes (or MOUNT
   protocol.

   For a subset thereof).

   To this end, attributes are divided into three groups: mandatory,
   recommended, and named.  Both mandatory discussion of NFS' use of RPCSEC_GSS and recommended attributes
   are supported Kerberos V5, please
   see RFC2623 [23].

3.2.1.2.  LIPKEY as a security triple

   The LIPKEY GSS-API mechanism as described in RFC2847 [7] MUST be
   implemented and provide the NFS version following security triples.  The
   definition of the columns matches the previous subsection "Kerberos
   V5 as security triple"

    1      2        3                   4 protocol by a specific and well-
   defined encoding and are identified by number.  They are requested by
   setting
    --------------------------------------------------------------------
    390006 lipkey   1.3.6.1.5.5.9       rpc_gss_svc_none
    390007 lipkey-i 1.3.6.1.5.5.9       rpc_gss_svc_integrity
    390008 lipkey-p 1.3.6.1.5.5.9       rpc_gss_svc_privacy

3.2.1.3.  SPKM-3 as a bit security triple

   The SPKM-3 GSS-API mechanism as described in RFC2847 [7] MUST be
   implemented and provide the bit vector sent in following security triples.  The
   definition of the GETATTR request; columns matches the previous subsection "Kerberos
   V5 as security triple".

    1      2        3                   5
    --------------------------------------------------------------------
    390009 spkm3    1.3.6.1.5.5.1.3     rpc_gss_svc_none
    390010 spkm3i   1.3.6.1.5.5.1.3     rpc_gss_svc_integrity
    390011 spkm3p   1.3.6.1.5.5.1.3     rpc_gss_svc_privacy

3.3.  Security Negotiation

   With the NFS version 4 server response includes potentially offering multiple security
   mechanisms, the client needs a bit vector method to list what attributes were
   returned in the response.  New mandatory determine or recommended attributes
   may be added negotiate which
   mechanism is to be used for its communication with the server.  The
   NFS protocol between major revisions server may have multiple points within its file system name space
   that are available for use by
   publishing NFS clients.  In turn the NFS server
   may be configured such that each of these entry points may have
   different or multiple security mechanisms in use.

   The security negotiation between client and server must be done with
   a standards-track RFC which allocates secure channel to eliminate the possibility of a new attribute
   number value and defines third party
   intercepting the encoding for negotiation sequence and forcing the attribute. client and
   server to choose a lower level of security than required or desired.
   See the section "Minor Versioning" "Security Considerations" for further discussion.

   Named attributes are accessed by

3.3.1.  SECINFO and SECINFO_NO_NAME

   The SECINFO and SECINFO_NO_NAME operations allow the new OPENATTR operation, which
   accesses a hidden directory of attributes associated with a file
   system object.  OPENATTR takes client to
   determine, on a per filehandle basis, what security triple is to be
   used for server access.  In general, the object and
   returns client will not have to use
   either operation except during initial communication with the filehandle for server
   or when the attribute hierarchy.  The filehandle
   for client crosses policy boundaries at the named attributes server.  It is a directory object accessible by LOOKUP
   or READDIR and contains files whose names represent
   possible that the named
   attributes and whose data bytes are server's policies change during the value of client's
   interaction therefore forcing the attribute.  For
   example:

        +----------+-----------+---------------------------------+
        | LOOKUP   | "foo"     | ; look up file                  |
        | GETATTR  | attrbits  |                                 |
        | OPENATTR |           | ; access foo's named attributes |
        | LOOKUP   | "x11icon" | ; look up specific attribute    |
        | READ     | 0,4096    | ; read stream of bytes          |
        +----------+-----------+---------------------------------+

   Named attributes are intended for data needed by applications rather
   than by an NFS client implementation.  NFS implementors are strongly
   encouraged to define their negotiate a new attributes as recommended attributes
   by bringing them to security
   triple.

3.3.2.  Security Error

   Based on the IETF standards-track process.

   The set of attributes which are classified as mandatory is
   deliberately small since servers assumption that each NFS version 4 client and server
   must do whatever it takes to support
   them.  A a minimum set of security (i.e., LIPKEY, SPKM-3, and
   Kerberos-V5 all under RPCSEC_GSS), the NFS client will start its
   communication with the server should support as many with one of the recommended attributes
   as possible but by their definition, minimal security
   triples.  During communication with the server, the client may
   receive an NFS error of NFS4ERR_WRONGSEC.  This error allows the
   server to notify the client that the security triple currently being
   used is not required appropriate for access to
   support all of them.  Attributes are deemed mandatory if the data server's file system
   resources.  The client is
   both needed by a large number of clients then responsible for determining what
   security triples are available at the server and choose one which is not otherwise
   reasonably computable by
   appropriate for the client when support is not provided on client.  See the server.

   Note that section for the hidden directory returned by OPENATTR is a convenience "SECINFO"
   operation for protocol processing.  The further discussion of how the client should not make any assumptions
   about will respond to
   the server's implementation of named attributes NFS4ERR_WRONGSEC error and whether the
   underlying filesystem at use SECINFO.

3.3.3.  Callback RPC Authentication

   Callback authentication has changed in NFSv4.1 from NFSv4.0.

   NFSv4.0 required the NFS server has to create a named attribute directory
   or not.  Therefore, operations such security context for
   RPCSEC_GSS, AUTH_DH, and AUTH_KERB4, and any other security flavor
   that had a security context.  It also required that principal issuing
   the callback be the same as SETATTR the principal that accepted the callback
   parameters (via SETCLIENTID), and GETATTR on that the
   named attribute directory are undefined.

4.1.  Mandatory Attributes

   These MUST client principal accepting
   the callback be supported by every the same as that which issued the SETCLIENTID.  This
   required the NFS version 4 client and server in
   order to ensure have an assigned machine credential.
   NFSv4.1 does not require a minimum level of interoperability.  The server must
   store and return these attributes machine credential.  Instead, NFSv4.1
   allows an RPCSEC_GSS security context initiated by the client and
   eswtablished on both the client must be able and server to
   function with an attribute set limited be used on callback
   RPCs sent by the server to these attributes.  With
   just the mandatory attributes some client functionality may be
   impaired or limited in some ways.  A client.  The BIND_BACKCHANNEL
   operation is used establish RPCSEC_GSS contexts (if the client may ask so
   desires) on the server.  No support for any AUTH_DH, or AUTH_KERB4 is
   specified.

3.3.4.  GSS Server Principal

   Regardless of these
   attributes to be returned by setting a bit what security mechanism under RPCSEC_GSS is being used,
   the NFS server, MUST identify itself in GSS-API via a
   GSS_C_NT_HOSTBASED_SERVICE name type.  GSS_C_NT_HOSTBASED_SERVICE
   names are of the GETATTR request and form:

   service@hostname

   For NFS, the server must return their value.

4.2.  Recommended Attributes

   These attributes are understood well enough "service" element is

   nfs

   Implementations of security mechanisms will convert nfs@hostname to warrant support
   various different forms.  For Kerberos V5, LIPKEY, and SPKM-3, the
   following form is RECOMMENDED:

   nfs/hostname

4.  Filehandles

   The filehandle in the NFS version 4 protocol.  However, they may not be supported on all
   clients and servers.  A client may ask protocol is a per server unique identifier
   for any of these attributes to
   be returned by setting a bit in file system object.  The contents of the GETATTR request but must handle filehandle are opaque
   to the case where client.  Therefore, the server does not return them.  A client may ask is responsible for translating
   the set filehandle to an internal representation of attributes the server supports and should not request
   attributes file system
   object.

4.1.  Obtaining the server does not support.  A server should be tolerant First Filehandle

   The operations of requests for unsupported attributes and simply not return them
   rather than considering the request an error.  It is expected that
   servers will support all attributes they comfortably can and only
   fail to support attributes which NFS protocol are difficult to support defined in their
   operating environments.  A server should provide attributes whenever
   they don't have terms of one or
   more filehandles.  Therefore, the client needs a filehandle to "tell lies"
   initiate communication with the server.  With the NFS version 2
   protocol RFC1094 [17] and the NFS version 3 protocol RFC1813 [18],
   there exists an ancillary protocol to obtain this first filehandle.
   The MOUNT protocol, RPC program number 100005, provides the client.  For example, mechanism
   of translating a string based file
   modification time should be either an accurate time or should not system path name to a filehandle
   which can then be
   supported used by the server.  This will not always be comfortable to
   clients but NFS protocols.

   The MOUNT protocol has deficiencies in the client area of security and use
   via firewalls.  This is better positioned decide whether one reason that the use of the public
   filehandle was introduced in RFC2054 [24] and how to
   fabricate or construct an attribute or whether to do without RFC2055 [25].  With the
   attribute.

4.3.  Named Attributes

   These attributes are not supported by direct encoding
   use of the public filehandle in combination with the LOOKUP operation
   in the NFS
   Version version 2 and 3 protocols, it has been demonstrated that
   the MOUNT protocol is unnecessary for viable interaction between NFS
   client and server.

   Therefore, the NFS version 4 protocol but are accessed by will not use an ancillary
   protocol for translation from string based path names rather than
   numbers and correspond to an uninterpreted stream a
   filehandle.  Two special filehandles will be used as starting points
   for the NFS client.

4.1.1.  Root Filehandle

   The first of bytes which are
   stored with the filesystem object. special filehandles is the ROOT filehandle.  The
   ROOT filehandle is the "conceptual" root of the file system name
   space for these
   attributes may be accessed at the NFS server.  The client uses or starts with the ROOT
   filehandle by using employing the OPENATTR PUTROOTFH operation.  The
   OPENATTR PUTROOTFH
   operation returns a instructs the server to set the "current" filehandle for a virtual "attribute
   directory" and further perusal to the
   ROOT of the server's file tree.  Once this PUTROOTFH operation is
   used, the client can then traverse the entirety of the server's file
   tree with the LOOKUP operation.  A complete discussion of the server
   name space may be done using
   READDIR and LOOKUP operations on this is in the section "NFS Server Name Space".

4.1.2.  Public Filehandle

   The second special filehandle is the PUBLIC filehandle.  Named attributes  Unlike the
   ROOT filehandle, the PUBLIC filehandle may then be examined bound or changed by normal READ and WRITE and CREATE
   operations on represent an
   arbitrary file system object at the filehandles returned from READDIR and LOOKUP.
   Named attributes may have attributes.

   It server.  The server is recommended
   responsible for this binding.  It may be that servers support arbitrary named attributes.  A
   client should not depend on the ability PUBLIC filehandle
   and the ROOT filehandle refer to store any named attributes
   in the server's filesystem.  If a server does support named
   attributes, a client which same file system object.
   However, it is also able to handle them should be able up to copy a file's data the administrative software at the server and meta-data with complete transparency from
   one location to another; this would imply that names allowed for
   regular directory entries are valid for named attribute names as
   well.

   Names
   the policies of attributes will not be controlled by this document or other
   IETF standards track documents.  See the section "IANA
   Considerations" for further discussion.

4.4.  Classification of Attributes

   Each server administrator to define the binding of the Mandatory
   PUBLIC filehandle and Recommended attributes can be classified in
   one of three categories: per server, per filesystem, or per
   filesystem server file system object.  Note that it is possible that some per filesystem
   attributes  The client may vary within not
   make any assumptions about this binding.  The client uses the filesystem.  See PUBLIC
   filehandle via the "homogeneous"
   attribute for its definition.  Note that PUTPUBFH operation.

4.2.  Filehandle Types

   In the attributes
   time_access_set and time_modify_set are not listed in this section
   because they are write-only attributes corresponding to time_access
   and time_modify, NFS version 2 and are used in 3 protocols, there was one type of
   filehandle with a special instance single set of SETATTR.

   o  The per server attribute is:

         lease_time

   o  The per filesystem attributes are:

         supp_attr, fh_expire_type, link_support, symlink_support,
         unique_handles, aclsupport, cansettime, case_insensitive,
         case_preserving, chown_restricted, files_avail, files_free,
         files_total, fs_locations, homogeneous, maxfilesize, maxname,
         maxread, maxwrite, no_trunc, space_avail, space_free,
         space_total, time_delta, fs_layout_type, send_impl_id,
         recv_impl_id

   o semantics.  This type of filehandle
   is termed "persistent" in NFS Version 4.  The per filesystem object attributes are:

         type, change, size, named_attr, fsid, rdattr_error, filehandle,
         ACL, archive, fileid, hidden, maxlink, mimetype, mode,
         numlinks, owner, owner_group, rawdev, space_used, system,
         time_access, time_backup, time_create, time_metadata,
         time_modify, mounted_on_fileid, layout_type, layout_hint,
         layout_blksize, layout_alignment

   For quota_avail_hard, quota_avail_soft, and quota_used see their
   definitions below for semantics of a
   persistent filehandle remain the appropriate classification.

4.5.  Mandatory Attributes - Definitions

   +-----------------+----+------------+--------+----------------------+
   | name            | #  | Data Type  | Access | Description          |
   +-----------------+----+------------+--------+----------------------+
   | supp_attr       | 0  | bitmap     | READ   | The bit vector same as before.  A new type of
   filehandle introduced in NFS Version 4 is the "volatile" filehandle,
   which |
   |                 |    |            |        | would retrieve all   |
   |                 |    |            |        | mandatory and        |
   |                 |    |            |        | recommended          |
   |                 |    |            |        | attributes that are  |
   |                 |    |            |        | supported for this   |
   |                 |    |            |        | object. attempts to accommodate certain server environments.

   The scope volatile filehandle type was introduced to address server
   functionality or implementation issues which make correct
   implementation of |
   |                 |    |            |        | this attribute       |
   |                 |    |            |        | applies a persistent filehandle infeasible.  Some server
   environments do not provide a file system level invariant that can be
   used to all       |
   |                 |    |            |        | objects with construct a       |
   |                 |    |            |        | matching fsid.       |
   | type            | 1  | nfs4_ftype | READ   | persistent filehandle.  The type of underlying server
   file system may not provide the      |
   |                 |    |            |        | object (file,        |
   |                 |    |            |        | directory, symlink,  |
   |                 |    |            |        | etc.)                |
   | fh_expire_type  | 2  | uint32     | READ   | Server uses this invariant or the server's file system
   programming interfaces may not provide access to  |
   |                 |    |            |        | specify the needed
   invariant.  Volatile filehandles may ease the implementation of
   server functionality such as hierarchical storage management or file
   system reorganization or migration.  However, the volatile filehandle   |
   |                 |    |            |        | expiration behavior  |
   |                 |    |            |        | to
   increases the implementation burden for the client. See   |
   |                 |    |            |        |

   Since the section          |
   |                 |    |            |        | "Filehandles" for    |
   |                 |    |            |        | additional           |
   |                 |    |            |        | description.         |
   | change          | 3  | uint64     | READ   | A value created client will need to handle persistent and volatile
   filehandles differently, a file attribute is defined which may be
   used by   |
   |                 |    |            |        | the client to determine the filehandle types being returned
   by the server.

4.2.1.  General Properties of a Filehandle

   The filehandle contains all the information the server that needs to
   distinguish an individual file.  To the  |
   |                 |    |            |        | client, the filehandle is
   opaque.  The client can stores filehandles for use to    |
   |                 |    |            |        | determine if file    |
   |                 |    |            |        | data, directory      |
   |                 |    |            |        | in a later request and
   can compare two filehandles from the same server for equality by
   doing a byte-by-byte comparison.  However, the client MUST NOT
   otherwise interpret the contents or          |
   |                 |    |            |        | attributes of filehandles.  If two filehandles
   from the    |
   |                 |    |            |        | object have been     |
   |                 |    |            |        | modified. The same server |
   |                 |    |            |        | may return are equal, they MUST refer to the       |
   |                 |    |            |        | object's             |
   |                 |    |            |        | time_metadata        |
   |                 |    |            |        | attribute for this   |
   |                 |    |            |        | attribute's value    |
   |                 |    |            |        | same file.
   Servers SHOULD try to maintain a one-to-one correspondence between
   filehandles and files but this is not required.  Clients MUST use
   filehandle comparisons only if the      |
   |                 |    |            |        | filesystem object    |
   |                 |    |            |        | can to improve performance, not for correct
   behavior.  All clients need to be updated   |
   |                 |    |            |        | more frequently than |
   |                 |    |            |        | prepared for situations in which it
   cannot be determined whether two filehandles denote the resolution same object
   and in such cases, avoid making invalid assumptions which might cause
   incorrect behavior.  Further discussion of    |
   |                 |    |            |        | time_metadata.       |
   | size            | 4  | uint64     | R/W    | The size filehandle and attribute
   comparison in the context of data caching is presented in the      |
   |                 |    |            |        | object section
   "Data Caching and File Identity".

   As an example, in bytes.     |
   | link_support    | 5  | bool       | READ   | True, if the         |
   |                 |    |            |        | object's filesystem  |
   |                 |    |            |        | supports hard links. |
   | symlink_support | 6  | bool       | READ   | True, case that two different path names when
   traversed at the server terminate at the same file system object, the
   server SHOULD return the same filehandle for each path.  This can
   occur if a hard link is used to create two file names which refer to
   the         |
   |                 |    |            |        | object's filesystem  |
   |                 |    |            |        | supports symbolic    |
   |                 |    |            |        | links.               |
   | named_attr      | 7  | bool       | READ   | True, if this object |
   |                 |    |            |        | has named            |
   |                 |    |            |        | attributes. In other |
   |                 |    |            |        | words, same underlying file object has a  |
   |                 |    |            |        | non-empty named      |
   |                 |    |            |        | attribute directory. |
   | fsid            | 8  | fsid4      | READ   | Unique filesystem    |
   |                 |    |            |        | identifier for the   |
   |                 |    |            |        | filesystem holding   |
   |                 |    |            |        | this object. fsid    |
   |                 |    |            |        | contains major and   |
   |                 |    |            |        | minor components     |
   |                 |    |            |        | each of which are    |
   |                 |    |            |        | uint64.              |
   | unique_handles  | 9  | bool       | READ   | True, associated data.  For example, if two         |
   |                 |    |            |        | distinct filehandles |
   |                 |    |            |        | guaranteed to
   paths /a/b/c and /a/d/c refer  |
   |                 |    |            |        | to two different     |
   |                 |    |            |        | filesystem objects.  |
   | lease_time      | 10 | nfs_lease4 | READ   | Duration of leases   |
   |                 |    |            |        | at the same file, the server in         |
   |                 |    |            |        | seconds.             |
   | rdattr_error    | 11 | enum       | READ   | Error returned from  |
   |                 |    |            |        | getattr during       |
   |                 |    |            |        | readdir.             |
   | filehandle      | 19 | nfs_fh4    | READ   | The SHOULD
   return the same filehandle of    |
   |                 |    |            |        | this object          |
   |                 |    |            |        | (primarily for       |
   |                 |    |            |        | readdir requests).   |
   +-----------------+----+------------+--------+----------------------+

4.6.  Recommended Attributes - Definitions

   +--------------------+----+--------------+--------+-----------------+
   | name               | #  | Data Type    | Access | Description     |
   +--------------------+----+--------------+--------+-----------------+
   | ACL                | 12 | nfsace4<>    | R/W    | The access      |
   |                    |    |              |        | control list    |
   |                    |    |              |        | both path names traversals.

4.2.2.  Persistent Filehandle

   A persistent filehandle is defined as having a fixed value for the object. |
   | aclsupport         | 13 | uint32       | READ   | Indicates what  |
   |                    |    |              |        | types
   lifetime of ACLs   |
   |                    |    |              |        | are supported   |
   |                    |    |              |        | on the current  |
   |                    |    |              |        | filesystem.     |
   | archive            | 14 | bool         | R/W    | True, if this   |
   |                    |    |              |        | file has been   |
   |                    |    |              |        | archived since  |
   |                    |    |              |        | the time of     |
   |                    |    |              |        | last            |
   |                    |    |              |        | modification    |
   |                    |    |              |        | (deprecated in  |
   |                    |    |              |        | favor of        |
   |                    |    |              |        | time_backup).   |
   | cansettime         | 15 | bool         | READ   | True, if system object to which it refers.  Once the    |
   |                    |    |              |        |
   server able to  |
   |                    |    |              |        | change creates the      |
   |                    |    |              |        | times filehandle for a     |
   |                    |    |              |        | filesystem      |
   |                    |    |              |        | file system object, the server
   MUST accept the same filehandle for the object for the lifetime of
   the object.  If the server restarts or reboots the NFS server must
   honor the same filehandle value as       |
   |                    |    |              |        | specified it did in a  |
   |                    |    |              |        | SETATTR         |
   |                    |    |              |        | operation.      |
   | case_insensitive   | 16 | bool         | READ   | True, if        |
   |                    |    |              |        | filename        |
   |                    |    |              |        | comparisons on  |
   |                    |    |              |        | this filesystem |
   |                    |    |              |        | are case        |
   |                    |    |              |        | insensitive.    |
   | case_preserving    | 17 | bool         | READ   | True, the server's previous
   instantiation.  Similarly, if        |
   |                    |    |              |        | filename case   |
   |                    |    |              |        | on this         |
   |                    |    |              |        | filesystem are  |
   |                    |    |              |        | preserved.      |
   | chown_restricted   | 18 | bool         | READ   | If TRUE, the    |
   |                    |    |              |        | file system is migrated, the new
   NFS server will     |
   |                    |    |              |        | reject any      |
   |                    |    |              |        | request to      |
   |                    |    |              |        | change either   |
   |                    |    |              |        | must honor the owner same filehandle as the old NFS server.

   The persistent filehandle will be become stale or    |
   |                    |    |              |        | invalid when the group       |
   |                    |    |              |        | associated
   file system object is removed.  When the server is presented with |
   |                    |    |              |        | a
   persistent filehandle that refers to a deleted object, it MUST return
   an error of NFS4ERR_STALE.  A filehandle may become stale when the
   file system containing the object is no longer available.  The file
   system may become unavailable if it exists on removable media and the   |
   |                    |    |              |        | caller
   media is not a |
   |                    |    |              |        | privileged user |
   |                    |    |              |        | (for example,   |
   |                    |    |              |        | "root" in UNIX  |
   |                    |    |              |        | operating       |
   |                    |    |              |        | environments no longer available at the server or |
   |                    |    |              |        | in Windows 2000 |
   |                    |    |              |        | the "Take       |
   |                    |    |              |        | Ownership"      |
   |                    |    |              |        | privilege).     |
   | dir_notif_delay    | 56 | nfstime4     | READ   | notification    |
   |                    |    |              |        | delays on       |
   |                    |    |              |        | directory       |
   |                    |    |              |        | attributes      |
   | dirent_notif_delay | 57 | nfstime4     | READ   | notification    |
   |                    |    |              |        | delays on child |
   |                    |    |              |        | attributes      |
   | fileid             | 20 | uint64       | READ   | A number        |
   |                    |    |              |        | uniquely        |
   |                    |    |              |        | identifying file system in
   whole has been destroyed or the |
   |                    |    |              |        | file within system has simply been removed
   from the |
   |                    |    |              |        | filesystem.     |
   | files_avail        | 21 | uint64       | READ   | File slots      |
   |                    |    |              |        | available to    |
   |                    |    |              |        | this user on    |
   |                    |    |              |        | server's name space (i.e. unmounted in a UNIX environment).

4.2.3.  Volatile Filehandle

   A volatile filehandle does not share the filesystem  |
   |                    |    |              |        | containing this |
   |                    |    |              |        | same longevity
   characteristics of a persistent filehandle.  The server may determine
   that a volatile filehandle is no longer valid at many different
   points in time.  If the server can definitively determine that a
   volatile filehandle refers to an object - this   |
   |                    |    |              |        | that has been removed, the
   server should return NFS4ERR_STALE to the client (as is the case for
   persistent filehandles).  In all other cases where the server
   determines that a volatile filehandle can no longer be used, it
   should return an error of NFS4ERR_FHEXPIRED.

   The mandatory attribute "fh_expire_type" is used by the   |
   |                    |    |              |        | smallest        |
   |                    |    |              |        | relevant limit. |
   | files_free         | 22 | uint64       | READ   | Free client to
   determine what type of filehandle the server is providing for a
   particular file slots |
   |                    |    |              |        | on system.  This attribute is a bitmask with the
   following values:

   FH4_PERSISTENT  The value of FH4_PERSISTENT is used to indicate a
      persistent filehandle, which is valid until the          |
   |                    |    |              |        | filesystem      |
   |                    |    |              |        | containing this |
   |                    |    |              |        | object - this   |
   |                    |    |              |        | should be is removed
      from the   |
   |                    |    |              |        | smallest        |
   |                    |    |              |        | relevant limit. |
   | files_total        | 23 | uint64       | READ   | Total file      |
   |                    |    |              |        | slots on the    |
   |                    |    |              |        | filesystem      |
   |                    |    |              |        | containing this |
   |                    |    |              |        | object.         |
   | fs_absent          | 60 | bool         | READ   | Is current      |
   |                    |    |              |        | filesystem      |
   |                    |    |              |        | present or      |
   |                    |    |              |        | absent.         |
   | fs_layout_type     | 62 | layouttype4  | READ   | Layout types    |
   |                    |    |              |        | available system.  The server will not return
      NFS4ERR_FHEXPIRED for   |
   |                    |    |              |        | the filesystem. |
   | fs_locations       | 24 | fs_locations | READ   | Locations where |
   |                    |    |              |        | this filesystem |
   |                    |    |              |        | filehandle.  FH4_PERSISTENT is defined
      as a value in which none of the bits specified below are set.

   FH4_VOLATILE_ANY  The filehandle may expire at any time, except as
      specifically excluded (i.e.  FH4_NO_EXPIRE_WITH_OPEN).

   FH4_NOEXPIRE_WITH_OPEN  May only be found.   |
   |                    |    |              |        | set when FH4_VOLATILE_ANY is set.
      If this bit is set, then the server   |
   |                    |    |              |        | returns         |
   |                    |    |              |        | NFS4ERR_MOVED   |
   |                    |    |              |        | meaning of FH4_VOLATILE_ANY is
      qualified to exclude any expiration of the filehandle when it is
      open.

   FH4_VOL_MIGRATION  The filehandle will expire as an error,    |
   |                    |    |              |        | a result of a file
      system transition (migration or replication), in those case in
      which the continuity of filehandle use is not specified by
      _handle_ class information within the fs_locations_info attribute.
      When this attribute  |
   |                    |    |              |        | MUST be         |
   |                    |    |              |        | supported.      |
   | bit is set, clients without access to fs_locations_info  | 67 |              | READ   | Full function   |
   |                    |    |              |        | filesystem      |
   |                    |    |              |        | location.       |
   | fs_status          | 61 | fs4_status   | READ   | Generic         |
   |                    |    |              |        | filesystem type |
   |                    |    |              |        | information.    |
   | hidden             | 25 | bool         | R/W    | True, if the    |
   |                    |    |              |        |
      information should assume filehandles will expire on file system
      transitions.

   FH4_VOL_RENAME  The filehandle will expire during rename.  This
      includes a rename by the requesting client or a rename by any
      other client.  If FH4_VOL_ANY is         |
   |                    |    |              |        | considered      |
   |                    |    |              |        | hidden with     |
   |                    |    |              |        | respect set, FH4_VOL_RENAME is redundant.

   Servers which provide volatile filehandles that may expire while open
   (i.e. if FH4_VOL_MIGRATION or FH4_VOL_RENAME is set or if
   FH4_VOLATILE_ANY is set and FH4_NOEXPIRE_WITH_OPEN not set), should
   deny a RENAME or REMOVE that would affect an OPEN file of any of the
   components leading to the  |
   |                    |    |              |        | Windows API?    |
   | homogeneous        | 26 | bool         | READ   | True, OPEN file.  In addition, the server should
   deny all RENAME or REMOVE requests during the grace period upon
   server restart.

   Servers which provide volatile filehandles that may expire while open
   require special care as regards handling of RENAMESs and REMOVEs.
   This situation can arise if this   |
   |                    |    |              |        | object's        |
   |                    |    |              |        | filesystem FH4_VOL_MIGRATION or FH4_VOL_RENAME is   |
   |                    |    |              |        | homogeneous,    |
   |                    |    |              |        | i.e. are per    |
   |                    |    |              |        | filesystem      |
   |                    |    |              |        | attributes
   set, if FH4_VOLATILE_ANY is set and FH4_NOEXPIRE_WITH_OPEN not set,
   or if a non-readonly file system has a transition target in a
   different _handle _ class.  In these cases, the  |
   |                    |    |              |        | same for server should deny a
   RENAME or REMOVE that would affect an OPEN file of any of the
   components leading to the OPEN file.  In addition, the server should
   deny all    |
   |                    |    |              |        | filesystem's    |
   |                    |    |              |        | objects.        |
   | layout_alignment   | 66 | uint32_t     | READ   | Preferred       |
   |                    |    |              |        | alignment RENAME or REMOVE requests during the grace period, in order
   to make sure that reclaims of files where filehandles may have
   expired do not do a reclaim for the wrong file.

4.3.  One Method of Constructing a Volatile Filehandle

   A volatile filehandle, while opaque to the client could contain:

   [volatile bit = 1 | server boot time | slot |    |              |        | layout related  |
   |                    |    |              |        | I/O.            |
   | layout_blksize     | 65 | uint32_t     | READ   | Preferred block |
   |                    |    |              |        | size generation number]

   o  slot is an index in the server volatile filehandle table

   o  generation number is the generation number for layout |
   |                    |    |              |        | related I/O.    |
   | layout_hint        | 63 | layouthint4  | WRITE  | Client          |
   |                    |    |              |        | specified hint  |
   |                    |    |              |        | the table entry/
      slot

   When the client presents a volatile filehandle, the server makes the
   following checks, which assume that the check for the volatile bit
   has passed.  If the server boot time is less than the current server
   boot time, return NFS4ERR_FHEXPIRED.  If slot is out of range, return
   NFS4ERR_BADHANDLE.  If the generation number does not match, return
   NFS4ERR_FHEXPIRED.

   When the server reboots, the table is gone (it is volatile).

   If volatile bit is 0, then it is a persistent filehandle with a
   different structure following it.

4.4.  Client Recovery from Filehandle Expiration

   If possible, the client SHOULD recover from the receipt of an
   NFS4ERR_FHEXPIRED error.  The client must take on additional
   responsibility so that it may prepare itself to recover from the
   expiration of a volatile filehandle.  If the server returns
   persistent filehandles, the client does not need these additional
   steps.

   For volatile filehandles, most commonly the client will need to store
   the component names leading up to and including the file        |
   |                    |    |              |        | layout.         |
   | layout_type        | 64 | layouttype4  | READ   | Layout types    |
   |                    |    |              |        | system
   object in question.  With these names, the client should be able to
   recover by finding a filehandle in the name space that is still
   available for   |
   |                    |    |              |        | or by starting at the file.       |
   | maxfilesize        | 27 | uint64       | READ   | Maximum         |
   |                    |    |              |        | supported root of the server's file  |
   |                    |    |              |        | size for system name
   space.

   If the    |
   |                    |    |              |        | filesystem expired filehandle refers to an object that has been removed
   from the file system, obviously the client will not be able to
   recover from the expired filehandle.

   It is also possible that the expired filehandle refers to a file that
   has been renamed.  If the file was renamed by another client, again
   it is possible that the original client will not be able to recover.

   However, in the case that the client itself is renaming the file and
   the file is open, it is possible that the client may be able to
   recover.  The client can determine the new path name based on the
   processing of   |
   |                    |    |              |        | this object.    |
   | maxlink            | 28 | uint32       | READ   | Maximum number  |
   |                    |    |              |        | the rename request.  The client can then regenerate the
   new filehandle based on the new path name.  The client could also use
   the compound operation mechanism to construct a set of links for    |
   |                    |    |              |        | this object.    |
   | maxname            | 29 | uint32       | READ   | Maximum         |
   |                    |    |              |        | filename size   |
   |                    |    |              |        | operations
   like:

             RENAME A B
             LOOKUP B
             GETFH

   Note that the COMPOUND procedure does not provide atomicity.  This
   example only reduces the overhead of recovering from an expired
   filehandle.

5.  File Attributes

   To meet the requirements of extensibility and increased
   interoperability with non-UNIX platforms, attributes must be handled
   in a flexible manner.  The NFS version 3 fattr3 structure contains a
   fixed list of attributes that not all clients and servers are able to
   support or care about.  The fattr3 structure can not be extended as
   new needs arise and it provides no way to indicate non-support.  With
   the NFS version 4 protocol, the client is able query what attributes
   the server supports and construct requests with only those supported for   |
   |                    |    |              |        |
   attributes (or a subset thereof).

   To this object.    |
   | maxread            | 30 | uint64       | READ   | Maximum read    |
   |                    |    |              |        | size end, attributes are divided into three groups: mandatory,
   recommended, and named.  Both mandatory and recommended attributes
   are supported  |
   |                    |    |              |        | in the NFS version 4 protocol by a specific and well-
   defined encoding and are identified by number.  They are requested by
   setting a bit in the bit vector sent in the GETATTR request; the
   server response includes a bit vector to list what attributes were
   returned in the response.  New mandatory or recommended attributes
   may be added to the NFS protocol between major revisions by
   publishing a standards-track RFC which allocates a new attribute
   number value and defines the encoding for this        |
   |                    |    |              |        | object.         |
   | maxwrite           | 31 | uint64       | READ   | Maximum write   |
   |                    |    |              |        | size supported  |
   |                    |    |              |        | the attribute.  See the
   section "Minor Versioning" for this        |
   |                    |    |              |        | further discussion.

   Named attributes are accessed by the new OPENATTR operation, which
   accesses a hidden directory of attributes associated with a file
   system object. This    |
   |                    |    |              |        |  OPENATTR takes a filehandle for the object and
   returns the filehandle for the attribute       |
   |                    |    |              |        | SHOULD be       |
   |                    |    |              |        | supported if    |
   |                    |    |              |        | hierarchy.  The filehandle
   for the file named attributes is a directory object accessible by LOOKUP
   or READDIR and contains files whose names represent the named
   attributes and whose data bytes are the value of the attribute.  For
   example:

        +----------+-----------+---------------------------------+
        | LOOKUP   | "foo"     | ; look up file                  |
        | GETATTR  | writable. Lack  |
   |                    | attrbits  |                                 |
        | of this OPENATTR |           | ; access foo's named attributes |
        | LOOKUP   | "x11icon" | ; look up specific attribute can   |    |
        | READ     | 0,4096    | ; read stream of bytes          | lead
        +----------+-----------+---------------------------------+

   Named attributes are intended for data needed by applications rather
   than by an NFS client implementation.  NFS implementors are strongly
   encouraged to define their new attributes as recommended attributes
   by bringing them to the     |
   |                    |    |              |        | client either   |
   |                    |    |              |        | wasting         |
   |                    |    |              |        | bandwidth IETF standards-track process.

   The set of attributes which are classified as mandatory is
   deliberately small since servers must do whatever it takes to support
   them.  A server should support as many of the recommended attributes
   as possible but by their definition, the server is not required to
   support all of them.  Attributes are deemed mandatory if the data is
   both needed by a large number of clients and is not otherwise
   reasonably computable by the client when support is not provided on
   the server.

   Note that the hidden directory returned by OPENATTR is a convenience
   for protocol processing.  The client should not make any assumptions
   about the server's implementation of named attributes and whether the
   underlying file system at the server has a named attribute directory
   or not.  Therefore, operations such as SETATTR and GETATTR on the
   named attribute directory are undefined.

5.1.  Mandatory Attributes

   These MUST be supported by every NFS version 4 client and server in
   order to ensure a minimum level of interoperability.  The server must
   store and return these attributes and the client must be able to
   function with an attribute set limited to these attributes.  With
   just the mandatory attributes some client functionality may be
   impaired or limited in some ways.  A client may ask for any of these
   attributes to be returned by setting a bit in the GETATTR request and
   the server must return their value.

5.2.  Recommended Attributes

   These attributes are understood well enough to warrant support in the
   NFS version 4 protocol.  However, they may not be supported on all
   clients and servers.  A client may ask for any of these attributes to
   be returned by setting a bit in the GETATTR request but must handle
   the case where the server does not return them.  A client may ask for
   the set of attributes the server supports and should not request
   attributes the server does not support.  A server should be tolerant
   of requests for unsupported attributes and simply not return them
   rather than considering the request an error.  It is expected that
   servers will support all attributes they comfortably can and only
   fail to support attributes which are difficult to support in their
   operating environments.  A server should provide attributes whenever
   they don't have to "tell lies" to the client.  For example, a file
   modification time should be either an accurate time or should not be
   supported by the server.  This will not always be comfortable to
   clients but the client is better positioned decide whether and how to
   fabricate or construct an attribute or whether to do without the
   attribute.

5.3.  Named Attributes

   These attributes are not supported by direct encoding in the NFS
   Version 4 protocol but are accessed by string names rather than
   numbers and correspond to an uninterpreted stream of bytes which are
   stored with the file system object.  The name space for these
   attributes may be accessed by using the OPENATTR operation.  The
   OPENATTR operation returns a filehandle for a virtual "attribute
   directory" and further perusal of the name space may be done using
   READDIR and LOOKUP operations on this filehandle.  Named attributes
   may then be examined or changed by normal READ and WRITE and CREATE
   operations on the filehandles returned from READDIR and LOOKUP.
   Named attributes may have attributes.

   It is recommended that servers support arbitrary named attributes.  A
   client should not depend on the ability to store any named attributes
   in the server's file system.  If a server does support named
   attributes, a client which is also able to handle them should be able
   to copy a file's data and meta-data with complete transparency from
   one location to another; this would imply that names allowed for
   regular directory entries are valid for named attribute names as
   well.

   Names of attributes will not be controlled by this document or other
   IETF standards track documents.  See the section "IANA
   Considerations" for further discussion.

5.4.  Classification of Attributes

   Each of the Mandatory and Recommended attributes can be classified in
   one of three categories: per server, per file system, or per file
   system object.  Note that it is possible that some per file system
   attributes may vary within the file system.  See the "homogeneous"
   attribute for its definition.  Note that the attributes
   time_access_set and time_modify_set are not listed in this section
   because they are write-only attributes corresponding to time_access
   and time_modify, and are used in a special instance of SETATTR.

   o  The per server attribute is:

         lease_time

   o  The per file system attributes are:

         supp_attr, fh_expire_type, link_support, symlink_support,
         unique_handles, aclsupport, cansettime, case_insensitive,
         case_preserving, chown_restricted, files_avail, files_free,
         files_total, fs_locations, homogeneous, maxfilesize, maxname,
         maxread, maxwrite, no_trunc, space_avail, space_free,
         space_total, time_delta, fs_layout_type, send_impl_id,
         recv_impl_id

   o  The per file system object attributes are:

         type, change, size, named_attr, fsid, rdattr_error, filehandle,
         ACL, archive, fileid, hidden, maxlink, mimetype, mode,
         numlinks, owner, owner_group, rawdev, space_used, system,
         time_access, time_backup, time_create, time_metadata,
         time_modify, mounted_on_fileid, layout_type, layout_hint,
         layout_blksize, layout_alignment

   For quota_avail_hard, quota_avail_soft, and quota_used see their
   definitions below for the appropriate classification.

5.5.  Mandatory Attributes - Definitions

   +-----------------+----+------------+--------+----------------------+
   | name            | #  | Data Type  | Access | Description          | not receiving   |
   +-----------------+----+------------+--------+----------------------+
   | supp_attr       | 0  | bitmap     | READ   | the best The bit vector which |
   |                 |    |            |        | performance. would retrieve all   |
   | mimetype                 | 32    | utf8<>            | R/W        | MIME body mandatory and        |
   |                 |    |            |        | type/subtype of recommended          |
   |                 |    |            |        | this object. attributes that are  |
   | mode                 | 33    | mode4            | R/W        | UNIX-style mode supported for this   |
   |                 |    |            |        | and permission object. The scope of |
   |                 |    |            |        | bits for this attribute       |
   |                 |    |            |        | object. applies to all       |
   | mounted_on_fileid                 | 55    | uint64            | READ        | Like fileid, objects with a       |
   |                 |    |            |        | but if the matching fsid.       |
   | type            | 1  | nfs4_ftype | READ   | target The type of the      |
   |                 |    |            |        | filehandle is object (file,        |
   |                 |    |            |        | the root of a directory, symlink,  |
   |                 |    |            |        | filesystem etc.)                |
   | fh_expire_type  | 2  | uint32     | READ   | return the Server uses this to  |
   |                 |    |            |        | fileid of the specify filehandle   |
   |                 |    |            |        | underlying expiration behavior  |
   |                 |    |            |        | directory. to the client. See   |
   | no_trunc                 | 34    | bool            | READ        | True, if a name the section          |
   |                 |    |            |        | longer than "Filehandles" for    |
   |                 |    |            |        | name_max is additional           |
   |                 |    |            |        | used, an error description.         |
   | change          | 3  | uint64     | READ   | be returned and A value created by   |
   |                 |    |            |        | name is not the server that the  |
   |                 |    |            |        | truncated. client can use to    |
   | numlinks                 | 35    | uint32            | READ        | Number of hard determine if file    |
   |                 |    |            |        | links to this data, directory      |
   |                 |    |            |        | object. contents or          |
   | owner                 | 36    | utf8<>            | R/W        | The string name attributes of the    |
   |                 |    |            |        | of object have been     |
   |                 |    |            |        | modified. The server |
   |                 |    |            |        | may return the owner of       |
   |                 |    |            |        | object's             |
   |                 |    |            |        | time_metadata        |
   |                 |    |            |        | attribute for this object.   |
   | owner_group                 | 37    | utf8<>            | R/W        | The string name attribute's value    |
   |                 |    |            |        | of but only if the group file |
   |                 |    |            |        | ownership of system object can    |
   |                 |    |            |        | this object. not be updated more  |
   | quota_avail_hard                 | 38    | uint64            | READ        | For definition frequently than the  |
   |                 |    |            |        | see "Quota resolution of        |
   |                 |    |            |        | Attributes" time_metadata.       |
   | size            | 4  | uint64     | R/W    | section below. The size of the      |
   | quota_avail_soft                 | 39    | uint64            | READ        | For definition object in bytes.     |
   | link_support    | 5  | bool       | READ   | see "Quota True, if the         |
   |                 |    |            |        | Attributes" object's file system |
   |                 |    |            |        | section below. supports hard links. |
   | quota_used symlink_support | 40 6  | uint64 bool       | READ   | For definition True, if the         |
   |                 |    |            |        | see "Quota object's file system |
   |                 |    |            |        | Attributes" supports symbolic    |
   |                 |    |            |        | section below. links.               |
   | rawdev named_attr      | 41 7  | specdata4 bool       | READ   | Raw device True, if this object |
   |                 |    |            |        | identifier. has named            |
   |                 |    |            |        | UNIX device attributes. In other |
   |                 |    |            |        | major/minor words, object has a  |
   |                 |    |            |        | node non-empty named      |
   |                 |    |            |        | information. If attribute directory. |
   | fsid            | 8  | fsid4      | READ   | the value of Unique file system   |
   |                 |    |            |        | type is not identifier for the   |
   |                 |    |            |        | NF4BLK or file system holding  |
   |                 |    |            |        | NF4CHR, the this object. fsid    |
   |                 |    |            |        | value return contains major and   |
   |                 |    |            |        | SHOULD NOT be minor components     |
   |                 |    |            |        | considered each of which are    |
   |                 |    |            |        | useful. uint64.              |
   | recv_impl_id unique_handles  | 59 9  | nfs_impl_id4 bool       | READ   | Client obtains True, if two         |
   |                 |    |            |        | server distinct filehandles |
   |                 |    |            |        | implementation guaranteed to refer  |
   |                 |    |            |        | via GETATTR. to two different     |
   | send_impl_id                 | 58    | impl_ident4            | WRITE        | Client provides file system objects. |
   | lease_time      | 10 | nfs_lease4 | READ   | Duration of leases   |
   |                 |    |            |        | at server with in         |
   |                 |    |            |        | implementation seconds.             |
   | rdattr_error    | 11 | enum       | READ   | identity via Error returned from  |
   |                 |    |            |        | SETATTR. getattr during       |
   | space_avail                 | 42    | uint64            | READ        | Disk space in readdir.             |
   | filehandle      | 19 | nfs_fh4    | READ   | bytes available The filehandle of    |
   |                 |    |            |        | to this user on object          |
   |                 |    |            |        | the filesystem (primarily for       |
   |                 |    |            |        | containing this readdir requests).   |
   +-----------------+----+------------+--------+----------------------+

5.6.  Recommended Attributes - Definitions
   +--------------------+----+---------------+--------+----------------+
   | name               | #  | Data Type     | Access | object - this Description    |
   +--------------------+----+---------------+--------+----------------+
   | ACL                | 12 | nfsace4<>     | R/W    | should be the The access     |
   |                    |    |               |        | smallest control list   |
   |                    |    |               |        | relevant limit. for the        |
   | space_free                    | 43    | uint64               |        | object.        |
   | aclsupport         | 13 | uint32        | READ   | Free disk space Indicates what |
   |                    |    |               |        | types of ACLs  |
   |                    |    |               |        | are supported  |
   |                    |    |               |        | in bytes on the current |
   |                    |    |               |        | filesystem file system.   |
   | archive            | 14 | bool          | R/W    | containing True, if this  |
   |                    |    |               |        | object - this file has been  |
   |                    |    |               |        | should be the archived since |
   |                    |    |               |        | smallest the time of    |
   |                    |    |               |        | relevant limit. last           |
   | space_total                    | 44    | uint64               | READ        | Total disk modification   |
   |                    |    |               |        | space (deprecated in bytes |
   |                    |    |               |        | on favor of       |
   |                    |    |               |        | time_backup).  |
   | cansettime         | 15 | bool          | READ   | True, if the   |
   |                    |    |               |        | filesystem server able to |
   |                    |    |               |        | containing this change the     |
   |                    |    |               |        | object. times for a    |
   | space_used                    | 45    | uint64               | READ        | Number of file system    |
   |                    |    |               |        | filesystem object as      |
   |                    |    |               |        | bytes allocated specified in a |
   |                    |    |               |        | to this object. SETATTR        |
   | system                    | 46    |               |        | operation.     |
   | case_insensitive   | 16 | bool          | R/W READ   | True, if this       |
   |                    |    |               |        | file is a filename       |
   |                    |    |               |        | "system" comparisons on |
   |                    |    |               |        | this file      |
   |                    |    |               |        | with respect to system are     |
   |                    |    |               |        | the Windows case           |
   |                    |    |               |        | API? insensitive.   |
   | time_access case_preserving    | 47 17 | nfstime4 bool          | READ   | The time of True, if       |
   |                    |    |               |        | last access to filename case  |
   |                    |    |               |        | the object by a on this file   |
   |                    |    |               |        | read that was system are     |
   |                    |    |               |        | satisfied by preserved.     |
   | chown_restricted   | 18 | bool          | READ   | If TRUE, the server.   |
   | time_access_set                    | 48    | settime4               | WRITE        | Set the time of server will    |
   |                    |    |               |        | last access reject any     |
   |                    |    |               |        | request to     |
   |                    |    |               |        | the object. change either  |
   |                    |    |               |        | SETATTR use the owner or   |
   |                    |    |               |        | only. the group      |
   | time_backup                    | 49    | nfstime4               | R/W        | The time of associated     |
   |                    |    |               |        | last backup of with a file if |
   |                    |    |               |        | the object. caller is  |
   | time_create                    | 50    | nfstime4               | R/W        | The time of not a          |
   |                    |    |               |        | creation of the privileged     |
   |                    |    |               |        | object. This user (for      |
   |                    |    |               |        | attribute does example,       |
   |                    |    |               |        | not have any "root" in UNIX |
   |                    |    |               |        | relation to the operating      |
   |                    |    |               |        | traditional environments   |
   |                    |    |               |        | UNIX file or in Windows  |
   |                    |    |               |        | attribute 2000 the "Take |
   |                    |    |               |        | "ctime" or Ownership"     |
   |                    |    |               |        | "change time". privilege).    |
   | time_delta dir_notif_delay    | 51 56 | nfstime4      | READ   | Smallest useful notification   |
   |                    |    |               |        | server time delays on      |
   |                    |    |               |        | granularity. directory      |
   | time_metadata                    | 52    |               |        | attributes     |
   | dirent_notif_delay | 57 | nfstime4      | READ   | The time of notification   |
   |                    |    |               |        | last meta-data delays on      |
   |                    |    |               |        | modification of child          |
   |                    |    |               |        | the object. attributes     |
   | time_modify fileid             | 53 20 | nfstime4 uint64        | READ   | The time of A number       |
   |                    |    |               |        | last uniquely       |
   |                    |    |               |        | modification to identifying    |
   |                    |    |               |        | the object. file       |
   | time_modify_set                    | 54    | settime4               | WRITE        | Set within the time of     |
   |                    |    |               |        | last file system.   |
   | files_avail        | 21 | uint64        | READ   | File slots     |
   |                    |    |               | modification        | available to   |
   |                    |    |               |        | this user on   |
   |                    |    |               |        | the object. file       |
   |                    |    |               |        | SETATTR use system         |
   |                    |    |               |        | only. containing     |
   +--------------------+----+--------------+--------+-----------------+

4.7.  Time Access

   As defined above, the time_access attribute represents the time of
   last access to the
   |                    |    |               |        | this object by a read that was satisfied by the server.
   The notion of what is an "access" depends on server's operating
   environment and/or the server's filesystem semantics.  For example,
   for servers obeying POSIX semantics, time_access would -  |
   |                    |    |               |        | this should be updated
   only by the READLINK, READ, and READDIR operations and not any of the
   operations that modify the content of the object.  Of course, setting
   the corresponding time_access_set attribute is another way to modify
   the time_access attribute.

   Whenever |
   |                    |    |               |        | the smallest   |
   |                    |    |               |        | relevant       |
   |                    |    |               |        | limit.         |
   | files_free         | 22 | uint64        | READ   | Free file object resides      |
   |                    |    |               |        | slots on a writable filesystem, the server   |
   |                    |    |               |        | file system    |
   |                    |    |               |        | containing     |
   |                    |    |               |        | this object -  |
   |                    |    |               |        | this should make best efforts to record time_access into stable storage.
   However, to mitigate the performance effects of doing so, and most
   especially whenever the server is satisfying the read of the object's
   content from its cache, the server MAY cache access time updates and
   lazily write them to stable storage.  It is also acceptable to give
   administrators of be |
   |                    |    |               |        | the server smallest   |
   |                    |    |               |        | relevant       |
   |                    |    |               |        | limit.         |
   | files_total        | 23 | uint64        | READ   | Total file     |
   |                    |    |               |        | slots on the option to disable time_access
   updates.

4.8.  Interpreting owner and owner_group

   The recommended attributes "owner" and "owner_group" (and also users
   and groups within the "acl" attribute) are represented in terms of a
   UTF-8 string.  To avoid a representation that is tied to a particular
   underlying implementation at the client or server, the use of the
   UTF-8 string has been chosen.  Note that section 6.1 of [RFC2624]
   provides additional rationale.  It is expected that the client and
   server will have their own local representation of owner and
   owner_group that is used for local storage   |
   |                    |    |               |        | file system    |
   |                    |    |               |        | containing     |
   |                    |    |               |        | this object.   |
   | fs_absent          | 60 | bool          | READ   | Is current     |
   |                    |    |               |        | file system    |
   |                    |    |               |        | present or presentation to the end
   user.  Therefore, it is expected that when these attributes are
   transferred between the client and server that the local
   representation is translated to a syntax of the form "user@
   dns_domain".  This will allow     |
   |                    |    |               |        | absent.        |
   | fs_layout_type     | 62 | layouttype4   | READ   | Layout types   |
   |                    |    |               |        | available for a client and server that do not use
   the same local representation  |
   |                    |    |               |        | the ability to translate to a common
   syntax that can be interpreted by both.

   Similarly, security principals file       |
   |                    |    |               |        | system.        |
   | fs_locations       | 24 | fs_locations  | READ   | Locations      |
   |                    |    |               |        | where this     |
   |                    |    |               |        | file system    |
   |                    |    |               |        | may be represented in different ways
   by different security mechanisms.  Servers normally translate these
   representations into a common format, generally that used by local
   storage, to serve as a means of identifying the users corresponding
   to these security principals.  When these local identifiers are
   translated to the form of the owner attribute, associated with files
   created by such principals they identify, in a common format, found.  |
   |                    |    |               |        | If the
   users associated with each corresponding set of security principals.

   The translation used to interpret owner and group strings is not
   specified server  |
   |                    |    |               |        | returns        |
   |                    |    |               |        | NFS4ERR_MOVED  |
   |                    |    |               |        | as part of the protocol.  This allows various solutions to
   be employed.  For example, a local translation table may an error,   |
   |                    |    |               |        | this attribute |
   |                    |    |               |        | MUST be consulted
   that maps between a numeric id to        |
   |                    |    |               |        | supported.     |
   | fs_locations_info  | 67 |               | READ   | Full function  |
   |                    |    |               |        | file system    |
   |                    |    |               |        | location.      |
   | fs_status          | 61 | fs4_status    | READ   | Generic file   |
   |                    |    |               |        | system type    |
   |                    |    |               |        | information.   |
   | hidden             | 25 | bool          | R/W    | True, if the user@dns_domain syntax.  A name
   service may also be used   |
   |                    |    |               |        | file is        |
   |                    |    |               |        | considered     |
   |                    |    |               |        | hidden with    |
   |                    |    |               |        | respect to accomplish the translation.  A server may
   provide a more general service, not limited by any particular
   translation (which would only translate a limited set of possible
   strings) by storing the owner and owner_group |
   |                    |    |               |        | Windows API?   |
   | homogeneous        | 26 | bool          | READ   | True, if this  |
   |                    |    |               |        | object's file  |
   |                    |    |               |        | system is      |
   |                    |    |               |        | homogeneous,   |
   |                    |    |               |        | i.e. are per   |
   |                    |    |               |        | file system    |
   |                    |    |               |        | attributes in local
   storage without any translation or it may augment a translation
   method by storing the entire string |
   |                    |    |               |        | same for attributes all   |
   |                    |    |               |        | file system's  |
   |                    |    |               |        | objects.       |
   | layout_alignment   | 66 | uint32_t      | READ   | Preferred      |
   |                    |    |               |        | alignment for which no
   translation is available while using the local representation  |
   |                    |    |               |        | layout related |
   |                    |    |               |        | I/O.           |
   | layout_blksize     | 65 | uint32_t      | READ   | Preferred      |
   |                    |    |               |        | block size for
   those cases in which a translation is available.

   Servers that do not provide support |
   |                    |    |               |        | layout related |
   |                    |    |               |        | I/O.           |
   | layout_hint        | 63 | layouthint4   | WRITE  | Client         |
   |                    |    |               |        | specified hint |
   |                    |    |               |        | for all possible values of the
   owner and owner_group attributes, should return an error
   (NFS4ERR_BADOWNER) when a string is presented that has no
   translation, as the value to be set file       |
   |                    |    |               |        | layout.        |
   | layout_type        | 64 | layouttype4   | READ   | Layout types   |
   |                    |    |               |        | available for a SETATTR of  |
   |                    |    |               |        | the owner,
   owner_group, or acl attributes.  When a server does accept an owner
   or owner_group value as valid on a SETATTR (and similarly file.      |
   | maxfilesize        | 27 | uint64        | READ   | Maximum        |
   |                    |    |               |        | supported file |
   |                    |    |               |        | size for the
   owner and group strings in an acl), it is promising to return that
   same string when a corresponding GETATTR is done.  Configuration
   changes and ill-constructed name translations (those that contain
   aliasing) may make that promise impossible to honor.  Servers should
   make appropriate efforts to avoid a situation in which these
   attributes have their values changed when no real change to ownership
   has occurred.

   The "dns_domain" portion of the owner string is meant to be a DNS
   domain name.  For example, user@ietf.org.  Servers should accept as
   valid a set   |
   |                    |    |               |        | file system of users for at least one domain.  A server may treat
   other domains as having no valid translations.  A more general
   service is provided when a server is capable |
   |                    |    |               |        | this object.   |
   | maxlink            | 28 | uint32        | READ   | Maximum number |
   |                    |    |               |        | of accepting users links for
   multiple domains, or   |
   |                    |    |               |        | this object.   |
   | maxname            | 29 | uint32        | READ   | Maximum        |
   |                    |    |               |        | filename size  |
   |                    |    |               |        | supported for all domains, subject to security
   constraints.

   In  |
   |                    |    |               |        | this object.   |
   | maxread            | 30 | uint64        | READ   | Maximum read   |
   |                    |    |               |        | size supported |
   |                    |    |               |        | for this       |
   |                    |    |               |        | object.        |
   | maxwrite           | 31 | uint64        | READ   | Maximum write  |
   |                    |    |               |        | size supported |
   |                    |    |               |        | for this       |
   |                    |    |               |        | object. This   |
   |                    |    |               |        | attribute      |
   |                    |    |               |        | SHOULD be      |
   |                    |    |               |        | supported if   |
   |                    |    |               |        | the case where there file is no translation available    |
   |                    |    |               |        | writable. Lack |
   |                    |    |               |        | of this        |
   |                    |    |               |        | attribute can  |
   |                    |    |               |        | lead to the    |
   |                    |    |               |        | client either  |
   |                    |    |               |        | wasting        |
   |                    |    |               |        | bandwidth or
   server, the attribute value must be constructed without   |
   |                    |    |               |        | not receiving  |
   |                    |    |               |        | the "@".
   Therefore, best       |
   |                    |    |               |        | performance.   |
   | mdsthreshold       | 68 | mdsthreshold4 | READ   | Hint to client |
   |                    |    |               |        | as to when to  |
   |                    |    |               |        | write through  |
   |                    |    |               |        | the absence pnfs       |
   |                    |    |               |        | metadata       |
   |                    |    |               |        | server.        |
   | mimetype           | 32 | utf8<>        | R/W    | MIME body      |
   |                    |    |               |        | type/subtype   |
   |                    |    |               |        | of the @ from the owner or owner_group
   attribute signifies that no translation was available at the sender this        |
   |                    |    |               |        | object.        |
   | mode               | 33 | mode4         | R/W    | UNIX-style     |
   |                    |    |               |        | mode and that the receiver of the attribute should not use that string as
   a basis       |
   |                    |    |               |        | permission     |
   |                    |    |               |        | bits for translation into its own internal format.  Even though this  |
   |                    |    |               |        | object.        |
   | mounted_on_fileid  | 55 | uint64        | READ   | Like fileid,   |
   |                    |    |               |        | but if the attribute value can not be translated, it may still be useful.
   In     |
   |                    |    |               |        | target         |
   |                    |    |               |        | filehandle is  |
   |                    |    |               |        | the case root of a client,  |
   |                    |    |               |        | file system    |
   |                    |    |               |        | return the attribute string may be used for local
   display     |
   |                    |    |               |        | fileid of ownership.

   To provide the  |
   |                    |    |               |        | underlying     |
   |                    |    |               |        | directory.     |
   | no_trunc           | 34 | bool          | READ   | True, if a greater degree of compatibility with previous versions
   of NFS (i.e. v2 and v3), which identified users and groups by 32-bit
   unsigned uid's and gid's, owner and group strings that consist of
   decimal numeric values with no leading zeros can     |
   |                    |    |               |        | name longer    |
   |                    |    |               |        | than name_max  |
   |                    |    |               |        | is used, an    |
   |                    |    |               |        | error be given a special
   interpretation by clients       |
   |                    |    |               |        | returned and servers which choose to provide such
   support.  The receiver may treat such a user or group string as
   representing the same user as would be represented by a v2/v3 uid or
   gid having the corresponding numeric value.  A server   |
   |                    |    |               |        | name is not
   obligated    |
   |                    |    |               |        | truncated.     |
   | numlinks           | 35 | uint32        | READ   | Number of hard |
   |                    |    |               |        | links to accept such a string, but may return an NFS4ERR_BADOWNER
   instead.  To avoid this mechanism being used to subvert user and
   group translation, so that a client might pass all  |
   |                    |    |               |        | object.        |
   | owner              | 36 | utf8<>        | R/W    | The string     |
   |                    |    |               |        | name of the owners and
   groups in numeric form, a server SHOULD return an NFS4ERR_BADOWNER
   error when there is a valid translation for the user or    |
   |                    |    |               |        | owner
   designated in of this way.  In that case, the client must use the
   appropriate name@domain string and not the special form for
   compatibility.  |
   |                    |    |               |        | object.        |
   | owner_group        | 37 | utf8<>        | R/W    | The owner string "nobody" may be used to designate an anonymous user,
   which will be associated with a file created by a security principal
   that cannot be mapped through normal means to the owner attribute.

4.9.  Character Case Attributes

   With respect to the case_insensitive and case_preserving attributes,
   each UCS-4 character (which UTF-8 encodes) has a "long descriptive
   name" [RFC1345] which may or may not included     |
   |                    |    |               |        | name of the word "CAPITAL" or
   "SMALL".  The presence    |
   |                    |    |               |        | group          |
   |                    |    |               |        | ownership of SMALL or CAPITAL allows an NFS server to
   implement unambiguous and efficient table driven mappings for case
   insensitive comparisons, and non-case-preserving storage.   |
   |                    |    |               |        | this object.   |
   | quota_avail_hard   | 38 | uint64        | READ   | For
   general character handling and internationalization issues, definition |
   |                    |    |               |        | see the "Quota     |
   |                    |    |               |        | Attributes"    |
   |                    |    |               |        | section "Internationalization".

4.10.  Quota Attributes

   For the attributes related to filesystem quotas, the following
   definitions apply: below. |
   | quota_avail_soft  The value in bytes which represents the amount of
      additional disk space that can be allocated to this file or
      directory before   | 39 | uint64        | READ   | For definition |
   |                    |    |               |        | see "Quota     |
   |                    |    |               |        | Attributes"    |
   |                    |    |               |        | section below. |
   | quota_used         | 40 | uint64        | READ   | For definition |
   |                    |    |               |        | see "Quota     |
   |                    |    |               |        | Attributes"    |
   |                    |    |               |        | section below. |
   | rawdev             | 41 | specdata4     | READ   | Raw device     |
   |                    |    |               |        | identifier.    |
   |                    |    |               |        | UNIX device    |
   |                    |    |               |        | major/minor    |
   |                    |    |               |        | node           |
   |                    |    |               |        | information.   |
   |                    |    |               |        | If the user may reasonably be warned.  It is
      understood that this space may be consumed by allocations to other
      files or directories though there value   |
   |                    |    |               |        | of type is a rule as to which other
      files not |
   |                    |    |               |        | NF4BLK or directories.

   quota_avail_hard  The      |
   |                    |    |               |        | NF4CHR, the    |
   |                    |    |               |        | value return   |
   |                    |    |               |        | SHOULD NOT be  |
   |                    |    |               |        | considered     |
   |                    |    |               |        | useful.        |
   | recv_impl_id       | 59 | nfs_impl_id4  | READ   | Client obtains |
   |                    |    |               |        | server         |
   |                    |    |               |        | implementation |
   |                    |    |               |        | via GETATTR.   |
   | send_impl_id       | 58 | impl_ident4   | WRITE  | Client         |
   |                    |    |               |        | provides       |
   |                    |    |               |        | server with    |
   |                    |    |               |        | implementation |
   |                    |    |               |        | identity via   |
   |                    |    |               |        | SETATTR.       |
   | space_avail        | 42 | uint64        | READ   | Disk space in  |
   |                    |    |               |        | bytes which represent the amount of
      additional disk space beyond the current allocation that can be
      allocated          |
   |                    |    |               |        | available to   |
   |                    |    |               |        | this user on   |
   |                    |    |               |        | the file or directory before further allocations
      will be refused.  It is understood that       |
   |                    |    |               |        | system         |
   |                    |    |               |        | containing     |
   |                    |    |               |        | this space may object -  |
   |                    |    |               |        | this should be consumed
      by allocations to other files or directories.

   quota_used  The value |
   |                    |    |               |        | the smallest   |
   |                    |    |               |        | relevant       |
   |                    |    |               |        | limit.         |
   | space_free         | 43 | uint64        | READ   | Free disk      |
   |                    |    |               |        | space in bytes which represent |
   |                    |    |               |        | on the amount of disc
      space used by this file or directory and possibly a number of
      other similar files or directories, where the set of "similar"
      meets at least    |
   |                    |    |               |        | system         |
   |                    |    |               |        | containing     |
   |                    |    |               |        | this object -  |
   |                    |    |               |        | this should be |
   |                    |    |               |        | the criterion that allocating smallest   |
   |                    |    |               |        | relevant       |
   |                    |    |               |        | limit.         |
   | space_total        | 44 | uint64        | READ   | Total disk     |
   |                    |    |               |        | space to any file or
      directory in bytes |
   |                    |    |               |        | on the set will reduce the "quota_avail_hard" of every
      other file or directory in the set.

      Note that there may be a number of distinct but overlapping sets    |
   |                    |    |               |        | system         |
   |                    |    |               |        | containing     |
   |                    |    |               |        | this object.   |
   | space_used         | 45 | uint64        | READ   | Number of files or directories for which a quota_used value file |
   |                    |    |               |        | system bytes   |
   |                    |    |               |        | allocated to   |
   |                    |    |               |        | this object.   |
   | system             | 46 | bool          | R/W    | True, if this  |
   |                    |    |               |        | file is
      maintained.  E.g. "all files with a given owner", "all files      |
   |                    |    |               |        | "system" file  |
   |                    |    |               |        | with
      a given group owner". etc.

      The server is at liberty respect   |
   |                    |    |               |        | to choose any of those sets but should do
      so in a repeatable way.  The rule may be configured per-filesystem
      or may be "choose the set with Windows |
   |                    |    |               |        | API?           |
   | time_access        | 47 | nfstime4      | READ   | The time of    |
   |                    |    |               |        | last access to |
   |                    |    |               |        | the smallest quota".

4.11.  mounted_on_fileid

   UNIX-based operating environments connect object by  |
   |                    |    |               |        | a filesystem into the
   namespace read that    |
   |                    |    |               |        | was satisfied  |
   |                    |    |               |        | by connecting (mounting) the filesystem onto server. |
   | time_access_set    | 48 | settime4      | WRITE  | Set the existing
   file object (the mount point, usually a directory) time   |
   |                    |    |               |        | of an existing
   filesystem.  When the mount point's parent directory is read via an
   API like readdir(), last access |
   |                    |    |               |        | to the return results are directory entries, each
   with a component name and a fileid. object. |
   |                    |    |               |        | SETATTR use    |
   |                    |    |               |        | only.          |
   | time_backup        | 49 | nfstime4      | R/W    | The fileid time of    |
   |                    |    |               |        | last backup of |
   |                    |    |               |        | the mount point's
   directory entry will be different from the fileid that the stat()
   system call returns. object.    |
   | time_create        | 50 | nfstime4      | R/W    | The stat() system call is returning the fileid time of the root    |
   |                    |    |               |        | creation of    |
   |                    |    |               |        | the mounted filesystem, whereas readdir() is returning
   the fileid stat() would object.    |
   |                    |    |               |        | This attribute |
   |                    |    |               |        | does not have returned before  |
   |                    |    |               |        | any filesystems were
   mounted on the mount point.

   Unlike NFS version 3, NFS version 4 allows a client's LOOKUP request relation   |
   |                    |    |               |        | to cross other filesystems.  The client detects the filesystem
   crossing whenever the filehandle argument of LOOKUP has an fsid
   attribute different from that of the filehandle returned by LOOKUP.
   A UNIX-based client will consider this a "mount point crossing".         |
   |                    |    |               |        | traditional    |
   |                    |    |               |        | UNIX has a legacy scheme for allowing a process to determine its
   current working directory.  This relies on readdir() file      |
   |                    |    |               |        | attribute      |
   |                    |    |               |        | "ctime" or     |
   |                    |    |               |        | "change time". |
   | time_delta         | 51 | nfstime4      | READ   | Smallest       |
   |                    |    |               |        | useful server  |
   |                    |    |               |        | time           |
   |                    |    |               |        | granularity.   |
   | time_metadata      | 52 | nfstime4      | READ   | The time of a mount
   point's parent and stat()    |
   |                    |    |               |        | last meta-data |
   |                    |    |               |        | modification   |
   |                    |    |               |        | of the mount point returning fileids as
   previously described. object. |
   | time_modify        | 53 | nfstime4      | READ   | The mounted_on_fileid attribute corresponds time of    |
   |                    |    |               |        | last           |
   |                    |    |               |        | modification   |
   |                    |    |               |        | to the fileid that readdir() would have returned as described
   previously.

   While object. |
   | time_modify_set    | 54 | settime4      | WRITE  | Set the NFS version 4 client could simply fabricate a fileid
   corresponding time   |
   |                    |    |               |        | of last        |
   |                    |    |               |        | modification   |
   |                    |    |               |        | to what mounted_on_fileid provides (and if the server
   does not support mounted_on_fileid, object. |
   |                    |    |               |        | SETATTR use    |
   |                    |    |               |        | only.          |
   +--------------------+----+---------------+--------+----------------+

5.7.  Time Access

   As defined above, the client has no choice), there
   is a risk that time_access attribute represents the client will generate a fileid that conflicts with
   one that is already assigned time of
   last access to another object in the filesystem.
   Instead, if the server can provide the mounted_on_fileid, the
   potential for client operational problems in this area is eliminated.

   If the server detects object by a read that there was satisfied by the server.
   The notion of what is no mounted point at an "access" depends on server's operating
   environment and/or the target server's file object, then the value system semantics.  For example,
   for mounted_on_fileid that it returns is servers obeying POSIX semantics, time_access would be updated
   only by the same as READLINK, READ, and READDIR operations and not any of the
   operations that modify the content of the fileid attribute.

   The mounted_on_fileid object.  Of course, setting
   the corresponding time_access_set attribute is RECOMMENDED, so another way to modify
   the server SHOULD
   provide it if possible, and for a UNIX-based server, this is
   straightforward.  Usually, mounted_on_fileid will be requested during time_access attribute.

   Whenever the file object resides on a READDIR operation, in which case it is trivial (at least for UNIX-
   based servers) writable file system, the
   server should make best efforts to return mounted_on_fileid since it is equal record time_access into stable
   storage.  However, to mitigate the
   fileid performance effects of a directory entry returned by readdir().  If
   mounted_on_fileid is requested in a GETATTR operation, doing so,
   and most especially whenever the server
   should obey an invariant that has it returning a value that is equal
   to satisfying the file object's entry in read of the
   object's parent directory, i.e.
   what readdir() would have returned.  Some operating environments
   allow a series of two or more filesystems to be mounted onto a single
   mount point.  In this case, for content from its cache, the server MAY cache access time
   updates and lazily write them to obey the aforementioned
   invariant, it will need stable storage.  It is also
   acceptable to find give administrators of the base mount point, and not server the
   intermediate mount points.

4.12.  send_impl_id option to disable
   time_access updates.

5.8.  Interpreting owner and recv_impl_id

   These owner_group

   The recommended attributes are used to identify the client "owner" and
   server.  In "owner_group" (and also users
   and groups within the case "acl" attribute) are represented in terms of the send_impl_id attribute, a
   UTF-8 string.  To avoid a representation that is tied to a particular
   underlying implementation at the client sends
   its clientid4 value along with or server, the nfs_impl_id4.  The use of the
   clientid4 value allows the server to identify and match specific
   client interaction.  In the case
   UTF-8 string has been chosen.  Note that section 6.1 of RFC2624 [26]
   provides additional rationale.  It is expected that the recv_impl_id attribute, the
   client receives the nfs_impl_id4 value.

   Access to this identification information can be most useful at both client and server.  Being able to identify specific implementations
   can help in planning by administrators or implementers.  For example,
   diagnostic software may extract this information in an attempt to
   identify implementation problems, performance workload behaviors or
   general usage statistics.  Since the intent
   server will have their own local representation of having access to this
   information owner and
   owner_group that is used for planning local storage or general diagnosis only, presentation to the end
   user.  Therefore, it is expected that when these attributes are
   transferred between the client and server MUST NOT interpret this implementation identity information in
   a way that affects interoperational behavior of the implementation.
   The reason local
   representation is the if clients and servers did such translated to a thing, they might
   use fewer capabilities syntax of the protocol than the peer can support, or
   the client and server might refuse to interoperate.

   Because it is likely some implementations form "user@
   dns_domain".  This will violate the protocol
   specification and interpret the identity information, implementations
   MUST allow the users of the NFSv4 for a client and server to set that do not use
   the
   contents of same local representation the sent nfs_impl_id structure ability to any value.

   Even though these attributes are recommended, if the server supports
   one of them it MUST support the other.

4.13.  fs_layout_type

   This attribute applies translate to a file system and indicates what layout
   types are supported common
   syntax that can be interpreted by the file system.  We expect this attribute to both.

   Similarly, security principals may be queried when a client encounters represented in different ways
   by different security mechanisms.  Servers normally translate these
   representations into a new fsid.  This attribute is common format, generally that used by the client local
   storage, to determine if it has applicable layout drivers.

4.14.  layout_type

   This attribute indicates the particular layout type(s) used for serve as a
   file.  This is for informational purposes only.  The client needs to
   use means of identifying the LAYOUTGET operation in order to get enough information (e.g.,
   specific device information) in order users corresponding
   to perform I/O.

4.15.  layout_hint

   This attribute may be set on newly created files these security principals.  When these local identifiers are
   translated to influence the
   metadata server's choice for the file's layout.  It is suggested that
   this attribute is set as one form of the initial attributes within owner attribute, associated with files
   created by such principals they identify, in a common format, the
   OPEN call.
   users associated with each corresponding set of security principals.

   The metadata server may ignore this attribute.  This
   attribute translation used to interpret owner and group strings is a sub-set not
   specified as part of the layout structure returned by LAYOUTGET. protocol.  This allows various solutions to
   be employed.  For example, instead of specifying particular devices, this would a local translation table may be
   used to suggest the stripe width of consulted
   that maps between a file.  It is up numeric id to the server
   implementation user@dns_domain syntax.  A name
   service may also be used to determine which fields within accomplish the layout it uses.

5.  Access Control Lists

   The NFS version 4 ACL attribute is an array translation.  A server may
   provide a more general service, not limited by any particular
   translation (which would only translate a limited set of access control entries
   (ACEs).  Although, possible
   strings) by storing the client can read owner and write the ACL attribute,
   the server is responsible for using the ACL to perform access
   control.  The client can use the OPEN or ACCESS operations to check
   access owner_group attributes in local
   storage without modifying or reading data any translation or metadata.

   The NFS ACE attribute is defined as follows:

            typedef uint32_t        acetype4;
            typedef uint32_t        aceflag4;
            typedef uint32_t        acemask4;

            struct nfsace4 {
                    acetype4        type;
                    aceflag4        flag;
                    acemask4        access_mask;
                    utf8str_mixed   who;
            };

   To determine if it may augment a request succeeds, translation
   method by storing the server processes each nfsace4
   entry entire string for attributes for which no
   translation is available while using the local representation for
   those cases in order.  Only ACEs which have a "who" that matches the
   requester are considered.  Each ACE translation is processed until available.

   Servers that do not provide support for all possible values of the
   bits of the requester's access have been ALLOWED.  Once a bit (see
   below) has been ALLOWED by
   owner and owner_group attributes, should return an ACCESS_ALLOWED_ACE, it error
   (NFS4ERR_BADOWNER) when a string is presented that has no longer
   considered in
   translation, as the processing value to be set for a SETATTR of later ACEs.  If the owner,
   owner_group, or acl attributes.  When a server does accept an ACCESS_DENIED_ACE
   is encountered where owner
   or owner_group value as valid on a SETATTR (and similarly for the requester's access still has unALLOWED bits
   owner and group strings in common with the "access_mask" of the ACE, the request an acl), it is denied.
   However, unlike the ALLOWED and DENIED ACE types, the ALARM and AUDIT
   ACE types do not affect promising to return that
   same string when a requester's access, corresponding GETATTR is done.  Configuration
   changes and instead are for
   triggering events as a result of ill-constructed name translations (those that contain
   aliasing) may make that promise impossible to honor.  Servers should
   make appropriate efforts to avoid a requester's access attempt.

   Therefore, all AUDIT and ALARM ACEs are processed until end of the
   ACL.  When the ACL is fully processed, if there are bits situation in the
   requester's mask that which these
   attributes have not been ALLOWED or DENIED, access is
   denied.

   This is not intended their values changed when no real change to limit the ability ownership
   has occurred.

   The "dns_domain" portion of server implementations the owner string is meant to implement alternative access policies. be a DNS
   domain name.  For example:

   o example, user@ietf.org.  Servers should accept as
   valid a set of users for at least one domain.  A server implementation might always grant ACE4_WRITE_ACL and
      ACE4_READ_ACL permissions.  This would prevent the user from
      getting into the situation where they can't ever modify the ACL.

   o  If a file system may treat
   other domains as having no valid translations.  A more general
   service is mounted read only, then the provided when a server may deny
      ACE4_WRITE_DATA even though the ACL grants it.

   As mentioned before, this is one capable of the reasons that client
   implementations are not recommended accepting users for
   multiple domains, or for all domains, subject to do their own access checks
   based on their interpretation the ACL, but rather use security
   constraints.

   In the OPEN and
   ACCESS case where there is no translation available to do access checks.  This allows the client to act on the
   results of having the server determine whether or not access should
   be granted based on its interpretation of
   server, the ACL.

   Clients attribute value must be aware of situations in which an object's ACL will
   define a certain access even though the server will not enforce it.
   In general, but especially in these situations, constructed without the client needs to
   do its part in "@".
   Therefore, the enforcement absence of access as defined by the ACL.  To
   do this, @ from the client may issue owner or owner_group
   attribute signifies that no translation was available at the appropriate ACCESS operation prior
   to servicing sender
   and that the request receiver of the user or application in order to
   determine whether the user or application attribute should be granted the
   access requested.

   Some situations in which the ACL may define accesses not use that the server
   doesn't enforce:

   o All servers will allow string as
   a user basis for translation into its own internal format.  Even though
   the ability to read attribute value can not be translated, it may still be useful.
   In the data case of a client, the
   file when only the execute permission is granted (i.e.  If the ACL
   denies the user the ACE4_READ_DATA access and allows the user
   ACE4_EXECUTE, the server will allow the user to read the data attribute string may be used for local
   display of the
   file).

   o Many servers have the notion ownership.

   To provide a greater degree of owner-override in compatibility with previous versions
   of NFS (i.e. v2 and v3), which the identified users and groups by 32-bit
   unsigned uid's and gid's, owner
   of the object is allowed to override accesses and group strings that are denied consist of
   decimal numeric values with no leading zeros can be given a special
   interpretation by the
   ACL. clients and servers which choose to provide such
   support.  The NFS version 4 ACL model is quite rich.  Some server platforms receiver may
   provide access control functionality that goes beyond the UNIX-style
   mode attribute, but which is not as rich treat such a user or group string as
   representing the NFS ACL model.  So
   that users can take advantage of this more limited functionality, same user as would be represented by a v2/v3 uid or
   gid having the corresponding numeric value.  A server is not
   obligated to accept such a string, but may indicate return an NFS4ERR_BADOWNER
   instead.  To avoid this mechanism being used to subvert user and
   group translation, so that it supports ACLs as long as it follows a client might pass all of the
   guidelines for mapping between its ACL model owners and the NFS version 4
   ACL model.

   The situation is complicated by the fact that
   groups in numeric form, a server may have
   multiple modules SHOULD return an NFS4ERR_BADOWNER
   error when there is a valid translation for the user or owner
   designated in this way.  In that enforce ACLs.  For example, case, the enforcement for
   NFS version 4 access may be different from client must use the enforcement for local
   access,
   appropriate name@domain string and both may be different from not the enforcement special form for access
   through other protocols such as SMB.  So it
   compatibility.

   The owner string "nobody" may be useful for a
   server used to accept designate an ACL even if not all of its modules are able to
   support it.

   The guiding principle in all cases is anonymous user,
   which will be associated with a file created by a security principal
   that cannot be mapped through normal means to the server must not accept
   ACLs that appear owner attribute.

5.9.  Character Case Attributes

   With respect to make the file more secure than it really is.

5.1.  ACE type

      Type         Description
      _____________________________________________________
      ALLOW        Explicitly grants case_insensitive and case_preserving attributes,
   each UCS-4 character (which UTF-8 encodes) has a "long descriptive
   name" RFC1345 [27] which may or may not included the access defined in
                   acemask4 word "CAPITAL"
   or "SMALL".  The presence of SMALL or CAPITAL allows an NFS server to
   implement unambiguous and efficient table driven mappings for case
   insensitive comparisons, and non-case-preserving storage.  For
   general character handling and internationalization issues, see the
   section "Internationalization".

5.10.  Quota Attributes

   For the attributes related to file or directory.

      DENY         Explicitly denies system quotas, the access defined following
   definitions apply:

   quota_avail_soft  The value in
                   acemask4 to bytes which represents the file or directory.

      AUDIT        LOG (system dependent) any access
                   attempt amount of
      additional disk space that can be allocated to a this file or
      directory which
                   uses any of before the access methods specified
                   in acemask4.

      ALARM        Generate a system ALARM (system
                   dependent) when any access attempt user may reasonably be warned.  It is
                   made
      understood that this space may be consumed by allocations to other
      files or directories though there is a file rule as to which other
      files or directory for the
                   access methods specified directories.

   quota_avail_hard  The value in acemask4.

   A server need not support all bytes which represent the amount of
      additional disk space beyond the above ACE types.  The bitmask
   constants used current allocation that can be
      allocated to this file or directory before further allocations
      will be refused.  It is understood that this space may be consumed
      by allocations to other files or directories.

   quota_used  The value in bytes which represent the above definitions within the
   aclsupport attribute are as follows:

         const ACL4_SUPPORT_ALLOW_ACL    = 0x00000001;
         const ACL4_SUPPORT_DENY_ACL     = 0x00000002;
         const ACL4_SUPPORT_AUDIT_ACL    = 0x00000004;
         const ACL4_SUPPORT_ALARM_ACL    = 0x00000008;

   The semantics amount of the "type" field follow the descriptions provided
   above.

   The constants disc
      space used for by this file or directory and possibly a number of
      other similar files or directories, where the type field (acetype4) are as follows:

         const ACE4_ACCESS_ALLOWED_ACE_TYPE      = 0x00000000;
         const ACE4_ACCESS_DENIED_ACE_TYPE       = 0x00000001;
         const ACE4_SYSTEM_AUDIT_ACE_TYPE        = 0x00000002;
         const ACE4_SYSTEM_ALARM_ACE_TYPE        = 0x00000003;

   Clients should not attempt to set an ACE unless of "similar"
      meets at least the server claims
   support for criterion that ACE type.  If the server receives a request allocating space to any file or
      directory in the set
   an ACE that it cannot store, it MUST reject will reduce the request with
   NFS4ERR_ATTRNOTSUPP.  If "quota_avail_hard" of every
      other file or directory in the server receives a request to set an ACE set.

      Note that it can store there may be a number of distinct but cannot enforce, the server SHOULD reject the
   request overlapping sets
      of files or directories for which a quota_used value is
      maintained.  E.g. "all files with a given owner", "all files with NFS4ERR_ATTRNOTSUPP.

   Example: suppose
      a given group owner". etc.

      The server can enforce NFS ACLs for NFS access is at liberty to choose any of those sets but
   cannot enforce ACLs for local access.  If arbitrary processes can run
   on the server, then the server SHOULD NOT indicate ACL support.  On should do
      so in a repeatable way.  The rule may be configured per file
      system or may be "choose the other hand, if only trusted administrative programs run locally,
   then set with the server may indicate ACL support.

5.2.  ACE Access Mask

   The access_mask field contains values based on smallest quota".

5.11.  mounted_on_fileid

   UNIX-based operating environments connect a file system into the following:

      ACE4_READ_DATA
         Operation(s) affected:
              READ
              OPEN
         Discussion:
              Permission to read
   namespace by connecting (mounting) the data of file system onto the file.

              Servers SHOULD allow existing
   file object (the mount point, usually a user directory) of an existing
   file system.  When the ability to mount point's parent directory is read via an
   API like readdir(), the data return results are directory entries, each
   with a component name and a fileid.  The fileid of the file when only mount point's
   directory entry will be different from the ACE4_EXECUTE access mask bit fileid that the stat()
   system call returns.  The stat() system call is
              allowed.

      ACE4_LIST_DIRECTORY
          Operation(s) affected:
              READDIR
          Discussion:
              Permission to list returning the contents fileid
   of a directory.

      ACE4_WRITE_DATA
          Operation(s) affected:
              WRITE
              OPEN
          Discussion:
              Permission to modify a file's data anywhere in the file's
              offset range.  This includes root of the ability to write to mounted file system, whereas readdir() is
   returning the fileid stat() would have returned before any
              arbitrary offset and as file
   systems were mounted on the mount point.

   Unlike NFS version 3, NFS version 4 allows a result client's LOOKUP request
   to grow cross other file systems.  The client detects the file.

      ACE4_ADD_FILE
          Operation(s) affected:
              CREATE
              OPEN
          Discussion:
              Permission to add a new file in system
   crossing whenever the filehandle argument of LOOKUP has an fsid
   attribute different from that of the filehandle returned by LOOKUP.
   A UNIX-based client will consider this a directory.  The CREATE
              operation is affected when nfs_ftype4 is NF4LNK, NF4BLK,
              NF4CHR, NF4SOCK, or NF4FIFO. (NF4DIR is not listed because
              it is covered by ACE4_ADD_SUBDIRECTORY.) OPEN is affected
              when used to create "mount point crossing".
   UNIX has a regular file.

      ACE4_APPEND_DATA
          Operation(s) affected:
              WRITE
              OPEN
          Discussion:
               The ability to modify legacy scheme for allowing a file's data, but only starting at
               EOF. process to determine its
   current working directory.  This allows for the notion relies on readdir() of append-only files, by
               allowing ACE4_APPEND_DATA a mount
   point's parent and denying ACE4_WRITE_DATA to stat() of the same user or group.  If a file has an ACL such mount point returning fileids as
   previously described.  The mounted_on_fileid attribute corresponds to
   the
               one fileid that readdir() would have returned as described above and
   previously.

   While the NFS version 4 client could simply fabricate a WRITE request is made for
               somewhere other than EOF, fileid
   corresponding to what mounted_on_fileid provides (and if the server SHOULD return
               NFS4ERR_ACCESS.

      ACE4_ADD_SUBDIRECTORY
          Operation(s) affected:
              CREATE
          Discussion:
              Permission to create
   does not support mounted_on_fileid, the client has no choice), there
   is a subdirectory in risk that the client will generate a directory.  The
              CREATE operation is affected when nfs_ftype4 fileid that conflicts with
   one that is NF4DIR.

      ACE4_READ_NAMED_ATTRS
          Operation(s) affected:
              OPENATTR
          Discussion:
              Permission already assigned to read another object in the named attributes of a file or to
              lookup system.
   Instead, if the named attributes directory.  OPENATTR is
              affected when it is not used to create a named attribute
              directory.  This server can provide the mounted_on_fileid, the
   potential for client operational problems in this area is when 1.) createdir eliminated.

   If the server detects that there is TRUE, but a
              named attribute directory already exists, or 2.) createdir no mounted point at the target
   file object, then the value for mounted_on_fileid that it returns is FALSE.

      ACE4_WRITE_NAMED_ATTRS
          Operation(s) affected:
              OPENATTR
          Discussion:
              Permission to write
   the named attributes same as that of a file or
              to create a named the fileid attribute.

   The mounted_on_fileid attribute directory.  OPENATTR is
              affected when RECOMMENDED, so the server SHOULD
   provide it if possible, and for a UNIX-based server, this is used to create
   straightforward.  Usually, mounted_on_fileid will be requested during
   a named attribute
              directory.  This READDIR operation, in which case it is when createdir trivial (at least for UNIX-
   based servers) to return mounted_on_fileid since it is TRUE and no named
              attribute directory exists.  The ability equal to check whether
              or not the
   fileid of a named attribute directory exists depends on entry returned by readdir().  If
   mounted_on_fileid is requested in a GETATTR operation, the
              ability to look server
   should obey an invariant that has it up, therefore, users also need the
              ACE4_READ_NAMED_ATTRS permission in order to create returning a
              named attribute directory.

      ACE4_EXECUTE
          Operation(s) affected:
              LOOKUP
              READ
              OPEN
          Discussion:
              Permission value that is equal
   to execute a the file or traverse/search a
              directory.

              Servers SHOULD object's entry in the object's parent directory, i.e.
   what readdir() would have returned.  Some operating environments
   allow a user the ability to read the data series of the two or more file when only the ACE4_EXECUTE access mask bit is
              allowed.  This is because there is no way systems to execute be mounted onto a
              file without reading
   single mount point.  In this case, for the contents.  Though a server may
              treat ACE4_EXECUTE and ACE4_READ_DATA bits identically
              when deciding to permit a READ operation, it SHOULD still
              allow obey the two bits
   aforementioned invariant, it will need to be set independently in ACLs, find the base mount point,
   and
              MUST distinguish between them when replying not the intermediate mount points.

5.12.  send_impl_id and recv_impl_id

   These recommended attributes are used to ACCESS
              operations. identify the client and
   server.  In particular, servers SHOULD NOT silently
              turn on one of the two bits when case of the other is set, as
              that would make it impossible for send_impl_id attribute, the client to correctly
              enforce sends
   its clientid4 value along with the distinction between read and execute
              permissions.

                As an example, following a SETATTR nfs_impl_id4.  The use of the following ACL:
                        nfsuser:ACE4_EXECUTE:ALLOW

                A subsequent GETATTR of ACL for that file SHOULD return:
                        nfsuser:ACE4_EXECUTE:ALLOW
                Rather than:
                        nfsuser:ACE4_EXECUTE/ACE4_READ_DATA:ALLOW

      ACE4_DELETE_CHILD
          Operation(s) affected:
              REMOVE
          Discussion:
              Permission to delete a file or directory within a
              directory.  See section "ACE4_DELETE vs.
              ACE4_DELETE_CHILD" for information on how these two access
              mask bits interact.

      ACE4_READ_ATTRIBUTES
          Operation(s) affected:
              GETATTR of file system object attributes
          Discussion:
              The ability
   clientid4 value allows the server to read basic attributes (non-ACLs) of a file.
              On a UNIX system, basic attributes can be thought identify and match specific
   client interaction.  In the case of as the stat level attributes.  Allowing this access mask bit
              would mean recv_impl_id attribute, the entity
   client receives the nfs_impl_id4 value.

   Access to this identification information can execute "ls -l" be most useful at both
   client and stat.

      ACE4_WRITE_ATTRIBUTES
          Operation(s) affected:
              SETATTR of time_access_set, time_backup,
              time_create, time_modify_set
          Discussion:
              Permission server.  Being able to change the times associated with a file identify specific implementations
   can help in planning by administrators or directory to implementers.  For example,
   diagnostic software may extract this information in an arbitrary value.  A user having
              ACE4_WRITE_DATA permission, but lacking
              ACE4_WRITE_ATTRIBUTES must be allowed attempt to implicitly set
   identify implementation problems, performance workload behaviors or
   general usage statistics.  Since the times associated with a file.

      ACE4_DELETE
          Operation(s) affected:
              REMOVE
          Discussion:
              Permission intent of having access to delete the file or directory.  See section
              "ACE4_DELETE vs. ACE4_DELETE_CHILD" this
   information is for planning or general diagnosis only, the client and
   server MUST NOT interpret this implementation identity information on how
              these two access mask bits interact.

      ACE4_READ_ACL
          Operation(s) affected:
              GETATTR in
   a way that affects interoperational behavior of acl
          Discussion:
              Permission to read the ACL.

      ACE4_WRITE_ACL
          Operation(s) affected:
              SETATTR implementation.
   The reason is the if clients and servers did such a thing, they might
   use fewer capabilities of acl the protocol than the peer can support, or
   the client and mode
          Discussion:
              Permission server might refuse to write interoperate.

   Because it is likely some implementations will violate the acl protocol
   specification and mode attributes.

      ACE4_WRITE_OWNER
          Operation(s) affected:
              SETATTR interpret the identity information, implementations
   MUST allow the users of owner the NFSv4 client and owner_group
          Discussions:
              Permission server to write set the owner and owner_group attributes.
              On UNIX systems, this is
   contents of the ability to execute chown or
              chgrp.

      ACE4_SYNCHRONIZE
          Operation(s) affected:
              NONE
          Discussion:
              Permission sent nfs_impl_id structure to access file locally at any value.

   Even though these attributes are recommended, if the server with
              synchronized reads and writes.

   The bitmask constants used for supports
   one of them it MUST support the access mask field other.

5.13.  fs_layout_type

   This attribute applies to a file system and indicates what layout
   types are as follows:

      const ACE4_READ_DATA            = 0x00000001;
      const ACE4_LIST_DIRECTORY       = 0x00000001;
      const ACE4_WRITE_DATA           = 0x00000002;
      const ACE4_ADD_FILE             = 0x00000002;
      const ACE4_APPEND_DATA          = 0x00000004;
      const ACE4_ADD_SUBDIRECTORY     = 0x00000004;
      const ACE4_READ_NAMED_ATTRS     = 0x00000008;
      const ACE4_WRITE_NAMED_ATTRS    = 0x00000010;
      const ACE4_EXECUTE              = 0x00000020;
      const ACE4_DELETE_CHILD         = 0x00000040;
      const ACE4_READ_ATTRIBUTES      = 0x00000080;
      const ACE4_WRITE_ATTRIBUTES     = 0x00000100;
      const ACE4_DELETE               = 0x00010000;
      const ACE4_READ_ACL             = 0x00020000;
      const ACE4_WRITE_ACL            = 0x00040000;
      const ACE4_WRITE_OWNER          = 0x00080000;
      const ACE4_SYNCHRONIZE          = 0x00100000;

   Server implementations need not provide the granularity of control
   that is implied supported by the file system.  We expect this list of masks.  For example, POSIX-based
   systems might not distinguish APPEND_DATA (the ability to append to a
   file) from WRITE_DATA (the ability attribute to modify existing contents); both
   masks would
   be tied to queried when a single "write" permission.  When such client encounters a
   server returns attributes to new fsid.  This attribute is
   used by the client, it would show both
   APPEND_DATA and WRITE_DATA if and only client to determine if the write permission is
   enabled.

   If a server receives a SETATTR request that it cannot accurately
   implement, it should error in the direction of more restricted
   access.  For example, suppose a server cannot distinguish overwriting
   data from appending new data, as described in has applicable layout drivers.

5.14.  layout_type

   This attribute indicates the previous paragraph.
   If particular layout type(s) used for a client submits an ACE where APPEND_DATA
   file.  This is for informational purposes only.  The client needs to
   use the LAYOUTGET operation in order to get enough information (e.g.,
   specific device information) in order to perform I/O.

5.15.  layout_hint

   This attribute may be set but WRITE_DATA is
   not (or vice versa), on newly created files to influence the server should reject
   metadata server's choice for the request with
   NFS4ERR_ATTRNOTSUPP.  Nonetheless, if file's layout.  It is suggested that
   this attribute is set as one of the ACE has type DENY, initial attributes within the
   OPEN call.  The metadata server may silently turn on the other bit, so that both APPEND_DATA
   and WRITE_DATA are denied.

5.2.1.  ACE4_DELETE vs. ACE4_DELETE_CHILD

   Two access mask bits govern the ability to delete ignore this attribute.  This
   attribute is a file or directory
   object: ACE4_DELETE on the object itself, and ACE4_DELETE_CHILD on
   the object's parent directory.

   Many systems also consult the "sticky bit" (MODE4_SVTX) and write
   mode bit on sub-set of the parent directory when determining whether layout structure returned by LAYOUTGET.
   For example, instead of specifying particular devices, this would be
   used to allow suggest the stripe width of a
   file file.  It is up to be deleted.  The mode bit for write corresponds the server
   implementation to
   ACE4_WRITE_DATA, determine which is fields within the same physical bit layout it uses.

5.16.  mdsthreshold

   This attribute acts as ACE4_ADD_FILE.
   Therefore, ACE4_ADD_FILE can come into play when determining
   permission a hint to delete.

   In the algorithm below, the strategy client to help it determine when
   it is that ACE4_DELETE and
   ACE4_DELETE_CHILD take precedence over the sticky bit, more efficient to issue read and the sticky
   bit takes precedence over the "write" mode bits (reflected in
   ACE4_ADD_FILE).

   Server implementations SHOULD grant or deny permission write requests to delete
   based on the following algorithm.

          if ACE4_EXECUTE is denied by the parent directory ACL:
              deny delete
          else if ACE4_DELETE is allowed by the target object ACL:
              allow delete
          else if ACE4_DELETE_CHILD is allowed by metadata
   server vs. the parent
          directory ACL:
              allow delete
          else if ACE4_DELETE_CHILD dataserver.  Two types of thresholds are described:
   file size thresholds and I/O size thresholds.  If a file's size is denied by
   smaller than the
          parent directory ACL:
              deny delete
          else if ACE4_ADD_FILE is allowed by file size threshold, data accesses should be issued
   to the parent directory ACL:
              if MODE4_SVTX metadata server.  If an I/O is set for the parent directory:
                  if the principal owns the parent directory OR
                      the principal owns below the target object OR
                      ACE4_WRITE_DATA is allowed by I/O size threshold,
   the target
                      object ACL:
                          allow delete
                      else:
                          deny delete
              else:
                  allow delete
          else:
              deny delete

5.3.  ACE flag

   The "flag" field contains values based on I/O should be issued to the following descriptions.

   ACE4_FILE_INHERIT_ACE
      Can metadata server.  Each threshold can
   be placed on a directory specified independently for read and write requests.  For either
   threshold type, a value of 0 indicates that this ACE no read or write should be
      added
   issued to each new non-directory file created.

   ACE4_DIRECTORY_INHERIT_ACE
      Can be placed on the metadata server, while a directory and value of all 1s indicates that this ACE all
   reads or writes should be
      added issued to each new directory created.

   ACE4_INHERIT_ONLY_ACE
      Can be placed the metadata server.

   The attribute is available on a directory but does not apply to per filehandle basis.  If the directory,
      only current
   filehandle refers to newly created files/directories as specified by the above
      two flags.

   ACE4_NO_PROPAGATE_INHERIT_ACE
      Can be placed on a directory.  Normally when a new directory is
      created and an ACE exists on non-pNFS file or directory, the parent directory which metadata
   server should return an attribute that is marked
      ACE4_DIRECTORY_INHERIT_ACE, two ACEs are placed on the new
      directory.  One for representative of the directory itself and one which
   filehandle's file system.  It is an
      inheritable ACE for newly created directories.  This flag tells suggested that this attribute is
   queried as part of the server OPEN operation.  Due to dynamic system
   changes, the client should not place an ACE on assume that the newly created directory
      which attribute will remain
   constant for any specific time period, thus it should be periodically
   refreshed.

6.  Access Control Lists

   The NFS version 4 ACL attribute is inheritable by subdirectories an array of access control entries
   (ACEs).  Although, the created directory.

   ACE4_SUCCESSFUL_ACCESS_ACE_FLAG

   ACE4_FAILED_ACCESS_ACE_FLAG
      The ACE4_SUCCESSFUL_ACCESS_ACE_FLAG (SUCCESS) and
      ACE4_FAILED_ACCESS_ACE_FLAG (FAILED) flag bits relate only to
      ACE4_SYSTEM_AUDIT_ACE_TYPE (AUDIT) client can read and ACE4_SYSTEM_ALARM_ACE_TYPE
      (ALARM) ACE types.  If during the processing of write the file's ACL, ACL attribute,
   the server encounters an AUDIT or ALARM ACE that matches is responsible for using the
      principal attempting ACL to perform access
   control.  The client can use the OPEN, OPEN or ACCESS operations to check
   access without modifying or reading data or metadata.

   The NFS ACE attribute is defined as follows:

            typedef uint32_t        acetype4;
            typedef uint32_t        aceflag4;
            typedef uint32_t        acemask4;

            struct nfsace4 {
                    acetype4        type;
                    aceflag4        flag;
                    acemask4        access_mask;
                    utf8str_mixed   who;
            };

   To determine if a request succeeds, the server notes processes each nfsace4
   entry in order.  Only ACEs which have a "who" that fact, and matches the
      presence, if any,
   requester are considered.  Each ACE is processed until all of the SUCCESS and FAILED flags encountered in
   bits of the AUDIT or ALARM ACE. requester's access have been ALLOWED.  Once a bit (see
   below) has been ALLOWED by an ACCESS_ALLOWED_ACE, it is no longer
   considered in the server completes processing of later ACEs.  If an ACCESS_DENIED_ACE
   is encountered where the ACL
      processing, requester's access still has unALLOWED bits
   in common with the "access_mask" of the ACE, the request is denied.
   However, unlike the ALLOWED and DENIED ACE types, the share reservation processing, ALARM and AUDIT
   ACE types do not affect a requester's access, and instead are for
   triggering events as a result of a requester's access attempt.

   Therefore, all AUDIT and ALARM ACEs are processed until end of the OPEN
      call, it then notes
   ACL.  When the ACL is fully processed, if there are bits in the OPEN succeeded
   requester's mask that have not been ALLOWED or failed.  If DENIED, access is
   denied.

   This is not intended to limit the OPEN
      succeeded, ability of server implementations
   to implement alternative access policies.  For example:

   o  A server implementation might always grant ACE4_WRITE_ACL and if
      ACE4_READ_ACL permissions.  This would prevent the SUCCESS flag was set for user from
      getting into the situation where they can't ever modify the ACL.

   o  If a matching AUDIT or
      ALARM, file system is mounted read only, then the appropriate AUDIT or ALARM event occurs.  If server may deny
      ACE4_WRITE_DATA even though the ACL grants it.

   As mentioned before, this is one of the reasons that client
   implementations are not recommended to do their own access checks
   based on their interpretation the ACL, but rather use the OPEN failed, and if
   ACCESS to do access checks.  This allows the FAILED flag was set for client to act on the matching AUDIT
   results of having the server determine whether or ALARM, then not access should
   be granted based on its interpretation of the ACL.

   Clients must be aware of situations in which an object's ACL will
   define a certain access even though the server will not enforce it.
   In general, but especially in these situations, the client needs to
   do its part in the enforcement of access as defined by the ACL.  To
   do this, the client may issue the appropriate AUDIT or ALARM event occurs.
      Clearly either or both ACCESS operation prior
   to servicing the request of the SUCCESS user or FAILED can application in order to
   determine whether the user or application should be set, but if
      neither granted the
   access requested.

   Some situations in which the ACL may define accesses that the server
   doesn't enforce:

   o All servers will allow a user the ability to read the data of the
   file when only the execute permission is set, granted (i.e.  If the AUDIT or ALARM ACE ACL
   denies the user the ACE4_READ_DATA access and allows the user
   ACE4_EXECUTE, the server will allow the user to read the data of the
   file).

   o Many servers have the notion of owner-override in which the owner
   of the object is not useful.

      The previously described processing applies allowed to override accesses that are denied by the
   ACL.

   The NFS version 4 ACL model is quite rich.  Some server platforms may
   provide access control functionality that goes beyond the UNIX-style
   mode attribute, but which is not as rich as the NFS ACL model.  So
   that users can take advantage of this more limited functionality, the ACCESS
      operation
   server may indicate that it supports ACLs as well. long as it follows the
   guidelines for mapping between its ACL model and the NFS version 4
   ACL model.

   The difference being situation is complicated by the fact that "success" or
      "failure" does a server may have
   multiple modules that enforce ACLs.  For example, the enforcement for
   NFS version 4 access may be different from the enforcement for local
   access, and both may be different from the enforcement for access
   through other protocols such as SMB.  So it may be useful for a
   server to accept an ACL even if not mean whether ACCESS returns NFS4_OK or not.
      Success means whether ACCESS returns all requested and supported
      bits.  Failure means whether ACCESS failed of its modules are able to return a bit
   support it.

   The guiding principle in all cases is that
      was requested and supported.

   ACE4_IDENTIFIER_GROUP
      Indicates the server must not accept
   ACLs that appear to make the "who" refers file more secure than it really is.

6.1.  ACE type

      Type         Description
      _____________________________________________________
      ALLOW        Explicitly grants the access defined in
                   acemask4 to a GROUP as the file or directory.

      DENY         Explicitly denies the access defined under UNIX in
                   acemask4 to the file or directory.

      AUDIT        LOG (system dependent) any access
                   attempt to a GROUP ACCOUNT as defined under Windows.  Clients and servers
      must ignore file or directory which
                   uses any of the ACE4_IDENTIFIER_GROUP flag on ACEs with access methods specified
                   in acemask4.

      ALARM        Generate a who
      value equal system ALARM (system
                   dependent) when any access attempt is
                   made to one of a file or directory for the special identifiers outlined
                   access methods specified in section
      "ACE who". acemask4.

   A server need not support all of the above ACE types.  The bitmask
   constants used for to represent the flag field above definitions within the
   aclsupport attribute are as follows:

         const ACE4_FILE_INHERIT_ACE ACL4_SUPPORT_ALLOW_ACL    = 0x00000001;
         const ACE4_DIRECTORY_INHERIT_ACE ACL4_SUPPORT_DENY_ACL     = 0x00000002;
         const ACE4_NO_PROPAGATE_INHERIT_ACE ACL4_SUPPORT_AUDIT_ACL    = 0x00000004;
         const ACE4_INHERIT_ONLY_ACE ACL4_SUPPORT_ALARM_ACL    = 0x00000008;

   The semantics of the "type" field follow the descriptions provided
   above.

   The constants used for the type field (acetype4) are as follows:

         const ACE4_SUCCESSFUL_ACCESS_ACE_FLAG ACE4_ACCESS_ALLOWED_ACE_TYPE      = 0x00000010; 0x00000000;
         const ACE4_FAILED_ACCESS_ACE_FLAG ACE4_ACCESS_DENIED_ACE_TYPE       = 0x00000020; 0x00000001;
         const ACE4_IDENTIFIER_GROUP ACE4_SYSTEM_AUDIT_ACE_TYPE        = 0x00000040;

   A server need not support any of these flags.  If the server supports
   flags that are similar to, but not exactly the same as, these flags,
   the implementation may define a mapping between the protocol-defined
   flags and the implementation-defined flags.  Again, the guiding
   principle is that the file 0x00000002;
         const ACE4_SYSTEM_ALARM_ACE_TYPE        = 0x00000003;

   Clients should not appear to be more secure than it
   really is.

   For example, suppose a client tries attempt to set an ACE with
   ACE4_FILE_INHERIT_ACE set but not ACE4_DIRECTORY_INHERIT_ACE.  If unless the server does not claims
   support any form of ACL inheritance, for that ACE type.  If the server
   should receives a request to set
   an ACE that it cannot store, it MUST reject the request with
   NFS4ERR_ATTRNOTSUPP.  If the server
   supports receives a single "inherit ACE" flag that applies request to both files and
   directories, set an ACE
   that it can store but cannot enforce, the server may SHOULD reject the
   request (i.e., requiring with NFS4ERR_ATTRNOTSUPP.

   Example: suppose a server can enforce NFS ACLs for NFS access but
   cannot enforce ACLs for local access.  If arbitrary processes can run
   on the
   client to set both server, then the file and directory inheritance flags).  The server may also accept SHOULD NOT indicate ACL support.  On
   the request and silently turn on other hand, if only trusted administrative programs run locally,
   then the
   ACE4_DIRECTORY_INHERIT_ACE flag.

5.4.  ACE who

   There are several special identifiers ("who") which need server may indicate ACL support.

6.2.  ACE Access Mask

   The access_mask field contains values based on the following:

      ACE4_READ_DATA
         Operation(s) affected:
              READ
              OPEN
         Discussion:
              Permission to be
   understood universally, rather than in read the context of a particular
   DNS domain.  Some data of these identifiers cannot be understood when an
   NFS client accesses the server, but have meaning when file.

              Servers SHOULD allow a local process
   accesses user the file.  The ability to display and modify these
   permissions is permitted over NFS, even if none read the data
              of the access methods
   on file when only the server understands ACE4_EXECUTE access mask bit is
              allowed.

      ACE4_LIST_DIRECTORY
          Operation(s) affected:
              READDIR
          Discussion:
              Permission to list the identifiers.

      Who                    Description
      _______________________________________________________________
      "OWNER"                The owner contents of a directory.

      ACE4_WRITE_DATA
          Operation(s) affected:
              WRITE
              OPEN
          Discussion:
              Permission to modify a file's data anywhere in the file's
              offset range.  This includes the ability to write to any
              arbitrary offset and as a result to grow the file.
      "GROUP"

      ACE4_ADD_FILE
          Operation(s) affected:
              CREATE
              OPEN
          Discussion:
              Permission to add a new file in a directory.  The group associated with the CREATE
              operation is affected when nfs_ftype4 is NF4LNK, NF4BLK,
              NF4CHR, NF4SOCK, or NF4FIFO. (NF4DIR is not listed because
              it is covered by ACE4_ADD_SUBDIRECTORY.) OPEN is affected
              when used to create a regular file.
      "EVERYONE"

      ACE4_APPEND_DATA
          Operation(s) affected:
              WRITE
              OPEN
          Discussion:
               The world, including ability to modify a file's data, but only starting at
               EOF.  This allows for the owner notion of append-only files, by
               allowing ACE4_APPEND_DATA and
                             owning denying ACE4_WRITE_DATA to
               the same user or group.
      "INTERACTIVE"          Accessed from  If a file has an interactive terminal.
      "NETWORK"              Accessed via the network.
      "DIALUP"               Accessed ACL such as the
               one described above and a dialup user to WRITE request is made for
               somewhere other than EOF, the server.
      "BATCH"                Accessed from server SHOULD return
               NFS4ERR_ACCESS.

      ACE4_ADD_SUBDIRECTORY
          Operation(s) affected:
              CREATE
          Discussion:
              Permission to create a batch job.
      "ANONYMOUS"            Accessed without any authentication.
      "AUTHENTICATED"        Any authenticated user (opposite subdirectory in a directory.  The
              CREATE operation is affected when nfs_ftype4 is NF4DIR.

      ACE4_READ_NAMED_ATTRS
          Operation(s) affected:
              OPENATTR
          Discussion:
              Permission to read the named attributes of
                             ANONYMOUS)
      "SERVICE"              Access from a system service.

   To avoid conflict, these special identifiers are distinguish by an
   appended "@" and should appear in file or to
              lookup the form "xxxx@" (note: no domain
   name after named attributes directory.  OPENATTR is
              affected when it is not used to create a named attribute
              directory.  This is when 1.) createdir is TRUE, but a
              named attribute directory already exists, or 2.) createdir
              is FALSE.

      ACE4_WRITE_NAMED_ATTRS
          Operation(s) affected:
              OPENATTR
          Discussion:
              Permission to write the "@").  For example: ANONYMOUS@.

5.4.1.  Discussion named attributes of EVERYONE@

   It a file or
              to create a named attribute directory.  OPENATTR is important
              affected when it is used to note that "EVERYONE@" create a named attribute
              directory.  This is when createdir is TRUE and no named
              attribute directory exists.  The ability to check whether
              or not equivalent a named attribute directory exists depends on the
              ability to look it up, therefore, users also need the
   UNIX "other" entity.
              ACE4_READ_NAMED_ATTRS permission in order to create a
              named attribute directory.

      ACE4_EXECUTE
          Operation(s) affected:
              LOOKUP
              READ
              OPEN
          Discussion:
              Permission to execute a file or traverse/search a
              directory.

              Servers SHOULD allow a user the ability to read the data
              of the file when only the ACE4_EXECUTE access mask bit is
              allowed.  This is because, by definition, UNIX "other"
   does not include because there is no way to execute a
              file without reading the owner or owning group contents.  Though a server may
              treat ACE4_EXECUTE and ACE4_READ_DATA bits identically
              when deciding to permit a READ operation, it SHOULD still
              allow the two bits to be set independently in ACLs, and
              MUST distinguish between them when replying to ACCESS
              operations.  In particular, servers SHOULD NOT silently
              turn on one of the two bits when the other is set, as
              that would make it impossible for the client to correctly
              enforce the distinction between read and execute
              permissions.

                As an example, following a file.  "EVERYONE@"
   means literally everyone, including SETATTR of the owner following ACL:
                        nfsuser:ACE4_EXECUTE:ALLOW

                A subsequent GETATTR of ACL for that file SHOULD return:
                        nfsuser:ACE4_EXECUTE:ALLOW
                Rather than:
                        nfsuser:ACE4_EXECUTE/ACE4_READ_DATA:ALLOW

      ACE4_DELETE_CHILD
          Operation(s) affected:
              REMOVE
          Discussion:
              Permission to delete a file or owning group.

5.4.2.  Discussion directory within a
              directory.  See section "ACE4_DELETE vs.
              ACE4_DELETE_CHILD" for information on how these two access
              mask bits interact.

      ACE4_READ_ATTRIBUTES
          Operation(s) affected:
              GETATTR of OWNER@ and GROUP@ file system object attributes
          Discussion:
              The ACL itself cannot be used ability to determine read basic attributes (non-ACLs) of a file.
              On a UNIX system, basic attributes can be thought of as
              the owner stat level attributes.  Allowing this access mask bit
              would mean the entity can execute "ls -l" and owning group stat.

      ACE4_WRITE_ATTRIBUTES
          Operation(s) affected:

              SETATTR of time_access_set, time_backup,
              time_create, time_modify_set
          Discussion:
              Permission to change the times associated with a file
              or directory to an arbitrary value.  A user having
              ACE4_WRITE_DATA permission, but lacking
              ACE4_WRITE_ATTRIBUTES must be allowed to implicitly set
              the times associated with a file.  This

      ACE4_DELETE
          Operation(s) affected:
              REMOVE
          Discussion:
              Permission to delete the file or directory.  See section
              "ACE4_DELETE vs. ACE4_DELETE_CHILD" for information should be indicated by on how
              these two access mask bits interact.

      ACE4_READ_ACL
          Operation(s) affected:
              GETATTR of acl
          Discussion:
              Permission to read the values ACL.

      ACE4_WRITE_ACL
          Operation(s) affected:
              SETATTR of acl and mode
          Discussion:
              Permission to write the acl and mode attributes.

      ACE4_WRITE_OWNER
          Operation(s) affected:
              SETATTR of owner and owner_group file attributes returned by
          Discussions:
              Permission to write the server.

5.5.  Mode Attribute

   The NFS version 4 mode attribute owner and owner_group attributes.
              On UNIX systems, this is based on the UNIX mode bits. ability to execute chown or
              chgrp.

      ACE4_SYNCHRONIZE
          Operation(s) affected:
              NONE
          Discussion:
              Permission to access file locally at the server with
              synchronized reads and writes.

   The
   following bits bitmask constants used for the access mask field are defined: as follows:

      const MODE4_SUID ACE4_READ_DATA            = 0x800;  /* set user id on execution */ 0x00000001;
      const MODE4_SGID ACE4_LIST_DIRECTORY       = 0x400;  /* set group id on execution */ 0x00000001;
      const MODE4_SVTX ACE4_WRITE_DATA           = 0x200;  /* save text even after use */ 0x00000002;
      const MODE4_RUSR ACE4_ADD_FILE             = 0x100;  /* read permission: owner */ 0x00000002;
      const MODE4_WUSR ACE4_APPEND_DATA          = 0x080;  /* write permission: owner */ 0x00000004;
      const MODE4_XUSR ACE4_ADD_SUBDIRECTORY     = 0x040;  /* execute permission: owner */ 0x00000004;
      const MODE4_RGRP ACE4_READ_NAMED_ATTRS     = 0x020;  /* read permission: group */ 0x00000008;
      const MODE4_WGRP ACE4_WRITE_NAMED_ATTRS    = 0x010;  /* write permission: group */ 0x00000010;
      const MODE4_XGRP ACE4_EXECUTE              = 0x008;  /* execute permission: group */ 0x00000020;
      const MODE4_ROTH ACE4_DELETE_CHILD         = 0x004;  /* read permission: other */ 0x00000040;
      const MODE4_WOTH ACE4_READ_ATTRIBUTES      = 0x002;  /* write permission: other */ 0x00000080;
      const MODE4_XOTH ACE4_WRITE_ATTRIBUTES     = 0x001;  /* execute permission: other */

   Bits MODE4_RUSR, MODE4_WUSR, and MODE4_XUSR apply to the principal
   identified in the owner attribute.  Bits MODE4_RGRP, MODE4_WGRP, and
   MODE4_XGRP apply to the principals identified in the owner_group
   attribute.  Bits MODE4_ROTH, MODE4_WOTH, MODE4_XOTH apply to any
   principal that does 0x00000100;
      const ACE4_DELETE               = 0x00010000;
      const ACE4_READ_ACL             = 0x00020000;
      const ACE4_WRITE_ACL            = 0x00040000;
      const ACE4_WRITE_OWNER          = 0x00080000;
      const ACE4_SYNCHRONIZE          = 0x00100000;

   Server implementations need not match that in provide the owner group, and does not
   have a group matching that granularity of the owner_group attribute.

   The remaining bits are not defined control
   that is implied by this protocol and MUST NOT be
   used.  The minor version mechanism must list of masks.  For example, POSIX-based
   systems might not distinguish APPEND_DATA (the ability to append to a
   file) from WRITE_DATA (the ability to modify existing contents); both
   masks would be used tied to define further bit
   usage.

5.6.  Interaction Between Mode and ACL Attributes

   As defined, there is a certain amount of overlap between ACL single "write" permission.  When such a
   server returns attributes to the client, it would show both
   APPEND_DATA and mode
   file attributes.  Even though there WRITE_DATA if and only if the write permission is overlap, ACLs don't contain
   all
   enabled.

   If a server receives a SETATTR request that it cannot accurately
   implement, it should error in the information specified by direction of more restricted
   access.  For example, suppose a mode and modes can't possibly
   contain all server cannot distinguish overwriting
   data from appending new data, as described in the information specified by previous paragraph.
   If a client submits an ACL.

   For servers ACE where APPEND_DATA is set but WRITE_DATA is
   not (or vice versa), the server should reject the request with
   NFS4ERR_ATTRNOTSUPP.  Nonetheless, if the ACE has type DENY, the
   server may silently turn on the other bit, so that support both mode APPEND_DATA
   and ACL, WRITE_DATA are denied.

6.2.1.  ACE4_DELETE vs. ACE4_DELETE_CHILD

   Two access mask bits govern the mode's MODE4_R*,
   MODE4_W* and MODE4_X* values should be computed from ability to delete a file or directory
   object: ACE4_DELETE on the ACL object itself, and
   should be recomputed upon each SETATTR of ACL.  Similarly, upon
   SETATTR of mode, ACE4_DELETE_CHILD on
   the ACL should be modified in order to allow object's parent directory.

   Many systems also consult the "sticky bit" (MODE4_SVTX) and write
   mode computed from bit on the ACL parent directory when determining whether to allow a
   file to be deleted.  The mode bit for write corresponds to
   ACE4_WRITE_DATA, which is the same physical bit as the mode given ACE4_ADD_FILE.
   Therefore, ACE4_ADD_FILE can come into play when determining
   permission to
   SETATTR.  The mode computed from any given ACL should be
   deterministic.  This means that given an ACL, delete.

   In the same mode will
   always be computed.

   For servers algorithm below, the strategy is that support ACL ACE4_DELETE and not mode, clients may handle
   applications which set
   ACE4_DELETE_CHILD take precedence over the sticky bit, and get the mode by creating sticky
   bit takes precedence over the correct ACL
   to send "write" mode bits (reflected in
   ACE4_ADD_FILE).

   Server implementations SHOULD grant or deny permission to delete
   based on the server and following algorithm.

          if ACE4_EXECUTE is denied by computing the mode from parent directory ACL:
              deny delete
          else if ACE4_DELETE is allowed by the ACL,
   respectively.  In this case, target object ACL:
              allow delete
          else if ACE4_DELETE_CHILD is allowed by the methods used parent
          directory ACL:
              allow delete
          else if ACE4_DELETE_CHILD is denied by the server to keep
          parent directory ACL:
              deny delete
          else if ACE4_ADD_FILE is allowed by the mode in sync with parent directory ACL:
              if MODE4_SVTX is set for the ACL can also be used by parent directory:
                  if the client.  These
   methods are explained in sections Section 5.6.3 Section 5.6.1 and
   Section 5.6.2.

   Since principal owns the mode can't possibly represent all of parent directory OR
                      the information that principal owns the target object OR
                      ACE4_WRITE_DATA is defined allowed by an ACL, there are some discrepencies to be aware of.
   As explained in the section "Deficiencies in a Mode Representation of
   an ACL", the mode bits computed from target
                      object ACL:
                          allow delete
                      else:
                          deny delete
              else:
                  allow delete
          else:
              deny delete

6.3.  ACE flag

   The "flag" field contains values based on the ACL could potentially convey
   more restrictive permissions than what would following descriptions.

   ACE4_FILE_INHERIT_ACE
      Can be granted via the ACL.
   Because of placed on a directory and indicates that this clients are not recommended ACE should be
      added to do their own access
   checks based each new non-directory file created.

   ACE4_DIRECTORY_INHERIT_ACE
      Can be placed on the mode of a file.

   Because the mode attribute includes bits (i.e.  MODE4_SUID,
   MODE4_SGID, MODE4_SVTX) directory and indicates that have nothing this ACE should be
      added to do with ACL semantics,
   it is permitted for clients each new directory created.

   ACE4_INHERIT_ONLY_ACE
      Can be placed on a directory but does not apply to specify both the ACL attribute and
   mode in directory,
      only to newly created files/directories as specified by the same SETATTR operation.  However, because there above
      two flags.

   ACE4_NO_PROPAGATE_INHERIT_ACE
      Can be placed on a directory.  Normally when a new directory is no
   prescribed order for processing
      created and an ACE exists on the attributes in a SETATTR, clients
   may see differing results.  For recommendations parent directory which is marked
      ACE4_DIRECTORY_INHERIT_ACE, two ACEs are placed on how to achieve
   consistent behavior, see Section 5.6.4 the new
      directory.  One for recommendations.

5.6.1.  Recomputing mode upon SETATTR of ACL

   Keeping the mode directory itself and ACL attributes synchronized one which is important, but as
   mentioned previously, the mode cannot possibly represent all of the
   information in the ACL.  Still, the mode should be modified to
   represent an
      inheritable ACE for newly created directories.  This flag tells
      the access as accurately as possible.

   The general algorithm to assign a new mode attribute server to not place an object
   based ACE on a new ACL being set is:

   1.  Walk through the ACEs in order, looking for ACEs with a "who"
       value of OWNER@, GROUP@, or EVERYONE@.

   2.  It newly created directory
      which is understood that ACEs with a "who" value of OWNER@ affect
       the *USR bits inheritable by subdirectories of the mode, GROUP@ affect *GRP bits, created directory.

   ACE4_SUCCESSFUL_ACCESS_ACE_FLAG

   ACE4_FAILED_ACCESS_ACE_FLAG
      The ACE4_SUCCESSFUL_ACCESS_ACE_FLAG (SUCCESS) and EVERYONE@
       affect *USR, *GRP,
      ACE4_FAILED_ACCESS_ACE_FLAG (FAILED) flag bits relate only to
      ACE4_SYSTEM_AUDIT_ACE_TYPE (AUDIT) and *OTH bits.

   3. ACE4_SYSTEM_ALARM_ACE_TYPE
      (ALARM) ACE types.  If such during the processing of the file's ACL,
      the server encounters an ACE specifies ALLOW or DENY for ACE4_READ_DATA,
       ACE4_WRITE_DATA, AUDIT or ACE4_EXECUTE, ALARM ACE that matches the
      principal attempting the OPEN, the server notes that fact, and the mode bits affected have
       not been determined yet, set them to one (if ALLOW) or zero (if
       DENY).

   4.  Upon completion, any mode bits as yet undetermined have a value
      presence, if any, of zero.

   This pseudocode more precisely describes the algorithm:

          /* octal constants for SUCCESS and FAILED flags encountered in
      the mode bits */

          RUSR = 0400
          WUSR = 0200
          XUSR = 0100
          RGRP = 0040
          WGRP = 0020
          XGRP = 0010
          ROTH = 0004
          WOTH = 0002
          XOTH = 0001

         /*
          * old_mode represents AUDIT or ALARM ACE.  Once the previous value
          * of server completes the mode of ACL
      processing, and the object.
          */

          mode_t mode = 0, seen = 0;
          for each ACE a { share reservation processing, and the OPEN
      call, it then notes if a.type is ALLOW the OPEN succeeded or DENY failed.  If the OPEN
      succeeded, and
              ACE4_INHERIT_ONLY_ACE is not set in a.flags {
                  if a.who is OWNER@ {
                      if ((a.mask & ACE4_READ_DATA) &&
                          (! (seen & RUSR))) {
                              seen |= RUSR;
                              if a.type is ALLOW {
                                  mode |= RUSR;
                              }
                      }
                      if ((a.mask & ACE4_WRITE_DATA) &&
                          (! (seen & WUSR))) {
                              seen |= WUSR;
                              if a.type is ALLOW {
                                  mode |= WUSR;
                              }
                      }
                      if ((a.mask & ACE4_EXECUTE) &&
                          (! (seen & XUSR))) {
                              seen |= XUSR;
                              if a.type is ALLOW {
                                  mode |= XUSR;
                              }
                      }
                  } else if a.who is GROUP@ {
                      if ((a.mask & ACE4_READ_DATA) &&
                          (! (seen & RGRP))) {
                              seen |= RGRP;
                              if a.type is ALLOW {
                                  mode |= RGRP;
                              }
                      }
                      if ((a.mask & ACE4_WRITE_DATA) &&
                          (! (seen & WGRP))) {
                              seen |= WGRP;
                              if a.type is ALLOW {
                                  mode |= WGRP;
                              }
                      }
                      if ((a.mask & ACE4_EXECUTE) &&
                          (! (seen & XGRP))) {
                              seen |= XGRP;
                              if a.type is ALLOW {
                                  mode |= XGRP;
                              }
                      }
                  } else if a.who is EVERYONE@ {
                      if (a.mask & ACE4_READ_DATA) {
                          if ! (seen & RUSR) {
                              seen |= RUSR;
                              if a.type is ALLOW {
                                  mode |= RUSR;
                              }
                          }
                          if ! (seen & RGRP) {
                              seen |= RGRP;
                              if a.type is ALLOW {
                                  mode |= RGRP;
                              }
                          }
                          if ! (seen & ROTH) {
                              seen |= ROTH;
                              if a.type is ALLOW {
                                  mode |= ROTH;
                              }
                          }
                      }
                      if (a.mask & ACE4_WRITE_DATA) {
                          if ! (seen & WUSR) {
                              seen |= WUSR;
                              if a.type is ALLOW {
                                  mode |= WUSR;
                              }
                          }
                          if ! (seen & WGRP) {
                              seen |= WGRP;
                              if a.type is ALLOW {
                                  mode |= WGRP;
                              }
                          }
                          if ! (seen & WOTH) {
                              seen |= WOTH;
                              if a.type is ALLOW {
                                  mode |= WOTH;
                              }
                          }
                      }
                      if (a.mask & ACE4_EXECUTE) {
                          if ! (seen & XUSR) {
                              seen |= XUSR;
                              if a.type is ALLOW {
                                  mode |= XUSR;
                              }
                          }
                          if ! (seen & XGRP) {
                              seen |= XGRP;
                              if a.type is ALLOW {
                                  mode |= XGRP;
                              }
                          }
                          if ! (seen & XOTH) {
                              seen |= XOTH; if a.type is ALLOW {
                                  mode |= XOTH;
                              }
                          }
                      }
                  }
              }
          }
          return mode | (old_mode & (SUID | SGID | SVTX))

5.6.2.  Applying the mode given to CREATE SUCCESS flag was set for a matching AUDIT or
      ALARM, then the appropriate AUDIT or ALARM event occurs.  If the
      OPEN to an inherited ACL

   The goal of implementing ACL inheritance is for newly created objects
   to inherit failed, and if the ACLs they were intended to inherit, but without
   disregarding FAILED flag was set for the mode that is given with matching AUDIT
      or ALARM, then the arguments to appropriate AUDIT or ALARM event occurs.
      Clearly either or both of the CREATE SUCCESS or OPEN operations.  The general algorithm FAILED can be set, but if
      neither is as follows:

   1.  Form an ACL on set, the newly created object that AUDIT or ALARM ACE is the concatenation not useful.

      The previously described processing applies to that of the ACCESS
      operation as well.  The difference being that "success" or
      "failure" does not mean whether ACCESS returns NFS4_OK or not.
      Success means whether ACCESS returns all inheritable ACEs from its parent directory.  Note requested and supported
      bits.  Failure means whether ACCESS failed to return a bit that
      was requested and supported.

   ACE4_IDENTIFIER_GROUP
      Indicates that
       there may be zero inheritable ACEs; thus, an object may start
       with an empty ACL.

   2.  For each ACE in the new ACL, adjust its flags if necessary, "who" refers to a GROUP as defined under UNIX
      or a GROUP ACCOUNT as defined under Windows.  Clients and
       possibly create two servers
      must ignore the ACE4_IDENTIFIER_GROUP flag on ACEs in place of one.  This is necessary with a who
      value equal to
       honor the intent one of the inheritance- related flags and to
       preserve information about the original inheritable ACEs special identifiers outlined in the
       case that they will be modified by other steps. section
      "ACE who".

   The algorithm is bitmask constants used for the flag field are as follows:

       A.  If the

      const ACE4_FILE_INHERIT_ACE             = 0x00000001;
      const ACE4_DIRECTORY_INHERIT_ACE        = 0x00000002;
      const ACE4_NO_PROPAGATE_INHERIT_ACE is set, or if     = 0x00000004;
      const ACE4_INHERIT_ONLY_ACE             = 0x00000008;
      const ACE4_SUCCESSFUL_ACCESS_ACE_FLAG   = 0x00000010;
      const ACE4_FAILED_ACCESS_ACE_FLAG       = 0x00000020;
      const ACE4_IDENTIFIER_GROUP             = 0x00000040;

   A server need not support any of these flags.  If the object
           being created is server supports
   flags that are similar to, but not exactly the same as, these flags,
   the implementation may define a directory, then clear mapping between the following
           flags:

              ACE4_NO_PROPAGATE_INHERIT_ACE

              ACE4_FILE_INHERIT_ACE

              ACE4_DIRECTORY_INHERIT_ACE

              ACE4_INHERIT_ONLY_ACE

           Continue on to protocol-defined
   flags and the next ACE.

       B.  If implementation-defined flags.  Again, the object being created guiding
   principle is that the file not appear to be more secure than it
   really is.

   For example, suppose a directory and client tries to set an ACE with
   ACE4_FILE_INHERIT_ACE is set, set but ACE4_DIRECTORY_INHERIT_ACE
           is NOT set, then we ensure that ACE4_INHERIT_ONLY_ACE is set.
           Continue on to the next ACE.  Otherwise:

       C. not ACE4_DIRECTORY_INHERIT_ACE.  If the type
   server does not support any form of ACL inheritance, the ACE is neither ALLOW nor DENY, then
           continue on to server
   should reject the next ACE.

       D.  Copy request with NFS4ERR_ATTRNOTSUPP.  If the original ACE into server
   supports a second, adjacent ACE.

       E.  On the first ACE, ensure single "inherit ACE" flag that ACE4_INHERIT_ONLY_ACE is set.

       F.  On applies to both files and
   directories, the second ACE, clear server may reject the following flags:

              ACE4_NO_PROPAGATE_INHERIT_ACE

              ACE4_FILE_INHERIT_ACE

              ACE4_DIRECTORY_INHERIT_ACE

              ACE4_INHERIT_ONLY_ACE

       G.  On request (i.e., requiring the second ACE, if
   client to set both the type field is ALLOW, an
           implementation MAY clear file and directory inheritance flags).  The
   server may also accept the following mask bits:

              ACE4_WRITE_ACL

              ACE4_WRITE_OWNER

   3.  To ensure that the mode is honored, apply the algorithm for
       applying a mode to a file/directory with an existing ACL request and silently turn on the
       new object as described in Section 5.6.3, using the mode that is
   ACE4_DIRECTORY_INHERIT_ACE flag.

6.4.  ACE who

   There are several special identifiers ("who") which need to be used for file creation.

5.6.3.  Applying a Mode to an Existing ACL

   An existing ACL can mean two things
   understood universally, rather than in this context.  One, that the context of a
   file/directory already exists and it has particular
   DNS domain.  Some of these identifiers cannot be understood when an ACL.  Two, that
   NFS client accesses the server, but have meaning when a
   directory has inheritable ACEs that will make up local process
   accesses the ACL for any new
   files or directories created therein. file.  The high-level goal ability to display and modify these
   permissions is permitted over NFS, even if none of the behavior when a mode is set access methods
   on a file the server understands the identifiers.

      Who                    Description
      _______________________________________________________________
      "OWNER"                The owner of the file.
      "GROUP"                The group associated with
   an existing ACL is to take the new mode into account, without needing
   to delete a pre-existing ACL.

   When a mode is applied to file.
      "EVERYONE"             The world, including the owner and
                             owning group.
      "INTERACTIVE"          Accessed from an object, e.g. interactive terminal.
      "NETWORK"              Accessed via SETATTR or CREATE/OPEN, the ACL must be modified network.
      "DIALUP"               Accessed as a dialup user to accommodate the mode.

   1.  The ACL is traversed, one ACE at server.
      "BATCH"                Accessed from a time.  For each ACE:

       1.  If the type batch job.
      "ANONYMOUS"            Accessed without any authentication.
      "AUTHENTICATED"        Any authenticated user (opposite of
                             ANONYMOUS)
      "SERVICE"              Access from a system service.

   To avoid conflict, these special identifiers are distinguish by an
   appended "@" and should appear in the ACE is neither ALLOW nor DENY, form "xxxx@" (note: no domain
   name after the ACE "@").  For example: ANONYMOUS@.

6.4.1.  Discussion of EVERYONE@

   It is
           left unchanged.  Continue important to the next ACE.

       2.  If the ACE4_INHERIT_ONLY_ACE flag note that "EVERYONE@" is set on not equivalent to the ACE, it
   UNIX "other" entity.  This is
           left unchanged.  Continue to because, by definition, UNIX "other"
   does not include the next ACE.

       3.  If either owner or both owning group of ACE4_FILE_INHERIT_ACE a file.  "EVERYONE@"
   means literally everyone, including the owner or
           ACE4_DIRECTORY_INHERIT_ACE are set:

           1.  A copy owning group.

6.4.2.  Discussion of the ACE is made, OWNER@ and placed in the GROUP@

   The ACL
               immediately following the current ACE.

           2.  In itself cannot be used to determine the first ACE, owner and owning group
   of a file.  This information should be indicated by the flag ACE4_INHERIT_ONLY_ACE is set.

           3.  In values of the second ACE,
   owner and owner_group file attributes returned by the following flags are cleared:

                  ACE4_FILE_INHERIT_ACE

                  ACE4_DIRECTORY_INHERIT_ACE

                  ACE4_NO_PROPAGATE_INHERIT_ACE server.

6.5.  Mode Attribute

   The algorithm continues on with the second ACE.

       4.  If the "who" field NFS version 4 mode attribute is one of the following:

              OWNER@

              GROUP@

              EVERYONE@
           then based on the UNIX mode bits.  The
   following mask bits are cleared:

              ACE4_READ_DATA / ACE4_LIST_DIRECTORY

              ACE4_WRITE_DATA / ACE4_ADD_FILE

              ACE4_APPEND_DATA / ACE4_ADD_SUBDIRECTORY

              ACE4_EXECUTE

           At this point, we proceed defined:

         const MODE4_SUID = 0x800;  /* set user id on execution */
         const MODE4_SGID = 0x400;  /* set group id on execution */
         const MODE4_SVTX = 0x200;  /* save text even after use */
         const MODE4_RUSR = 0x100;  /* read permission: owner */
         const MODE4_WUSR = 0x080;  /* write permission: owner */
         const MODE4_XUSR = 0x040;  /* execute permission: owner */
         const MODE4_RGRP = 0x020;  /* read permission: group */
         const MODE4_WGRP = 0x010;  /* write permission: group */
         const MODE4_XGRP = 0x008;  /* execute permission: group */
         const MODE4_ROTH = 0x004;  /* read permission: other */
         const MODE4_WOTH = 0x002;  /* write permission: other */
         const MODE4_XOTH = 0x001;  /* execute permission: other */

   Bits MODE4_RUSR, MODE4_WUSR, and MODE4_XUSR apply to the next ACE.

       5.  Otherwise, if the "who" field did not match one of OWNER@,
           GROUP@, or EVERYONE@, principal
   identified in the following steps SHOULD be
           performed.

           1.  If owner attribute.  Bits MODE4_RGRP, MODE4_WGRP, and
   MODE4_XGRP apply to the type of principals identified in the ACE is ALLOW, we check owner_group
   attribute.  Bits MODE4_ROTH, MODE4_WOTH, MODE4_XOTH apply to any
   principal that does not match that in the preceding
               ACE (if any).  If it owner group, and does not meet all
   have a group matching that of the following
               criteria:

               1.  The type field is DENY.

               2. owner_group attribute.

   The who field is the same as the current ACE.

               3. remaining bits are not defined by this protocol and MUST NOT be
   used.  The flag minor version mechanism must be used to define further bit ACE4_IDENTIFIER_GROUP
   usage.

6.6.  Interaction Between Mode and ACL Attributes

   As defined, there is the same as it a certain amount of overlap between ACL and mode
   file attributes.  Even though there is in overlap, ACLs don't contain
   all the current ACE, and no other flag bits are
                   set.

               4.  The mask bits are information specified by a subset of mode and modes can't possibly
   contain all the mask bits of information specified by an ACL.

   For servers that support both mode and ACL, the
                   current ACE, mode's MODE4_R*,
   MODE4_W* and are also a subset of MODE4_X* values should be computed from the following:

                      ACE4_READ_DATA / ACE4_LIST_DIRECTORY

                      ACE4_WRITE_DATA / ACE4_ADD_FILE

                      ACE4_APPEND_DATA / ACE4_ADD_SUBDIRECTORY

                      ACE4_EXECUTE

               then an ACE ACL and
   should be recomputed upon each SETATTR of type DENY, with a who equal to ACL.  Similarly, upon
   SETATTR of mode, the current
               ACE, flag bits equal to (<current-ACE-flags> &
               ACE4_IDENTIFIER_GROUP), and no mask bits, is prepended.

           2.  The following modifications are made ACL should be modified in order to allow the prepended
               ACE.  The intent is
   mode computed from the ACL to mask be the following ACE same as the mode given to disallow
               ACE4_READ_DATA, ACE4_WRITE_DATA, ACE4_APPEND_DATA, or
               ACE4_EXECUTE, based upon
   SETATTR.  The mode computed from any given ACL should be
   deterministic.  This means that given an ACL, the group permissions of same mode will
   always be computed.

   For servers that support ACL and not mode, clients may handle
   applications which set and get the new
               mode.  As a special case, if mode by creating the ACE matches correct ACL
   to send to the current
               owner of server and by computing the file, mode from the owner bits are used, rather than ACL,
   respectively.  In this case, the group bits.  This is reflected methods used by the server to keep
   the mode in sync with the algorithm
               below.

          Let there ACL can also be three bits defined:

          #define READ    04
          #define WRITE   02
          #define EXEC    01

          Let "amode" be the new mode, right-shifted three
          bits, in order to have used by the group permission bits
          placed client.  These
   methods are explained in Section 6.6.3, Section 6.6.1, and
   Section 6.6.2.

   Since the three low order bits of amode,
          i.e. amode = mode >> 3

          If ACE4_IDENTIFIER_GROUP can't possibly represent all of the information that
   is not set defined by an ACL, there are some discrepencies to be aware of.
   As explained in the flags,
          and the "who" field section "Deficiencies in a Mode Representation of
   an ACL", the ACE matches the owner
          of mode bits computed from the file, we shift amode three ACL could potentially convey
   more bits, in
          order to have the owner permission bits placed in restrictive permissions than what would be granted via the three low order bits ACL.
   Because of amode:

          amode = amode >> 3

          amode is now used as follows:

          If ACE4_READ_DATA is set this clients are not recommended to do their own access
   checks based on the current ACE:
                     If READ is set on amode:
                         ACE4_READ_DATA is cleared on mode of a file.

   Because the prepended ACE
                     else:
                         ACE4_READ_DATA mode attribute includes bits (i.e.  MODE4_SUID,
   MODE4_SGID, MODE4_SVTX) that have nothing to do with ACL semantics,
   it is set on permitted for clients to specify both the prepended ACE

              If ACE4_WRITE_DATA is set on ACL attribute and
   mode in the current ACE:
                     If WRITE is set on amode:
                         ACE4_WRITE_DATA same SETATTR operation.  However, because there is cleared on no
   prescribed order for processing the prepended ACE
                     else:
                         ACE4_WRITE_DATA is set attributes in a SETATTR, clients
   may see differing results.  For recommendations on how to achieve
   consistent behavior, see Section 6.6.4 for recommendations.

6.6.1.  Recomputing mode upon SETATTR of ACL

   Keeping the prepended ACE
              If ACE4_APPEND_DATA mode and ACL attributes synchronized is set on important, but as
   mentioned previously, the current ACE:
                     If WRITE is set on amode:
                         ACE4_APPEND_DATA is cleared on mode cannot possibly represent all of the
                         prepended ACE
                     else:
                         ACE4_APPEND_DATA is set on
   information in the prepended ACE

              If ACE4_EXECUTE is set on ACL.  Still, the current ACE:
                     If EXEC is set on amode:
                         ACE4_EXECUTE is cleared on mode should be modified to
   represent the prepended ACE
                     else:
                         ACE4_EXECUTE is set access as accurately as possible.

   The general algorithm to assign a new mode attribute to an object
   based on a new ACL being set is:

   1.  Walk through the prepended ACE
           3.  To conform ACEs in order, looking for ACEs with POSIX, and prevent cases where the owner a "who"
       value of the file is given permissions via an explicit group,
               we implement the following step.

                  If ACE4_IDENTIFIER_GROUP OWNER@, GROUP@, or EVERYONE@.

   2.  It is set in the flags field understood that ACEs with a "who" value of OWNER@ affect
       the ALLOW ACE:
                      Let "mode" be the mode that we are chmoding to:
                          extramode = (mode >> 3) & 07
                          ownermode = mode >> 6
                          extramode &= ~ownermode
                      If extramode is not zero:
                          If extramode & READ:
                              Clear ACE4_READ_DATA in both *USR bits of the
                              prepended DENY ACE mode, GROUP@ affect *GRP bits, and the ALLOW ACE
                          If extramode & WRITE:
                              Clear ACE4_WRITE_DATA EVERYONE@
       affect *USR, *GRP, and ACE_APPEND_DATA
                              in both the prepended DENY *OTH bits.

   3.  If such an ACE and the specifies ALLOW ACE
                      If extramode & EXEC:
                              Clear ACE4_EXECUTE in both the prepended or DENY ACE for ACE4_READ_DATA,
       ACE4_WRITE_DATA, or ACE4_EXECUTE, and the ALLOW ACE

   2.  If there are at least six ACEs, the final six ACEs are examined.
       If they are mode bits affected have
       not equal to the following ACEs:

          A1) OWNER@:::DENY
          A2) OWNER@:ACE4_WRITE_ACL/ACE4_WRITE_OWNER/
              ACE4_WRITE_ATTRIBUTES/ACE4_WRITE_NAMED_ATTRIBUTES::ALLOW
          A3) GROUP@::ACE4_IDENTIFIER_GROUP:DENY
          A4) GROUP@::ACE4_IDENTIFIER_GROUP:ALLOW
          A5) EVERYONE@:ACE4_WRITE_ACL/ACE4_WRITE_OWNER/
              ACE4_WRITE_ATTRIBUTES/ACE4_WRITE_NAMED_ATTRIBUTES::DENY
          A6) EVERYONE@:ACE4_READ_ACL/ACE4_READ_ATTRIBUTES/
              ACE4_READ_NAMED_ATTRIBUTES/ACE4_SYNCHRONIZE::ALLOW

       Then six ACEs matching the above are appended.

   3.  The final six ACEs are adjusted according been determined yet, set them to one (if ALLOW) or zero (if
       DENY).

   4.  Upon completion, any mode bits as yet undetermined have a value
       of zero.

   This pseudocode more precisely describes the incoming mode. algorithm:

          /* octal constants for the mode bits */

          RUSR = 0400
          WUSR = 0200
          XUSR = 0100
          RGRP = 0040
          WGRP = 0020
          XGRP = 0010
          ROTH = 0004
          WOTH = 0002
          XOTH = 0001

          If RUSR is set: set ACE4_READ_DATA in A2
              else: set ACE4_READ_DATA in A1
          If WUSR

         /*
          * old_mode represents the previous value
          * of the mode of the object.
          */
          mode_t mode = 0, seen = 0;
          for each ACE a {
              if a.type is set: set ACE4_WRITE_DATA and ACE4_APPEND_DATA in A2
              else: set ACE4_WRITE_DATA ALLOW or DENY and ACE4_APPEND_DATA in A1
          If XUSR
              ACE4_INHERIT_ONLY_ACE is set: set ACE4_EXECUTE in A2
              else: not set ACE4_EXECUTE in A1
          If RGRP a.flags {
                  if a.who is set: set ACE4_READ_DATA in A4
              else: set ACE4_READ_DATA in A3
          If WGRP OWNER@ {
                      if ((a.mask & ACE4_READ_DATA) &&
                          (! (seen & RUSR))) {
                              seen |= RUSR;
                              if a.type is set: set ACE4_WRITE_DATA and ACE4_APPEND_DATA in A4
              else: set ACE4_WRITE_DATA and ACE4_APPEND_DATA in A3
          If XGRP ALLOW {
                                  mode |= RUSR;
                              }
                      }
                      if ((a.mask & ACE4_WRITE_DATA) &&
                          (! (seen & WUSR))) {
                              seen |= WUSR;
                              if a.type is set: set ACE4_EXECUTE in A4
              else: set ACE4_EXECUTE in A3
          If ROTH ALLOW {
                                  mode |= WUSR;
                              }
                      }
                      if ((a.mask & ACE4_EXECUTE) &&
                          (! (seen & XUSR))) {
                              seen |= XUSR;
                              if a.type is set: set ACE4_READ_DATA in A6
              else: set ACE4_READ_DATA in A5
          If WOTH ALLOW {
                                  mode |= XUSR;
                              }
                      }
                  } else if a.who is set: set ACE4_WRITE_DATA and ACE4_APPEND_DATA in A6
              else: set ACE4_WRITE_DATA and ACE4_APPEND_DATA in A5
          If XOTH GROUP@ {
                      if ((a.mask & ACE4_READ_DATA) &&
                          (! (seen & RGRP))) {
                              seen |= RGRP;
                              if a.type is set: set ACE4_EXECUTE in A6
              else: set ACE4_EXECUTE in A5

5.6.4.  ACL and mode in the same SETATTR

   The only reason that a ALLOW {
                                  mode and ACL should be set in the same SETATTR |= RGRP;
                              }
                      }
                      if ((a.mask & ACE4_WRITE_DATA) &&
                          (! (seen & WGRP))) {
                              seen |= WGRP;
                              if a.type is ALLOW {
                                  mode |= WGRP;
                              }
                      }
                      if the user wants to set the SUID, SGID and SVTX bits along with
   setting the permissions by means of an ACL.  There ((a.mask & ACE4_EXECUTE) &&
                          (! (seen & XGRP))) {
                              seen |= XGRP;
                              if a.type is still no way to
   enforce which order the attributes will be set in, and it ALLOW {
                                  mode |= XGRP;
                              }
                      }
                  } else if a.who is likely
   that different orders of operations will produce different results.

5.6.4.1.  Client Side Recommendations

   If an application needs to enforce a certain behavior, it EVERYONE@ {
                      if (a.mask & ACE4_READ_DATA) {
                          if ! (seen & RUSR) {
                              seen |= RUSR;
                              if a.type is
   recommended that the client implementations set ALLOW {
                                  mode and ACL in
   separate SETATTR requests.  This will produce consistent and expected
   results.

   If an application wants to set SUID, SGID and SVTX bits and an ACL:

      In the first SETATTR, set the |= RUSR;
                              }
                          }
                          if ! (seen & RGRP) {
                              seen |= RGRP;
                              if a.type is ALLOW {
                                  mode with SUID, |= RGRP;
                              }
                          }
                          if ! (seen & ROTH) {
                              seen |= ROTH;
                              if a.type is ALLOW {
                                  mode |= ROTH;
                              }
                          }
                      }
                      if (a.mask & ACE4_WRITE_DATA) {
                          if ! (seen & WUSR) {
                              seen |= WUSR;
                              if a.type is ALLOW {
                                  mode |= WUSR;
                              }
                          }
                          if ! (seen & WGRP) {
                              seen |= WGRP;
                              if a.type is ALLOW {
                                  mode |= WGRP;
                              }
                          }
                          if ! (seen & WOTH) {
                              seen |= WOTH;
                              if a.type is ALLOW {
                                  mode |= WOTH;
                              }
                          }
                      }
                      if (a.mask & ACE4_EXECUTE) {
                          if ! (seen & XUSR) {
                              seen |= XUSR;
                              if a.type is ALLOW {
                                  mode |= XUSR;
                              }
                          }
                          if ! (seen & XGRP) {
                              seen |= XGRP;
                              if a.type is ALLOW {
                                  mode |= XGRP;
                              }
                          }
                          if ! (seen & XOTH) {
                              seen |= XOTH;
                              if a.type is ALLOW {
                                  mode |= XOTH;
                              }
                          }
                      }
                  }
              }
          }
          return mode | (old_mode & (SUID | SGID and SVTX bits
      as desired and all other bits with a value of 0.

      In a following SETATTR (preferably in the same COMPOUND) set | SVTX))

6.6.2.  Applying the
      ACL.

5.6.4.2.  Server Side Recommendations

   If both mode and ACL are given to SETATTR, server implementations
   should verify that the mode and CREATE or OPEN to an inherited ACL don't conflict, i.e. the mode
   computed from the given

   The goal of implementing ACL must be inheritance is for newly created objects
   to inherit the same as ACLs they were intended to inherit, but without
   disregarding the mode that is given mode,
   excluding with the SUID, SGID and SVTX bits. arguments to the CREATE
   or OPEN operations.  The general algorithm for assigning
   a new mode based is as follows:

   1.  Form an ACL on the ACL can be used.  (This newly created object that is described in
   section Section 5.6.1.)  If a server receives a request to set both
   mode and ACL, but the two conflict, the server should return
   NFS4ERR_INVAL.

5.6.5.  Inheritance and turning it off

   The inheritance concatenation
       of access permissions may be problematic if a user
   cannot prevent their file all inheritable ACEs from inheriting unwanted permissions.  For
   example, a user, "bob", sets up a shared project directory to be used
   by everyone working on Project Foo. "alice" is a part of Project Foo,
   but is working on something its parent directory.  Note that should not
       there may be seen by anyone else.
   How can "alice" make sure that any new files that she creates zero inheritable ACEs; thus, an object may start
       with an empty ACL.

   2.  For each ACE in this
   shared project directory do not inherit anything that could
   compromise the security new ACL, adjust its flags if necessary, and
       possibly create two ACEs in place of her work?

   More relevant one.  This is necessary to
       honor the implementors intent of NFS version 4 clients and
   servers is the question of how inheritance- related flags and to communicate
       preserve information about the fact original inheritable ACEs in the
       case that user
   "alice" doesn't want any permissions to they will be inherited to her newly
   created file modified by other steps.  The algorithm is
       as follows:

       A.  If the ACE4_NO_PROPAGATE_INHERIT_ACE is set, or directory.

   To do this, implementors should standardize if the object
           being created is not a directory, then clear the following
           flags:

              ACE4_NO_PROPAGATE_INHERIT_ACE

              ACE4_FILE_INHERIT_ACE

              ACE4_DIRECTORY_INHERIT_ACE
              ACE4_INHERIT_ONLY_ACE

           Continue on what to the behavior of
   CREATE next ACE.

       B.  If the object being created is a directory and OPEN must be if:

   1.  just mode
           ACE4_FILE_INHERIT_ACE is given

       In this case, inheritance will take place, set, but the mode will be
       applied ACE4_DIRECTORY_INHERIT_ACE
           is NOT set, then we ensure that ACE4_INHERIT_ONLY_ACE is set.
           Continue on to the inherited ACL as described in Section 5.6.1,
       thereby modifying next ACE.  Otherwise:

       C.  If the ACL.

   2.  just ACL type of the ACE is given

       In this case, inheritance will not take place, and neither ALLOW nor DENY, then
           continue on to the ACL as
       defined in next ACE.

       D.  Copy the CREATE or OPEN will be set without modification.

   3.  both mode and ACL are given

       In this case, implementors should verify original ACE into a second, adjacent ACE.

       E.  On the first ACE, ensure that ACE4_INHERIT_ONLY_ACE is set.

       F.  On the mode and ACL
       don't conflict, i.e. second ACE, clear the mode computed from following flags:

              ACE4_NO_PROPAGATE_INHERIT_ACE

              ACE4_FILE_INHERIT_ACE

              ACE4_DIRECTORY_INHERIT_ACE

              ACE4_INHERIT_ONLY_ACE

       G.  On the given ACL must be second ACE, if the same as type field is ALLOW, an
           implementation MAY clear the following mask bits:

              ACE4_WRITE_ACL

              ACE4_WRITE_OWNER

   3.  To ensure that the mode is honored, apply the given mode.  The algorithm for assigning
       applying a new mode based to a file/directory with an existing ACL on the ACL can be used.  This is
       new object as described in Section 5.6.1) If a server receives a request to set both mode
       and ACL, but the two conflict, the server should return
       NFS4ERR_INVAL.  If the mode and ACL don't conflict, inheritance
       will not take place and both, 6.6.3, using the mode and ACL, will that is
       to be set
       without modification.

   4.  neither mode nor used for file creation.

6.6.3.  Applying a Mode to an Existing ACL are given

       In

   An existing ACL can mean two things in this case, inheritance will take place context.  One, that a
   file/directory already exists and no modifications to
       the ACL will happen.  It is worth noting it has an ACL.  Two, that if no a
   directory has inheritable ACEs exist on the parent directory, the file that will be make up the ACL for any new
   files or directories created with
       an empty ACL, thus granting no accesses.

5.6.6.  Deficiencies in a Mode Representation therein.

   The high-level goal of an ACL

   In the presence of an ACL, there are certain cases behavior when the
   representation of the a mode is not guaranteed to be accurate.  An
   example of set on a situation file with
   an existing ACL is detailed below.

   As mentioned in Section 5.6, the representation of to take the new mode is
   deterministic, but not guaranteed into account, without needing
   to be accurate.  The mode bits
   potentially convey delete a more restrictive permission than what will
   actually be granted via the pre-existing ACL.

   Given the following ACL of two ACEs:

          GROUP@:ACE4_READ_DATA/ACE4_WRITE_DATA/ACE4_EXECUTE:
              ACE4_IDENTIFIER_GROUP:ALLOW
          EVERYONE@:ACE4_READ_DATA/ACE4_WRITE_DATA/ACE4_EXECUTE::DENY

   we would compute

   When a mode of 0070.  However, it is possible, even
   likely, that the owner might be a member of the object's owning
   group, and thus, the owner would be granted read, write, and execute
   access applied to the object.  This would conflict with the mode of 0070,
   where an owner would be denied this access.

   The only way to overcome this deficiency would object, e.g. via SETATTR or CREATE/OPEN,
   the ACL must be modified to determine
   whether accommodate the object's owner mode.

   1.  The ACL is traversed, one ACE at a member time.  For each ACE:

       1.  If the type of the object's owning group.
   This is difficult, but worse, on a POSIX or any UNIX-like system, it ACE is a process' membership in a group that neither ALLOW nor DENY, the ACE is important, not a user's.
   Thus, any fixed mode intended
           left unchanged.  Continue to represent the above ACL can be
   incorrect.

   Example: administrative databases (possibly /etc/passwd and /etc/
   group) indicate that next ACE.

       2.  If the user "bob" ACE4_INHERIT_ONLY_ACE flag is a member of the group "staff".
   An object has set on the ACL given above, ACE, it is owned by "bob", and has an
   owning group
           left unchanged.  Continue to the next ACE.

       3.  If either or both of ACE4_FILE_INHERIT_ACE or
           ACE4_DIRECTORY_INHERIT_ACE are set:

           1.  A copy of "staff".  User "bob" has logged into the system, and
   thus processes have been created owned by "bob" ACE is made, and having membership placed in group "staff".

   A mode representation of the above ACL could thus be 0770, due to
   user "bob" having membership in group "staff".  Now,
               immediately following the
   administrative databases are changed, such that user "bob" is no
   longer in group "staff".  User "bob" logs in to current ACE.

           2.  In the system again, and
   thus more processes are created, this time owned by "bob" but NOT in
   group "staff".

   A mode of 0770 first ACE, the flag ACE4_INHERIT_ONLY_ACE is inaccurate for processes not belonging to group
   "staff".  But even if set.

           3.  In the mode of second ACE, the file were proactively changed
   to 0070 at following flags are cleared:

                  ACE4_FILE_INHERIT_ACE

                  ACE4_DIRECTORY_INHERIT_ACE

                  ACE4_NO_PROPAGATE_INHERIT_ACE

           The algorithm continues on with the time second ACE.

       4.  If the group database was edited, mode 0070 would be
   inaccurate for "who" field is one of the pre-existing processes owned by user "bob" and
   having membership in group "staff".

6.  Single-server Name Space

   This chapter describes following:

              OWNER@

              GROUP@

              EVERYONE@

           then the NFSv4 single-server name space.  Single-
   server namespaces may be presented directly to clients, or they may
   be used as a basis to form larger multi-server namespaces (e.g. site-
   wide or organization-wide) to be presented following mask bits are cleared:

              ACE4_READ_DATA / ACE4_LIST_DIRECTORY

              ACE4_WRITE_DATA / ACE4_ADD_FILE

              ACE4_APPEND_DATA / ACE4_ADD_SUBDIRECTORY

              ACE4_EXECUTE

           At this point, we proceed to clients, as described
   in Section 12.

6.1.  Server Exports

   On a UNIX server, the name space describes all the files reachable by
   pathnames under next ACE.

       5.  Otherwise, if the root directory "who" field did not match one of OWNER@,
           GROUP@, or "/".  On a Windows NT server
   the name space constitutes all EVERYONE@, the files on disks named by mapped
   disk letters.  NFS server administrators rarely make following steps SHOULD be
           performed.

           1.  If the entire
   server's filesystem name space available to NFS clients.  More often
   portions type of the name space are made available via an "export"
   feature.  In previous versions ACE is ALLOW, we check the preceding
               ACE (if any).  If it does not meet all of the NFS protocol, following
               criteria:

               1.  The type field is DENY.

               2.  The who field is the root
   filehandle for each export same as the current ACE.

               3.  The flag bit ACE4_IDENTIFIER_GROUP is obtained through the MOUNT protocol; same as it
                   is in the client sends current ACE, and no other flag bits are
                   set.

               4.  The mask bits are a string that identifies subset of the export mask bits of name space
   and the server returns
                   current ACE, and are also a subset of the root filehandle for it.  The MOUNT
   protocol supports following:

                      ACE4_READ_DATA / ACE4_LIST_DIRECTORY

                      ACE4_WRITE_DATA / ACE4_ADD_FILE

                      ACE4_APPEND_DATA / ACE4_ADD_SUBDIRECTORY

                      ACE4_EXECUTE

               then an EXPORTS procedure that will enumerate the
   server's exports.

6.2.  Browsing Exports

   The NFS version 4 protocol provides ACE of type DENY, with a root filehandle that clients
   can use who equal to obtain filehandles for the exports of a particular server,
   via a series of LOOKUP operations within a COMPOUND, current
               ACE, flag bits equal to traverse a
   path.  A common user experience (<current-ACE-flags> &
               ACE4_IDENTIFIER_GROUP), and no mask bits, is to use a graphical user interface
   (perhaps a file "Open" dialog window) to find a file via progressive
   browsing through a directory tree. prepended.

           2.  The client must be able to move
   from one export following modifications are made to another export via single-component, progressive
   LOOKUP operations.

   This style of browsing is not well supported by the NFS version 2 and
   3 protocols. prepended
               ACE.  The client expects all LOOKUP operations intent is to remain
   within a single server filesystem.  For example, mask the device attribute
   will not change.  This prevents a client from taking name space paths
   that span exports.

   An automounter on following ACE to disallow
               ACE4_READ_DATA, ACE4_WRITE_DATA, ACE4_APPEND_DATA, or
               ACE4_EXECUTE, based upon the client can obtain a snapshot group permissions of the server's
   name space using the EXPORTS procedure of new
               mode.  As a special case, if the MOUNT protocol.  If it
   understands ACE matches the server's pathname syntax, it can create an image current
               owner of the server's name space on the client.  The parts of file, the name space
   that owner bits are not exported by used, rather than
               the server are filled group bits.  This is reflected in with a "pseudo
   filesystem" that allows the user to browse from one mounted
   filesystem to another.  There is a drawback algorithm
               below.

          Let there be three bits defined:

          #define READ    04
          #define WRITE   02
          #define EXEC    01

          Let "amode" be the new mode, right-shifted three
          bits, in order to this representation of have the server's name space on group permission bits
          placed in the client: it is static. three low order bits of amode,
          i.e. amode = mode >> 3

          If ACE4_IDENTIFIER_GROUP is not set in the server
   administrator adds a new export flags,
          and the client will be unaware "who" field of it.

6.3.  Server Pseudo Filesystem

   NFS version 4 servers avoid this name space inconsistency by
   presenting all the exports for a given server within ACE matches the framework of
   a single namespace, for that server.  An NFS version 4 client uses
   LOOKUP and READDIR operations to browse seamlessly from one export to
   another.  Portions owner
          of the server name space that are not exported are
   bridged via a "pseudo filesystem" that provides a view of exported
   directories only.  A pseudo filesystem has a unique fsid and behaves
   like a normal, read only filesystem.

   Based on the construction of the server's name space, it is possible
   that multiple pseudo filesystems may exist.  For example,

           /a              pseudo filesystem
           /a/b            real filesystem
           /a/b/c          pseudo filesystem
           /a/b/c/d        real filesystem

   Each of the pseudo filesystems are considered separate entities and
   therefore will file, we shift amode three more bits, in
          order to have its own unique fsid.

6.4.  Multiple Roots

   The DOS and Windows operating environments are sometimes described as
   having "multiple roots".  Filesystems are commonly represented as
   disk letters.  MacOS represents filesystems as top level names.  NFS
   version 4 servers for these platforms can construct a pseudo file
   system above these root names so that disk letters or volume names
   are simply directory names the owner permission bits placed in
          the pseudo root.

6.5.  Filehandle Volatility

   The nature three low order bits of amode:

          amode = amode >> 3

          amode is now used as follows:

          If ACE4_READ_DATA is set on the server's pseudo filesystem current ACE:
                     If READ is that it set on amode:
                         ACE4_READ_DATA is a logical
   representation of filesystem(s) available from cleared on the server.
   Therefore, prepended ACE
                     else:
                         ACE4_READ_DATA is set on the pseudo filesystem prepended ACE

              If ACE4_WRITE_DATA is most likely constructed
   dynamically when set on the server current ACE:
                     If WRITE is first instantiated.  It set on amode:
                         ACE4_WRITE_DATA is expected
   that cleared on the pseudo filesystem may not have an prepended ACE
                     else:
                         ACE4_WRITE_DATA is set on disk counterpart from
   which persistent filehandles could be constructed.  Even though it the prepended ACE
              If ACE4_APPEND_DATA is
   preferable that set on the server provide persistent filehandles for current ACE:
                     If WRITE is set on amode:
                         ACE4_APPEND_DATA is cleared on the
   pseudo filesystem,
                         prepended ACE
                     else:
                         ACE4_APPEND_DATA is set on the NFS client should expect that pseudo file
   system filehandles are volatile.  This can be confirmed by checking prepended ACE

              If ACE4_EXECUTE is set on the associated "fh_expire_type" attribute for those filehandles in
   question. current ACE:
                     If EXEC is set on amode:
                         ACE4_EXECUTE is cleared on the filehandles are volatile, prepended ACE
                     else:
                         ACE4_EXECUTE is set on the NFS client must be
   prepared to recover a filehandle value (e.g. prepended ACE

           3.  To conform with a series of LOOKUP
   operations) when receiving an error POSIX, and prevent cases where the owner
               of NFS4ERR_FHEXPIRED.

6.6.  Exported Root

   If the server's root filesystem is exported, one might conclude that
   a pseudo-filesystem file is unneeded.  This not necessarily so.  Assume given permissions via an explicit group,
               we implement the following filesystems on a server:

           /       disk1  (exported)
           /a      disk2  (not exported)
           /a/b    disk3  (exported)

   Because disk2 step.

                  If ACE4_IDENTIFIER_GROUP is not exported, disk3 cannot be reached with simple
   LOOKUPs.  The server must bridge the gap with a pseudo-filesystem.

6.7.  Mount Point Crossing

   The server filesystem environment may be constructed set in such a way
   that one filesystem contains a directory which is 'covered' or
   mounted upon by a second filesystem.  For example:

           /a/b            (filesystem 1)
           /a/b/c/d        (filesystem 2)

   The pseudo filesystem for this server may be constructed to look
   like:

           /               (place holder/not exported)
           /a/b            (filesystem 1)
           /a/b/c/d        (filesystem 2)

   It is the server's responsibility to present flags field of
                  the pseudo filesystem ALLOW ACE:
                      Let "mode" be the mode that we are chmoding to:
                          extramode = (mode >> 3) & 07
                          ownermode = mode >> 6
                          extramode &= ~ownermode
                      If extramode is complete to the client. not zero:
                          If extramode & READ:
                              Clear ACE4_READ_DATA in both the client sends a lookup request
   for
                              prepended DENY ACE and the path "/a/b/c/d", ALLOW ACE
                          If extramode & WRITE:
                              Clear ACE4_WRITE_DATA and ACE_APPEND_DATA
                              in both the server's response is prepended DENY ACE and the filehandle of
                              ALLOW ACE
                      If extramode & EXEC:
                              Clear ACE4_EXECUTE in both the filesystem "/a/b/c/d".  In previous versions of prepended
                              DENY ACE and the NFS protocol, ALLOW ACE

   2.  If there are at least six ACEs, the server would respond with final six ACEs are examined.
       If they are not equal to the filehandle of directory "/a/b/c/d"
   within following ACEs:

          A1) OWNER@:::DENY
          A2) OWNER@:ACE4_WRITE_ACL/ACE4_WRITE_OWNER/
              ACE4_WRITE_ATTRIBUTES/ACE4_WRITE_NAMED_ATTRIBUTES::ALLOW
          A3) GROUP@::ACE4_IDENTIFIER_GROUP:DENY
          A4) GROUP@::ACE4_IDENTIFIER_GROUP:ALLOW
          A5) EVERYONE@:ACE4_WRITE_ACL/ACE4_WRITE_OWNER/
              ACE4_WRITE_ATTRIBUTES/ACE4_WRITE_NAMED_ATTRIBUTES::DENY
          A6) EVERYONE@:ACE4_READ_ACL/ACE4_READ_ATTRIBUTES/
              ACE4_READ_NAMED_ATTRIBUTES/ACE4_SYNCHRONIZE::ALLOW

       Then six ACEs matching the filesystem "/a/b". above are appended.

   3.  The NFS client will be able final six ACEs are adjusted according to determine if it crosses a server mount
   point by a change in the value of incoming mode.

          /* octal constants for the "fsid" attribute.

6.8.  Security Policy mode bits */

          RUSR = 0400
          WUSR = 0200
          XUSR = 0100
          RGRP = 0040
          WGRP = 0020
          XGRP = 0010
          ROTH = 0004
          WOTH = 0002
          XOTH = 0001

          If RUSR is set: set ACE4_READ_DATA in A2
              else: set ACE4_READ_DATA in A1
          If WUSR is set: set ACE4_WRITE_DATA and Name Space Presentation

   The application of ACE4_APPEND_DATA in A2
              else: set ACE4_WRITE_DATA and ACE4_APPEND_DATA in A1
          If XUSR is set: set ACE4_EXECUTE in A2
              else: set ACE4_EXECUTE in A1
          If RGRP is set: set ACE4_READ_DATA in A4
              else: set ACE4_READ_DATA in A3
          If WGRP is set: set ACE4_WRITE_DATA and ACE4_APPEND_DATA in A4
              else: set ACE4_WRITE_DATA and ACE4_APPEND_DATA in A3
          If XGRP is set: set ACE4_EXECUTE in A4
              else: set ACE4_EXECUTE in A3
          If ROTH is set: set ACE4_READ_DATA in A6
              else: set ACE4_READ_DATA in A5
          If WOTH is set: set ACE4_WRITE_DATA and ACE4_APPEND_DATA in A6
              else: set ACE4_WRITE_DATA and ACE4_APPEND_DATA in A5
          If XOTH is set: set ACE4_EXECUTE in A6
              else: set ACE4_EXECUTE in A5

6.6.4.  ACL and mode in the server's security policy needs to same SETATTR

   The only reason that a mode and ACL should be carefully
   considered by the implementor.  One may choose to limit the
   viewability of portions of the pseudo filesystem based on set in the
   server's perception of same SETATTR
   is if the client's ability user wants to authenticate itself
   properly.  However, with set the support of multiple security mechanisms SUID, SGID and SVTX bits along with
   setting the ability to negotiate the appropriate use permissions by means of these mechanisms,
   the server an ACL.  There is unable still no way to properly determine if a client
   enforce which order the attributes will be able
   to authenticate itself.  If, based on its policies, the server
   chooses to limit the contents set in, and it is likely
   that different orders of the pseudo filesystem, the server
   may effectively hide filesystems from operations will produce different results.

6.6.4.1.  Client Side Recommendations

   If an application needs to enforce a client certain behavior, it is
   recommended that may otherwise
   have legitimate access.

   As suggested practice, the server should apply client implementations set mode and ACL in
   separate SETATTR requests.  This will produce consistent and expected
   results.

   If an application wants to set SUID, SGID and SVTX bits and an ACL:

      In the security policy first SETATTR, set the mode with SUID, SGID and SVTX bits
      as desired and all other bits with a value of 0.

      In a shared resource following SETATTR (preferably in the server's namespace to the components of same COMPOUND) set the
   resource's ancestors.  For example:

           /
           /a/b
           /a/b/c

   The /a/b/c directory is a real filesystem
      ACL.

6.6.4.2.  Server Side Recommendations

   If both mode and is the shared resource.
   The security policy for /a/b/c is Kerberos with integrity.  The ACL are given to SETATTR, server implementations
   should apply verify that the same security policy to /, /a, mode and /a/b.
   This allows for the extension of ACL don't conflict, i.e. the protection of mode
   computed from the server's
   namespace to given ACL must be the ancestors of same as the real shared resource.

   For given mode,
   excluding the case of SUID, SGID and SVTX bits.  The algorithm for assigning
   a new mode based on the use of multiple, disjoint security mechanisms ACL can be used.  (This is described in
   Section 6.6.1.)  If a server receives a request to set both mode and
   ACL, but the server's resources, two conflict, the security for server should return NFS4ERR_INVAL.

6.6.5.  Inheritance and turning it off

   The inheritance of access permissions may be problematic if a particular object in the
   server's namespace user
   cannot prevent their file from inheriting unwanted permissions.  For
   example, a user, "bob", sets up a shared project directory to be used
   by everyone working on Project Foo. "alice" is a part of Project Foo,
   but is working on something that should not be seen by anyone else.
   How can "alice" make sure that any new files that she creates in this
   shared project directory do not inherit anything that could
   compromise the union of all security mechanisms of
   all direct descendants.

7.  File Locking and Share Reservations

   Integrating locking into her work?

   More relevant to the implementors of NFS protocol necessarily causes it to be
   stateful.  With version 4 clients and
   servers is the inclusion question of share reservations how to communicate the protocol
   becomes substantially more dependent fact that user
   "alice" doesn't want any permissions to be inherited to her newly
   created file or directory.

   To do this, implementors should standardize on state than what the traditional
   combination behavior of NFS and NLM [XNFS].  There are three components to
   making this state manageable:

   o  Clear division between client and server

   o  Ability to reliably detect inconsistency in state between client
      and server

   o  Simple
   CREATE and robust recovery mechanisms OPEN must be if:

   1.  just mode is given

       In this model, the server owns case, inheritance will take place, but the state information.  The client
   communicates its view of this state mode will be
       applied to the server inherited ACL as needed.  The
   client is also able to detect inconsistent state before described in Section 6.6.1,
       thereby modifying a
   file.

   To support Win32 share reservations it the ACL.

   2.  just ACL is necessary to atomically
   OPEN or CREATE files.  Having a separate share/unshare operation
   would given

       In this case, inheritance will not allow correct implementation of take place, and the Win32 OpenFile API.  In
   order to correctly implement share semantics, ACL as
       defined in the previous NFS
   protocol mechanisms used when a file is opened CREATE or created (LOOKUP,
   CREATE, ACCESS) need to be replaced.  The NFS version 4 protocol has
   an OPEN operation will be set without modification.

   3.  both mode and ACL are given
       In this case, implementors should verify that subsumes the NFS version 3 methodology of
   LOOKUP, CREATE, mode and ACCESS.  However, because many operations require
   a filehandle, ACL
       don't conflict, i.e. the traditional LOOKUP is preserved to map a file name
   to filehandle without establishing state on mode computed from the server.  The policy
   of granting access or modifying files is managed by given ACL must be
       the server same as the given mode.  The algorithm for assigning a new
       mode based on the client's state.  These mechanisms ACL can implement policy ranging
   from advisory only locking to full mandatory locking.

7.1.  Locking

   It is assumed that manipulating a lock is rare when compared to READ
   and WRITE operations.  It is also assumed that crashes and network
   partitions are relatively rare.  Therefore it be used.  This is important that the
   READ and WRITE operations have described in
       Section 6.6.1) If a lightweight mechanism to indicate if
   they possess server receives a held lock.  A lock request contains the heavyweight
   information required to establish a lock set both mode
       and uniquely define the lock
   owner.

   The following sections describe ACL, but the transition from two conflict, the heavyweight
   information to server should return
       NFS4ERR_INVAL.  If the eventual stateid used for most client mode and server
   locking ACL don't conflict, inheritance
       will not take place and lease interactions.

7.1.1.  Client ID

   For each LOCK request, both, the client must identify itself mode and ACL, will be set
       without modification.

   4.  neither mode nor ACL are given

       In this case, inheritance will take place and no modifications to
       the server.
   This ACL will happen.  It is done worth noting that if no inheritable
       ACEs exist on the parent directory, the file will be created with
       an empty ACL, thus granting no accesses.

6.6.6.  Deficiencies in such a way as Mode Representation of an ACL

   In the presence of an ACL, there are certain cases when the
   representation of the mode is not guaranteed to allow for correct lock
   identification and crash recovery.  A sequence be accurate.  An
   example of a SETCLIENTID
   operation followed by a SETCLIENTID_CONFIRM operation situation is required to
   establish the identification onto detailed below.

   As mentioned in Section 6.6, the server.  Establishment representation of
   identification by the mode is
   deterministic, but not guaranteed to be accurate.  The mode bits
   potentially convey a new incarnation of more restrictive permission than what will
   actually be granted via the client also has ACL.

   Given the effect following ACL of immediately breaking any leased state that two ACEs:

          GROUP@:ACE4_READ_DATA/ACE4_WRITE_DATA/ACE4_EXECUTE:
              ACE4_IDENTIFIER_GROUP:ALLOW
          EVERYONE@:ACE4_READ_DATA/ACE4_WRITE_DATA/ACE4_EXECUTE::DENY

   we would compute a previous incarnation mode of 0070.  However, it is possible, even
   likely, that the client owner might have had on the server, as opposed to forcing be a member of the
   new client incarnation to wait for object's owning
   group, and thus, the leases owner would be granted read, write, and execute
   access to expire.  Breaking the lease state amounts to object.  This would conflict with the server removing all lock, share
   reservation, and, mode of 0070,
   where an owner would be denied this access.

   The only way to overcome this deficiency would be to determine
   whether the server is not supporting the
   CLAIM_DELEGATE_PREV claim type, all delegation state associated with
   same client with the same identity.  For discussion object's owner is a member of delegation
   state recovery, see the section "Delegation Recovery".

   Client identification object's owning group.
   This is encapsulated in the following structure:

               struct nfs_client_id4 {
               verifier4     verifier;
               opaque        id<NFS4_OPAQUE_LIMIT>;
               };

   The first field, verifier difficult, but worse, on a POSIX or any UNIX-like system, it
   is a client incarnation verifier process' membership in a group that is
   used important, not a user's.
   Thus, any fixed mode intended to detect client reboots.  Only if represent the verifier is different
   from above ACL can be
   incorrect.

   Example: administrative databases (possibly /etc/passwd and /etc/
   group) indicate that the server user "bob" is a member of the group "staff".
   An object has previously recorded for the client (as
   identified ACL given above, is owned by the second field "bob", and has an
   owning group of "staff".  User "bob" has logged into the structure, id) does the server
   start the process system, and
   thus processes have been created owned by "bob" and having membership
   in group "staff".

   A mode representation of canceling the client's leased state.

   The second field, id is a variable length string that uniquely
   defines above ACL could thus be 0770, due to
   user "bob" having membership in group "staff".  Now, the client.

   There
   administrative databases are several considerations for how the client generates the id
   string:

   o  The string should be unique so changed, such that multiple clients do not
      present user "bob" is no
   longer in group "staff".  User "bob" logs in to the same string.  The consequences system again, and
   thus more processes are created, this time owned by "bob" but NOT in
   group "staff".

   A mode of two clients
      presenting the same string range from one client getting an error 0770 is inaccurate for processes not belonging to one client having its leased state abruptly and unexpectedly
      canceled.

   o  The string should be selected so group
   "staff".  But even if the subsequent incarnations (e.g.
      reboots) mode of the same client cause the client file were proactively changed
   to present 0070 at the same
      string.  The implementor is cautioned from an approach that
      requires time the string to group database was edited, mode 0070 would be recorded in a local file because this
      precludes the use of
   inaccurate for the implementation in an environment where
      there is no local disk pre-existing processes owned by user "bob" and all file access is from an NFS version
      4 server.

   o  The string should be different for each server network address
      that
   having membership in group "staff".

7.  Single-server Name Space

   This chapter describes the client accesses, rather than common to all NFSv4 single-server name space.  Single-
   server network
      addresses.  The reason is that it namespaces may not be possible for the
      client presented directly to tell if same server is listening on multiple network
      addresses.  If the client issues SETCLIENTID with the same id
      string clients, or they may
   be used as a basis to each network address of such form larger multi-server namespaces (e.g. site-
   wide or organization-wide) to be presented to clients, as described
   in Section 13.

7.1.  Server Exports

   On a UNIX server, the name space describes all the files reachable by
   pathnames under the root directory or "/".  On a Windows NT server will
      think it is
   the same client, and each successive SETCLIENTID will
      cause name space constitutes all the files on disks named by mapped
   disk letters.  NFS server to begin administrators rarely make the process entire
   server's file system name space available to NFS clients.  More often
   portions of removing the client's name space are made available via an "export"
   feature.  In previous leased state.

   o  The algorithm versions of the NFS protocol, the root
   filehandle for generating each export is obtained through the MOUNT protocol;
   the client sends a string should not assume that identifies the
      client's network address won't change.  This includes changes
      between client incarnations export of name space
   and even changes while the client is
      stilling running in its current incarnation.  This means that if server returns the client includes just root filehandle for it.  The MOUNT
   protocol supports an EXPORTS procedure that will enumerate the client's and
   server's network address
      in the id string, there is exports.

7.2.  Browsing Exports

   The NFS version 4 protocol provides a real risk, after the client gives up
      the network address, root filehandle that another client, using a similar
      algorithm clients
   can use to obtain filehandles for generating the id string, will generate exports of a
      conflicting id string.

   o  Given the above considerations, an example particular server,
   via a series of LOOKUP operations within a well generated id
      string is one that includes:

   o  The server's network address.

   o  The client's network address.

   o  For COMPOUND, to traverse a
   path.  A common user level NFS version 4 client, it should contain
      additional information experience is to distinguish the client from other use a graphical user
      level clients running on the same host, such as interface
   (perhaps a process id or
      other unique sequence.

   o  Additional information that tends file "Open" dialog window) to be unique, such as one or
      more of:

      * find a file via progressive
   browsing through a directory tree.  The client machine's serial number (for privacy reasons, it is
         best must be able to perform some move
   from one way function on the serial number).

      *  A MAC address.

      *  The timestamp export to another export via single-component, progressive
   LOOKUP operations.

   This style of when browsing is not well supported by the NFS version 4 software was first
         installed on the 2 and
   3 protocols.  The client (though this is subject expects all LOOKUP operations to the
         previously mentioned caution about using information that is
         stored in remain
   within a file, because the single server file might only be accessible
         over NFS version 4).

      *  A true random number.  However since this number ought to be system.  For example, the same between device
   attribute will not change.  This prevents a client incarnations, this shares the same
         problem as from taking name
   space paths that span exports.

   An automounter on the client can obtain a snapshot of the server's
   name space using the timestamp EXPORTS procedure of the software
         installation.

   As a security measure, the server MUST NOT cancel a client's leased
   state if MOUNT protocol.  If it
   understands the principal established server's pathname syntax, it can create an image of
   the state for a given id string is
   not server's name space on the same as client.  The parts of the principal issuing name space
   that are not exported by the SETCLIENTID.

   Note server are filled in with a "pseudo file
   system" that SETCLIENTID and SETCLIENTID_CONFIRM has allows the user to browse from one mounted file system
   to another.  There is a secondary purpose drawback to this representation of establishing the information
   server's name space on the client: it is static.  If the server needs to make callbacks to
   administrator adds a new export the client for purpose will be unaware of supporting delegations.  It is permitted to
   change it.

7.3.  Server Pseudo File System

   NFS version 4 servers avoid this information via SETCLIENTID and SETCLIENTID_CONFIRM name space inconsistency by
   presenting all the exports for a given server within the same incarnation framework of the client without removing the
   client's leased state.

   Once
   a SETCLIENTID and SETCLIENTID_CONFIRM sequence has successfully
   completed, the single namespace, for that server.  An NFS version 4 client uses
   LOOKUP and READDIR operations to browse seamlessly from one export to
   another.  Portions of the short hand client identifier, server name space that are not exported are
   bridged via a "pseudo file system" that provides a view of type
   clientid4, instead exported
   directories only.  A pseudo file system has a unique fsid and behaves
   like a normal, read only file system.

   Based on the construction of the longer and less compact nfs_client_id4
   structure.  This short hand client identifier (a clientid) server's name space, it is
   assigned by possible
   that multiple pseudo file systems may exist.  For example,

           /a              pseudo file system
           /a/b            real file system
           /a/b/c          pseudo file system
           /a/b/c/d        real file system

   Each of the server pseudo file systems are considered separate entities and should be chosen
   therefore will have its own unique fsid.

7.4.  Multiple Roots

   The DOS and Windows operating environments are sometimes described as
   having "multiple roots".  File Systems are commonly represented as
   disk letters.  MacOS represents file systems as top level names.  NFS
   version 4 servers for these platforms can construct a pseudo file
   system above these root names so that disk letters or volume names
   are simply directory names in the pseudo root.

7.5.  Filehandle Volatility

   The nature of the server's pseudo file system is that it will not
   conflict with is a clientid previously assigned by logical
   representation of file system(s) available from the server.  This
   applies across server restarts or reboots.  When a clientid
   Therefore, the pseudo file system is
   presented to a most likely constructed
   dynamically when the server and that clientid is first instantiated.  It is expected
   that the pseudo file system may not recognized, as would
   happen after a server reboot, have an on disk counterpart from
   which persistent filehandles could be constructed.  Even though it is
   preferable that the server will reject the request with provide persistent filehandles for the error NFS4ERR_STALE_CLIENTID.  When this happens,
   pseudo file system, the NFS client must
   obtain a new clientid should expect that pseudo file
   system filehandles are volatile.  This can be confirmed by use of checking
   the SETCLIENTID operation and then
   proceed to any other necessary recovery associated "fh_expire_type" attribute for those filehandles in
   question.  If the server reboot case
   (See filehandles are volatile, the section "Server Failure and Recovery").

   The NFS client must also employ the SETCLIENTID operation when it
   receives a NFS4ERR_STALE_STATEID error using a stateid derived from
   its current clientid, since this also indicates be
   prepared to recover a server reboot which
   has invalidated the existing clientid (see the next section
   "lock_owner and stateid Definition" for details).

   See the detailed descriptions of SETCLIENTID and SETCLIENTID_CONFIRM
   for filehandle value (e.g. with a complete specification series of the operations.

7.1.2.  Server Release LOOKUP
   operations) when receiving an error of Clientid NFS4ERR_FHEXPIRED.

7.6.  Exported Root

   If the server determines server's root file system is exported, one might conclude that
   a pseudo-file system is unneeded.  This not necessarily so.  Assume
   the client holds no associated state
   for its clientid, the following file systems on a server:

           /       disk1  (exported)
           /a      disk2  (not exported)
           /a/b    disk3  (exported)

   Because disk2 is not exported, disk3 cannot be reached with simple
   LOOKUPs.  The server may choose to release must bridge the clientid. gap with a pseudo-file system.

7.7.  Mount Point Crossing

   The server file system environment may make this choice for an inactive client so be constructed in such a way
   that resources
   are not consumed one file system contains a directory which is 'covered' or
   mounted upon by those intermittently active clients. a second file system.  For example:

           /a/b            (file system 1)
           /a/b/c/d        (file system 2)

   The pseudo file system for this server may be constructed to look
   like:

           /               (place holder/not exported)
           /a/b            (file system 1)
           /a/b/c/d        (file system 2)

   It is the server's responsibility to present the pseudo file system
   that is complete to the client.  If the client contacts sends a lookup request
   for the server after this release, path "/a/b/c/d", the server must ensure server's response is the client receives filehandle of
   the appropriate error so that it will use file system "/a/b/c/d".  In previous versions of the
   SETCLIENTID/SETCLIENTID_CONFIRM sequence to establish a new identity.

   It should be clear that NFS
   protocol, the server must be very hesitant to release a
   clientid since would respond with the resulting work on filehandle of directory
   "/a/b/c/d" within the file system "/a/b".

   The NFS client to recover from such
   an event will be the same burden as able to determine if the server had failed and
   restarted.  Typically it crosses a server would not release mount
   point by a clientid unless
   there had been no activity from that client for many minutes.

   Note that if the id string change in a SETCLIENTID request is properly
   constructed, the value of the "fsid" attribute.

7.8.  Security Policy and if Name Space Presentation

   The application of the client takes care server's security policy needs to use be carefully
   considered by the same principal
   for each successive use of SETCLIENTID, then, barring an active
   denial implementor.  One may choose to limit the
   viewability of service attack, NFS4ERR_CLID_INUSE should never be
   returned.

   However, client bugs, server bugs, or perhaps a deliberate change portions of the principal owner pseudo file system based on the
   server's perception of the id string (such as client's ability to authenticate itself
   properly.  However, with the case support of a client
   that changes multiple security flavors, mechanisms
   and under the new flavor, there is no
   mapping ability to negotiate the previous owner) will in rare cases result in
   NFS4ERR_CLID_INUSE.

   In that event, when appropriate use of these mechanisms,
   the server gets a SETCLIENTID for is unable to properly determine if a client id
   that currently has no state, or it has state, but the lease has
   expired, rather than returning NFS4ERR_CLID_INUSE, will be able
   to authenticate itself.  If, based on its policies, the server MUST
   allow
   chooses to limit the SETCLIENTID, and confirm contents of the new clientid if followed by pseudo file system, the appropriate SETCLIENTID_CONFIRM.

7.1.3.  lock_owner and stateid Definition

   When requesting server
   may effectively hide file systems from a lock, the client must present that may otherwise
   have legitimate access.

   As suggested practice, the server should apply the security policy of
   a shared resource in the server's namespace to the components of the
   resource's ancestors.  For example:

           /
           /a/b
           /a/b/c

   The /a/b/c directory is a real file system and is the shared
   resource.  The security policy for /a/b/c is Kerberos with integrity.
   The server should apply the
   clientid same security policy to /, /a, and an identifier /a/b.
   This allows for the owner extension of the requested lock.
   These two fields are referred to as protection of the lock_owner and server's
   namespace to the definition ancestors of those fields are:

   o  A clientid returned by the server as part real shared resource.

   For the case of the client's use of multiple, disjoint security mechanisms in
   the SETCLIENTID operation.

   o  A variable length opaque array used to uniquely define server's resources, the owner
      of security for a lock managed by particular object in the client.

      This may
   server's namespace should be a thread id, process id, or other unique value.

   When the server grants union of all security mechanisms of
   all direct descendants.

8.  File Locking and Share Reservations

   Integrating locking into the lock, NFS protocol necessarily causes it responds with a unique stateid.
   The stateid is used as a shorthand reference to be
   stateful.  With the lock_owner, since inclusion of such features as share reservations,
   file and directory delegations, recallable layouts, and support for
   mandatory byte-range locking the server will be maintaining protocol becomes substantially more
   dependent on state than the correspondence traditional combination of NFS and NLM
   [XNFS].  There are three components to making this state manageable:

   o  Clear division between them.

   The client and server is free

   o  Ability to form reliably detect inconsistency in state between client
      and server

   o  Simple and robust recovery mechanisms

   In this model, the stateid server owns the state information.  The client
   requests changes in any manner that it chooses
   as long as it is able to recognize invalid locks and out-of-date stateids.
   This requirement includes those stateids generated by earlier
   instances of the server.  From this, server responds with the changes
   made.  Non-client-initiated changes in locking state are infrequent
   and the client receives prompt notification of them and can be properly
   notified adjust
   his view of a server restart.  This notification will occur when the
   client presents a stateid locking state to reflect the server from server's changes.

   To support Win32 share reservations it is necessary to provide
   operations which atomically OPEN or CREATE files.  Having a separate
   share/unshare operation would not allow correct implementation of the
   Win32 OpenFile API.  In order to correctly implement share semantics,
   the previous
   instantiation.

   The server must NFS protocol mechanisms used when a file is opened or
   created (LOOKUP, CREATE, ACCESS) need to be able replaced.  The NFS
   version 4.1 protocol defines OPEN operation which looks up or creates
   a file and establishes locking state on the server.

8.1.  Locking

   It is assumed that manipulating a lock is rare when compared to distinguish READ
   and WRITE operations.  It is also assumed that crashes and network
   partitions are relatively rare.  Therefore it is important that the following situations
   READ and
   return WRITE operations have a lightweight mechanism to indicate if
   they possess a held lock.  A lock request contains the error as specified:

   o  The stateid was generated by an earlier server instance (i.e.
      before heavyweight
   information required to establish a server reboot).  The error NFS4ERR_STALE_STATEID should
      be returned.

   o lock and uniquely define the lock
   owner.

   The stateid was generated by following sections describe the current server instance but transition from the
      stateid no longer designates heavyweight
   information to the current locking state eventual lightwieght stateid used for the
      lockowner-file pair in question (i.e. one most client
   and server locking interactions.

8.1.1.  Client ID

   For each operation that obtains or more depends on locking
      operations has occurred).  The error NFS4ERR_OLD_STATEID should state, the
   specific client must be
      returned.

      This error condition will only occur when determinable by the server.  In NFSv4, each
   distinct client issues instance is represented by a
      locking request clientid, which changes is a stateid while an I/O request that
      uses 64-
   bit identifier that stateid is outstanding.

   o  The stateid was generated by the current server instance but the
      stateid does not designate identifies a locking state for any active
      lockowner-file pair.  The error NFS4ERR_BAD_STATEID should be
      returned.

      This error condition will occur when there has been specific client at a logic error
      on the part of given time and
   which is changed whenever the client or server.  This should not happen.

   One mechanism that may be the server re-initializes.
   Clientid's are used to satisfy these requirements support lock identification and crash
   recovery.

   In NFSv4.1, the clientid associated with each operation is for derived
   from the server to,

   o  divide session on which the "other" field of each stateid into two fields:

      * operation is issued.  Each session is
   associated with a specific clientid at session creation and that
   clientid then becomes the clientid associated with all requests
   issued using it.

   A server verifier which uniquely designates sequence of a particular server
         instantiation.

      *  An index into CREATE_CLIENTID operation followed by a table
   CREATE_SESSION operation using that clientid is required to establish
   the identification on the server.  Establishment of identification by
   a new incarnation of locking-state structures.

   o  utilize the "seqid" field client also has the effect of each stateid, such immediately
   releasing any locking state that seqid is
      monotonically incremented for each stateid a previous incarnation of that same
   client might have had on the server.  Such released state would
   include all lock, share reservation, and, where the server is not
   supporting the CLAIM_DELEGATE_PREV claim type, all delegation state
   associated with
      the same index into the locking-state table.

   By matching the incoming stateid and its field values client with the same identity.  For discussion
   of delegation state
   held at recovery, see the server, section "Delegation Recovery".

   Releasing such state requires that the server is be able to easily determine if a
   stateid is valid for its current instantiation and state.  If the
   stateid
   that one client instance is not valid, the appropriate error can successor of another.  Where this
   cannot be supplied to the
   client.

7.1.4.  Use done, for any of the stateid and Locking

   All READ, WRITE and SETATTR operations contain a stateid.  For the
   purposes number of this section, SETATTR operations which change reasons, the size
   attribute of locking state
   will remain for a file are treated as if they are writing the area
   between the old time subject to lease expiration (see Section 8.5)
   and new size (i.e. the range truncated or added new client will need to
   the file by means of the SETATTR), even where SETATTR is not
   explicitly mentioned in the text.

   If the lock_owner performs a READ or WRITE in a situation in which wait for such state to be removed, if
   it
   has established a makes conflicting lock or share reservation on the server (any OPEN
   constitutes a share reservation) the stateid (previously returned by
   the server) must be used to indicate what locks, including both
   record locks and share reservations, are held by the lockowner.  If
   no state requests.

   Client identification is established by encapsulated in the client, either record lock or share
   reservation, a stateid of all bits 0 following structure:

               struct nfs_client_id4 {
               verifier4     verifier;
               opaque        id<NFS4_OPAQUE_LIMIT>;
               };

   The first field, verifier, is used.  Regardless whether a
   stateid of all bits 0, or a stateid returned by the server client incarnation verifier that is used,
   used to detect client reboots.  Only if there is a conflicting share reservation or mandatory record lock
   held on the file, verifier is different
   from that the server MUST refuse to service the READ or WRITE
   operation.

   Share reservations are established by OPEN operations and by their
   nature are mandatory in that when had previously recorded for the OPEN denies READ or WRITE
   operations, that denial results in such operations being rejected
   with error NFS4ERR_LOCKED.  Record locks may be implemented client (as
   identified by the
   server as either mandatory or advisory, or the choice second field of mandatory or
   advisory behavior may be determined by the structure, id) does the server on
   start the basis process of canceling the
   file being accessed (for example, some UNIX-based servers support client's leased state.

   The second field, id is a
   "mandatory lock bit" on the mode attribute such variable length string that if set, record
   locks are required on the file before I/O is possible).  When record
   locks are advisory, they only prevent uniquely
   defines the granting client so that subsequent instances of conflicting
   lock requests and have no effect on READs or WRITEs.  Mandatory
   record locks, however, prevent conflicting I/O operations.  When they
   are attempted, they are rejected with NFS4ERR_LOCKED.  When the same client gets NFS4ERR_LOCKED on a file it knows it has
   bear the proper share
   reservation for, it will need to issue same id with a LOCK request on different verifier.

   There are several considerations for how the region
   of client generates the file id
   string:

   o  The string should be unique so that includes multiple clients do not
      present the region same string.  The consequences of two clients
      presenting the I/O was same string range from one client getting an error
      to one client having its leased state abruptly and unexpectedly
      canceled.

   o  The string should be performed on,
   with an appropriate locktype (i.e.  READ*_LT for a READ operation,
   WRITE*_LT for a WRITE operation).

   With NFS version 3, there was no notion of a stateid selected so there was no
   way to tell if the application process subsequent incarnations (e.g.
      reboots) of the same client sending cause the READ
   or WRITE operation had also acquired client to present the appropriate record lock on same
      string.  The implementor is cautioned from an approach that
      requires the file.  Thus there was no way string to implement mandatory locking.
   With the stateid construct, be recorded in a local file because this barrier has been removed.

   Note that
      precludes the use of the implementation in an environment where
      there is no local disk and all file access is from an NFS version
      4 server.

   o  The string should be different for UNIX environments each server network address
      that support mandatory file locking, the distinction between advisory and mandatory locking client accesses, rather than common to all server network
      addresses.  The reason is subtle.  In
   fact, advisory and mandatory record locks are exactly that it may not be possible for the
      client to tell if same in so
   far as the APIs and requirements on implementation.  If the mandatory
   lock attribute server is set listening on multiple network
      addresses.  If the file, client issues CREATE_CLIENTID with the server checks same id
      string to see if the
   lockowner has an appropriate shared (read) or exclusive (write)
   record lock on each network address of such a server, the region server will
      think it wishes to read or write to.  If there is
   no appropriate lock, the same client, and each successive CREATE_CLIENTID
      will cause the server checks if there is a conflicting lock
   (which can be done by attempting to acquire remove the conflicting lock on client's previous leased state.

   o  The algorithm for generating the behalf of string should not assume that the lockowner,
      client's network address won't change.  This includes changes
      between client incarnations and even changes while the client is
      still running in its current incarnation.  This means that if successful, release the lock
   after
      client includes just the READ or WRITE is done), client's and if there is, server's network address in
      the server returns
   NFS4ERR_LOCKED.

   For Windows environments, id string, there are no advisory record locks, so is a real risk, after the
   server always checks client gives up the
      network address, that another client, using a similar algorithm
      for record locks during I/O requests.

   Thus, generating the id string, would generate a conflicting id
      string.

   Given the above considerations, an example of a well generated id
   string is one that includes:

   o  The server's network address.

   o  The client's network address.

   o  For a user level NFS version 4 LOCK operation does not need client, it should contain
      additional information to distinguish
   between advisory and mandatory record locks.  It is the NFS version 4
   server's processing of the READ and WRITE operations that introduces the distinction.

   Every stateid client from other than user
      level clients running on the special stateid values noted in this
   section, whether returned by an OPEN-type operation (i.e.  OPEN,
   OPEN_DOWNGRADE), or by same host, such as a LOCK-type operation (i.e.  LOCK or LOCKU),
   defines an access mode for the file (i.e.  READ, WRITE, process id or READ-
   WRITE) as established by the original OPEN which began the stateid
   sequence, and as modified by subsequent OPENs and OPEN_DOWNGRADEs
   within that stateid
      other unique sequence.  When a READ, WRITE,

   o  Additional information that tends to be unique, such as one or SETATTR which
   specifies the size attribute,
      more of:

      *  The client machine's serial number (for privacy reasons, it is done,
         best to perform some one way function on the operation serial number).

      *  A MAC address.

      *  The timestamp of when the NFS version 4 software was first
         installed on the client (though this is subject to
   checking against the access mode to verify
         previously mentioned caution about using information that the operation is
   appropriate given the OPEN with which
         stored in a file, because the operation is associated.

   In file might only be accessible
         over NFS version 4).

      *  A true random number.  However since this number ought to be
         the case of WRITE-type operations (i.e.  WRITEs and SETATTRs which
   set size), same between client incarnations, this shares the server must verify same
         problem as that of the access mode allows writing
   and return an NFS4ERR_OPENMODE error if it does not.  In using the case, timestamp of
   READ, the software
         installation.

   As a security measure, the server may perform MUST NOT cancel a client's leased
   state if the corresponding check on principal established the access
   mode, or it may choose to allow READ on opens state for WRITE only, to
   accommodate clients whose write implementation may unavoidably do
   reads (e.g. due to buffer cache constraints).  However, even if READs
   are allowed in these circumstances, a given id string is
   not the same as the principal issuing the CREATE_CLIENTID.

   A server MUST still check for
   locks that conflict may compare an nfs_client_id4 in a CREATE_CLIENTID with the READ (e.g. another open specify denial
   of READs).  Note an
   nfs_client_id4 established using SETCLIENTID using NFSv4 minor
   version 0, so that a server which does enforce the access mode
   check on READs need an NFSv4.1 client is not explicitly check for conflicting share
   reservations since the existence of OPEN for read access guarantees
   that no conflicting share reservation can exist.

   A stateid of all bits 1 (one) MAY allow READ operations forced to bypass delay until
   lease expiration for locking checks at state established by the server.  However, WRITE operations with earlier client
   using minor version 0.

   Once a
   stateid with bits all 1 (one) MUST NOT bypass locking checks CREATE_CLIENTID has been done, and are
   treated exactly the same resulting clientid
   established as if associated with a stateid of session, all bits 0 were used.

   A lock may not be granted while a READ or WRITE operation requests made on that
   session implicitly identify that clientid, which in turn designates
   the client specified using one
   of the special stateids long-form nfs_client_id4 structure.
   The shorthand client identifier (a clientid) is being performed and the range of assigned by the lock
   request conflicts
   server and should be chosen so that it will not conflict with a
   clientid previously assigned by the range of the READ server.  This applies across
   server restarts or WRITE operation.  For reboots.

   In the purposes event of this paragraph, a conflict occurs when a shared lock
   is requested and a WRITE operation is being performed, or an
   exclusive lock is requested and either a READ or server restart, a WRITE operation is
   being performed.  A SETATTR client will find out that sets size its
   current clientid is treated similarly to no longer valid when receives a
   WRITE as discussed above.

7.1.5.  Sequencing
   NFS4ERR_STALE_CLIENTID error.  The precise circumstances depend of Lock Requests

   Locking
   the characteristics of the sessions involved, specifically whether
   the session is different from most NFS operations as it requires "at-
   most-one" semantics that are not provided by ONCRPC.  ONCRPC over persistent.

   When a
   reliable transport session is not sufficient because persistent, the client will need to create a sequence of locking
   requests may span multiple TCP connections.  In
   new session.  When the face existing clientid is presented to a server as
   part of
   retransmission or reordering, lock or unlock requests must have creating a
   well defined session and consistent behavior.  To accomplish this, each lock
   request contains a sequence number that clientid is not recognized, as
   would happen after a consecutively increasing
   integer.  Different lock_owners have different sequences.  The server
   maintains reboot, the last sequence number (L) received and server will reject the response that
   was returned.  The first request issued for any given lock_owner is
   issued with a sequence number of zero.

   Note that for requests that contain a sequence number, for each
   lock_owner, there should be no more than one outstanding request.

   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
   properly-functioning client, NFS4ERR_STALE_CLIENTID.  When this happens,
   the response to (r) client must have been
   received before the last request (L) was sent.  If obtain a duplicate new clientid by use of
   last request (r == L) is received, the stored response is returned.
   If CREATE_CLIENTID
   operation and then use that clientid as the basis of the basis of a request beyond
   new session and then proceed to any other necessary recovery for the next sequence (r == L + 2) is received, it is
   rejected with
   server reboot case (See Section 8.6.2).

   In the return case of error NFS4ERR_BAD_SEQID.  Sequence
   history is reinitialized whenever the SETCLIENTID/SETCLIENTID_CONFIRM
   sequence changes session being persistent, the client verifier.

   Since will re-
   establish communication using the sequence number is represented with an unsigned 32-bit
   integer, existing session after the arithmetic involved reboot.
   This session will be associated with a stale clientid and the sequence number is mod
   2^32.  For client
   will receive an example indication of modulo arithetic involving sequence numbers
   see [RFC793].

   It is critical that fact in the server maintain status field returned
   by the last response sent to SEQUENCE operation.  The client, can then use the
   client existing
   session to provide a more reliable cache do whatever operations are necessary to determine the
   status of duplicate non-idempotent requests than that outstanding at the time of reboot, while avoiding
   issuing new requests, particularly any involving locking on that
   session.  Such requests would fail with NFS4ERR_STALE_CLIENTID error
   or an NFS4ERR_STALE_STATEID error, if attempted.  In any case, the traditional cache described in [Juszczak].
   The traditional duplicate request cache uses
   client would create a least recently used
   algorithm new clientid using CREATE_CLIENTID, create a
   new session based on that clientid, and proceed to other necessary
   recovery for removing unneeded requests.  However, the last lock
   request server reboot case.

   See the detailed descriptions of CREATE_CLIENTID and response on CREATE_SESSION
   for a given lock_owner must be cached as long as complete specification of these operations.

8.1.2.  Server Release of Clientid

   If the lock state exists on server determines that the server.

   The client MUST monotonically increment the sequence number holds no associated state
   for its clientid, the
   CLOSE, LOCK, LOCKU, OPEN, OPEN_CONFIRM, and OPEN_DOWNGRADE
   operations.  This is true even in server may choose to release the event clientid.  The
   server may make this choice for an inactive client so that resources
   are not consumed by those intermittently active clients.  If the previous
   operation that used
   client contacts the sequence number received an error.  The only
   exception to server after this rule is if release, the previous operation received one of server must ensure
   the following errors: NFS4ERR_STALE_CLIENTID, NFS4ERR_STALE_STATEID,
   NFS4ERR_BAD_STATEID, NFS4ERR_BAD_SEQID, NFS4ERR_BADXDR,
   NFS4ERR_RESOURCE, NFS4ERR_NOFILEHANDLE.

7.1.6.  Recovery from Replayed Requests

   As described above, client receives the appropriate error so that it will use the
   CREATE_CLIENTID/CREATE_SESSION sequence number is per lock_owner.  As long
   as to establish a new identity.
   It should be clear that the server maintains must be very hesitant to release a
   clientid since the last sequence number received and follows resulting work on the methods described above, there are no risks of a Byzantine router
   re-sending old requests.  The server need only maintain client to recover from such
   an event will be the
   (lock_owner, sequence number) state as long same burden as there are open files
   or closed files with locks outstanding.

   LOCK, LOCKU, OPEN, OPEN_DOWNGRADE, if the server had failed and CLOSE each contain
   restarted.  Typically a sequence
   number and therefore the risk of the replay of these operations
   resulting in undesired effects is non-existent while the server
   maintains the lock_owner state.

7.1.7.  Releasing lock_owner State

   When would not release a particular lock_owner clientid unless
   there had been no longer holds open or file locking
   state at activity from that client for many minutes.

   Note that if the server, id string in a CREATE_CLIENTID request is properly
   constructed, and if the server may choose client takes care to release the sequence
   number state associated with use the lock_owner.  The server may make
   this choice based on lease expiration, same principal
   for the reclamation each successive use of CREATE_CLIENTID, then, barring an active
   denial of service attack, NFS4ERR_CLID_INUSE should never be
   returned.

   However, client bugs, server
   memory, bugs, or other implementation specific details.  In any event, the
   server is able to do this safely only when the lock_owner no longer
   is being utilized by perhaps a deliberate change of
   the client.  The server may choose to hold principal owner of the
   lock_owner state in id string (such as the event case of a client
   that retransmitted requests are
   received.  However, changes security flavors, and under the period to hold this state new flavor, there is implementation
   specific.

   In no
   mapping to the case previous owner) will in rare cases result in
   NFS4ERR_CLID_INUSE.

   In that a LOCK, LOCKU, OPEN_DOWNGRADE, or CLOSE is
   retransmitted after event, when the server gets a CREATE_CLIENTID for a client id
   that currently has no state, or it has previously released the lock_owner state, but the lease has
   expired, rather than returning NFS4ERR_CLID_INUSE, the server will find that MUST
   allow the lock_owner has no files open CREATE_CLIENTID, and
   an error will be returned to confirm the client.  If new clientid if followed
   by the lock_owner does have appropriate CRREATESESSION.

8.1.3.  State-owner and Stateid Definition

   When opening a file open, or requesting a byte-range lock, the stateid will not match and again client must
   specify an error is
   returned to identifier which represents the client.

7.1.8.  Use owner of Open Confirmation

   In the case that an OPEN is retransmitted and the lock_owner requested
   lock.  This identifier is being
   used for in the first time or form of a state-owner, represented
   in the lock_owner state has been previously
   released protocol by a state_owner4, a variable-length opaque array
   which, when concatenated with the server, current clientid uniquely defines
   the use owner of lock managed by the OPEN_CONFIRM operation will
   prevent incorrect behavior.  When the server observes the use client.  This may be a thread id,
   process id, or other unique value.

   Owners of opens and owners of byte-range locks are separate entities
   and remain separate even if the
   lock_owner for the first time, it will direct the client same opaque arrays are used to perform
   the OPEN_CONFIRM for the corresponding OPEN.  This sequence
   establishes the use
   designate owners of an lock_owner each.  The protocol distinguishes between open-
   owners (represented by open_owner4 structures) and lock-owners
   (represented by lock_owner4 structures).

   Each open is associated sequence number.
   Since the OPEN_CONFIRM sequence connects with a new open_owner on the
   server specific open-owner while each byte-
   range lock is associated with an existing open_owner on a client, lock-owner and an open-owner, the sequence number
   may have any value.  The OPEN_CONFIRM step assures
   latter being the server that open-owner associated with the value received is open file under which
   the correct one.  See LOCK operation was done.  Delegations and layouts, on the section "OPEN_CONFIRM
   - Confirm Open" for further details.

   There other
   hand, are not associated with a number of situations in which the requirement to confirm
   an OPEN would pose difficulties for specific owner but are associated the
   client and server, in that
   they would be prevented from acting in as a timely fashion on
   information received, because that information would be provisional,
   subject to deletion upon non-confirmation.  Fortunately, these are
   situations in which the server can avoid whole.

   When the need for confirmation
   when responding to open requests.  The two constraints are:

   o  The server must not bestow grants a delegation for lock of any open which would
      require confirmation.

   o  The server MUST NOT require confirmation on a reclaim-type open
      (i.e. one specifying claim type CLAIM_PREVIOUS or
      CLAIM_DELEGATE_PREV).

   These constraints are related in (including opens, byte-
   range locks, delegations, and layouts) it responds with a unique
   stateid, that reclaim-type opens are the only
   ones in which the server may be required to send represents a delegation.  For
   CLAIM_NULL, sending the delegation is optional while set of locks (often a single lock) for
   CLAIM_DELEGATE_CUR, no delegation is sent.

   Delegations being sent with an open requiring confirmation are
   troublesome because recovering from non-confirmation adds undue
   complexity to the protocol while requiring confirmation on reclaim-
   type opens poses difficulties in that
   same file, of the inability to resolve same type, and sharing the
   status same ownership
   characteristics.  Thus opens of the reclaim until lease expiration may make it difficult to same file by different open-
   owners each have timely determination of the an identifying stateid.  Similarly, each set of
   byte-range locks being reclaimed (since
   the grace period may expire).

   Requiring open confirmation on reclaim-type opens is avoidable
   because of the nature of the environments in which such opens are
   done.  For CLAIM_PREVIOUS opens, this is immediately after server
   reboot, so there should be no time for lockowners to be created,
   found to be unused, and recycled.  For CLAIM_DELEGATE_PREV opens, we
   are dealing with a client reboot situation.  A server which supports
   delegation can be sure that no lockowners file owned by a specific lock-owner and gotten
   via an open for that client have been
   recycled since client initialization a specific open-owner, has its own identifying
   stateid.  Delegations and thus can ensure that
   confirmation will not layouts also have associated stateid's by
   which they may be required.

7.2.  Lock Ranges referenced.  The protocol allows stateid is used as a lock owner shorthand
   reference to request a lock with a byte range
   and then either upgrade or unlock a sub-range set of locks and given a stateid the initial lock.
   It is expected that this will be an uncommon type client
   can determine the associated state-owner or state-owners (in the case
   of request.  In an open-owner/lock-owner pair) and the associated.  Clients,
   however, must not assume any
   case, servers or server filesystems may such mapping and must not be able to support sub-
   range lock semantics.  In the event that a server receives a locking
   request that represents use a sub-range of current locking state stateid
   returned for a given filehandle and state-owner in the
   lock owner, the context of a
   different filehandle or a different state-owner.

   The server is allowed free to return form the error
   NFS4ERR_LOCK_RANGE to signify stateid in any manner that it does not support sub-range lock
   operations.  Therefore, the client should be prepared chooses
   as long as it is able to receive recognize invalid and out-of-date stateids.
   Although the protocol XDR definition divides the stateid into into
   'seqid' and 'other' fields, for the purposes of minor version one,
   this
   error and, if appropriate, report distinction is not important and the error to server may use the requesting
   application.
   available space as it chooses, with one exception.

   The client exception is discouraged from combining multiple independent locking
   ranges that happen to stateids whose 'other' field is either all
   zeros or all ones are reserved and may not be adjacent into a single request since generated by the
   server
   server.  Clients may not support sub-range requests and for reasons related to use the recovery protocol-defined special stateid values
   for their defined purposes, but any use of file locking state stateid's in this reserved
   class that are not specially defined by the event of server failure.
   As discussed protocol MUST result in the section "Server Failure and Recovery" below, the
   server
   an NFS4ERR_BAD_STATED being returned.

   Clients may employ certain optimizations during recovery not compare stateids associated with different
   filehandles, so that work
   effectively only when the client's behavior during lock recovery is
   similar to the client's locking behavior prior to server failure.

7.3.  Upgrading and Downgrading Locks

   If a client has server might use stateids with the same bit
   pattern for all opens with a write lock on given open-owner or for all sets of
   byte-range locks associated with a record, given lock-owner/open-owner pair.
   However, if it can request an atomic
   downgrade does so, it must recognize and reject any use of
   stateid when the current filehandle is such that no lock to for that
   filehandle by that open owner (or lock-owner/open-owner pair) exists.

   Stateid's must remain valid until either a read lock via client reboot or a sever
   reobot or until the LOCK request, client returns all of the locks associated with
   the stateid by setting means of an operation such as CLOSE or DELEGRETURN.
   If the type locks are lost due to READ_LT.  If revocation the server supports atomic downgrade, sateid remains usable
   until the
   request will succeed.  If not, it will return NFS4ERR_LOCK_NOTSUPP.
   The client should be prepared to receive this error, and frees it by using FREE_STATEID.  Stateid's
   associated with byte-range locks are an exception.  They remain valid
   even if
   appropriate, report a LOCKU free all remaining locks, so long as the error to opefile with
   which they are associated remains open, unless the requesting application.

   If a client has does a read lock on
   FREE_STATEID to caused the stateid to be freed.

   Because each operation using a record, it can request an atomic
   upgrade stateid occurs as part of a session,
   each stateid is implicitly associated with the lock clientid assigned to
   that session.  Use of a write lock via stateid in the LOCK request by setting context of a session where the type to WRITE_LT or WRITEW_LT.  If
   clientid is invalid should result in the server does not support
   atomic upgrade, it will error NFS4ERR_STALE_STATEID.
   Servers MUST NOT do any validation or return NFS4ERR_LOCK_NOTSUPP.  If the upgrade
   can be achieved without other errors in this
   case, even if they have sufficient information available to validate
   stateids associated with an existing conflict, out-of-date client.

   One mechanism that may be used to satisfy the request will
   succeed.  Otherwise, requirement that the
   server will return either NFS4ERR_DENIED or
   NFS4ERR_DEADLOCK.  The error NFS4ERR_DEADLOCK recognize invalid and out-of-date stateids is returned if for the
   client issued server
   to divide the LOCK request stateid into two fields.  This division may coincide
   with the type set to WRITEW_LT documented division into 'seqid' and 'other' fields or it
   may divide the
   server has detected stateid field up in any other ay it chooses.

   o  An index into a deadlock.  The client should be prepared to
   receive such errors and if appropriate, report the error to the
   requesting application.

7.4.  Blocking Locks

   Some clients require the support table of blocking locks.  The NFS version
   4 protocol must not rely locking-state structures.

   o  A generation number which is incremented on each allocation of a callback mechanism and therefore is
   unable to notify
      table entry a client when particular allocation of a previously denied lock has been
   granted.  Clients have no choice but to continually poll for stateid.

   And then store in each table entry,

   o  The current generation number.

   o  The clientid with which the
   lock.  This presents a fairness problem.  Two new lock types are
   added, READW and WRITEW, and stateid is associated.

   o  The filehandle of the file on which the locks are taken.

   o  An indication of the type of stateid (open, byte-range lock, file
      delegation, directory delegation, layout).

   With this information, the following procedure would be used to indicate to the server that
   validate an incoming stateid and return an appropriate error, when
   necessary:

   o  If the client current session is requesting a blocking lock.  The server should maintain associated with an ordered list invalid clientid,
      return NFS4ERR_STALE_STATEID.

   o  If the table index field is outside the range of pending blocking locks.  When the conflicting lock associated
      table, return NFS4ERR_BAD_STATEID.

   o  If the selected table entry is released, of a different generation than that
      specified in the server may wait incoming stateid, return NFS4ERR_BAD_STATEID.

   o  If the lease period for selected table entry does not match the first
   waiting client to re-request current file
      handle, return NFS4ERR_BAD_STATEID.

   o  If the lock.  After clientid in the lease period
   expires table entry does not match the next waiting client request is allowed clientid
      associated with the lock.  Clients
   are required to poll at an interval sufficiently small that it is
   likely to acquire current session, return NFS4ERR_BAD_STATEID.

   o  If the lock in a timely manner.  The server stateid type is not
   required to maintain a list of pending blocked locks as it valid for the context in which the
      stateid appears, return NFS4ERR_BAD_STATEID.

   o  Otherwise, the stateid is used to
   increase fairness valid and not correct operation.  Because of the
   unordered nature of crash recovery, storing of lock state to stable
   storage would be required to guarantee ordered granting table entry should contain
      any additional information about the associated set of blocking
   locks.

   Servers may also note locks, such
      as open-owner and lock-owner information, as well as information
      on the lock types specific locks, such as open modes and delay returning denial byte ranges.

8.1.4.  Use of the request to allow extra time for a conflicting lock to be
   released, allowing Stateid and Locking

   All READ, WRITE and SETATTR operations contain a successful return.  In this way, clients can
   avoid stateid.  For the burden
   purposes of needlessly frequent polling for blocking locks.
   The server should take care in this section, SETATTR operations which change the length size
   attribute of delay in a file are treated as if they are writing the event area
   between the
   client retransmits old and new size (i.e. the request.

7.5.  Lease Renewal

   The purpose of a lease is to allow a server range truncated or added to remove stale locks
   that are held
   the file by a client that has crashed or is otherwise
   unreachable.  It means of the SETATTR), even where SETATTR is not a mechanism for cache consistency and lease
   renewals may not be denied if
   explicitly mentioned in the lease interval has not expired.

   The following events cause implicit renewal of all of text.

   If the leases for state-owner performs a given client (i.e. all those sharing READ or WRITE in a given clientid).  Each of
   these is situation in which
   it has established a positive indication that lock or share reservation on the client is still active and
   that server (any
   OPEN constitutes a share reservation) the associated state stateid (previously
   returned by the server) must be used to indicate what locks,
   including both record locks and share reservations, are held at by the server, for
   state-owner.  If no state is established by the client, is
   still valid.

   o  An OPEN with a valid clientid.

   o  Any operation made with either record
   lock or share reservation, a valid stateid (CLOSE, DELEGRETURN, LOCK,
      LOCKU, OPEN, OPEN_CONFIRM, OPEN_DOWNGRADE, READ, SETATTR, WRITE).
      This does not include the special stateids stateid of all bits 0 or (including
   all
      bits 1.

      Note that if the client had restarted or rebooted, the client
      would not be making these requests without issuing the
      SETCLIENTID/SETCLIENTID_CONFIRM sequence.  The use fields of the
      SETCLIENTID/SETCLIENTID_CONFIRM sequence (one that changes the
      client verifier) notifies the server to drop the locking state
      associated with the client.  SETCLIENTID/SETCLIENTID_CONFIRM never
      renews a lease.

      If the server has rebooted, the stateids (NFS4ERR_STALE_STATEID
      error) or the clientid (NFS4ERR_STALE_CLIENTID error) will not be
      valid hence preventing spurious renewals.

   This approach allows for low overhead lease renewal which scales
   well.  In the typical case no extra RPC calls are required for lease
   renewal and in the worst case one RPC stateid) is required every lease period
   (i.e. used.  Regardless whether a RENEW operation).  The number stateid of locks held by the client is
   not a factor since all state for the client is involved with the
   lease renewal action.

   Since
   all operations that create bits 0, or a new lease also renew existing
   leases, stateid returned by the server must maintain a common lease expiration time for
   all valid leases for a given client.  This lease time can then be
   easily updated upon implicit lease renewal actions.

7.6.  Crash Recovery

   The important requirement in crash recovery is that both the client
   and the server know when the other has failed.  Additionally, it used, if there is
   required that
   a client sees a consistent view of data across server
   restarts or reboots.  All READ and WRITE operations that may have
   been queued within the client conflicting share reservation or network buffers must wait until mandatory record lock held on the
   client has successfully recovered
   file, the locks protecting server MUST refuse to service the READ and or WRITE operations.

7.6.1.  Client Failure operation.

   Share reservations are established by OPEN operations and Recovery

   In the event by their
   nature are mandatory in that a client fails, the server may recover the client's
   locks when the associated leases have expired.  Conflicting OPEN denies READ or WRITE
   operations, that denial results in such operations being rejected
   with error NFS4ERR_LOCKED.  Record locks
   from another client may only be granted after this lease expiration.
   If implemented by the client is able to restart
   server as either mandatory or advisory, or reinitialize within the lease
   period the client choice of mandatory or
   advisory behavior may be forced to wait determined by the remainder server on the basis of the lease
   period
   file being accessed (for example, some UNIX-based servers support a
   "mandatory lock bit" on the mode attribute such that if set, record
   locks are required on the file before obtaining new locks.

   To minimize client delay upon restart, I/O is possible).  When record
   locks are advisory, they only prevent the granting of conflicting
   lock requests and have no effect on READs or WRITEs.  Mandatory
   record locks, however, prevent conflicting I/O operations.  When they
   are associated attempted, they are rejected with an instance of NFS4ERR_LOCKED.  When the
   client by gets NFS4ERR_LOCKED on a client supplied verifier.  This
   verifier is part of the initial SETCLIENTID call made by file it knows it has the client.
   The server returns a clientid as proper share
   reservation for, it will need to issue a result of the SETCLIENTID
   operation.  The client then confirms LOCK request on the use region
   of the clientid with
   SETCLIENTID_CONFIRM.  The clientid in combination with an opaque
   owner field is then used by file that includes the client to identify region the lock owner for
   OPEN.  This chain of associations is then used I/O was to identify all locks be performed on,
   with an appropriate locktype (i.e.  READ*_LT for a particular client.

   Since the verifier will be changed by the client upon each
   initialization, the server can compare READ operation,
   WRITE*_LT for a new verifier to the verifier
   associated with currently held locks and determine WRITE operation).

   Note that they do not
   match.  This signifies for UNIX environments that support mandatory file locking,
   the client's new instantiation distinction between advisory and subsequent
   loss of mandatory locking state.  As a result, the server is free to release
   all subtle.  In
   fact, advisory and mandatory record locks held which are associated with the old clientid which was
   derived from the old verifier.

   Note that the verifier must have exactly the same uniqueness properties of
   the verifier for in so
   far as the COMMIT operation.

7.6.2.  Server Failure APIs and Recovery requirements on implementation.  If the mandatory
   lock attribute is set on the file, the server loses locking state (usually as a result of a restart checks to see if the
   lock-owner has an appropriate shared (read) or reboot), exclusive (write)
   record lock on the region it must allow clients time wishes to discover this fact and re-
   establish read or write to.  If there is
   no appropriate lock, the lost locking state.  The client must server checks if there is a conflicting lock
   (which can be able done by attempting to re-
   establish acquire the locking state without having conflicting lock on
   the server deny valid
   requests because behalf of the server has granted conflicting access to another
   client.  Likewise, lock-owner, and if there is successful, release the possibility that clients have not
   yet re-established their locking state for a file, lock
   after the server must
   disallow READ and or WRITE operations for that file.

   A client can determine that is done), and if there is, the server failure (and thus loss of locking
   state) has occurred, when it receives one of two errors.  The
   NFS4ERR_STALE_STATEID error indicates a stateid invalidated by a
   reboot or restart.  The NFS4ERR_STALE_CLIENTID error indicates a
   clientid invalidated by reboot or restart.  When either of these returns
   NFS4ERR_LOCKED.

   For Windows environments, there are
   received, no advisory record locks, so the client must establish a new clientid (See
   server always checks for record locks during I/O requests.

   Thus, the section
   "Client ID") NFS version 4 LOCK operation does not need to distinguish
   between advisory and re-establish its locking state.

   Once a session mandatory record locks.  It is established using the new clientid, NFS version 4
   server's processing of the client will
   use reclaim-type locking requests READ and WRITE operations that introduces
   the distinction.

   Every stateid other than the special stateid values noted in this
   section, whether returned by an OPEN-type operation (i.e.  OPEN,
   OPEN_DOWNGRADE), or by a LOCK-type operation (i.e.  LOCK requests with reclaim
   set to true and or LOCKU),
   defines an access mode for the file (i.e.  READ, WRITE, or READ-
   WRITE) as established by the original OPEN which caused the
   allocation of the open stateid and as modified by subsequent OPENs
   and OPEN_DOWNGRADEs for the same open-owner/file pair.  Stateids
   returned by byte-range lock operations imply the access mode for the
   open stateid associated with a claim the lock set represented by the stateid.
   Delegation stateids have an access mode based on the type of CLAIM_PREVIOUS)
   to re-establish its locking state.  Once this is done,
   delegation.  When a READ, WRITE, or if there SETATTR which specifies the size
   attribute, is
   no such locking state to reclaim, done, the client does a RECLAIM_COMPLETE operation is subject to indicate that it has reclaimed all of checking against the locking state
   access mode to verify that it will reclaim.  Once a client does a RECLAIM_COMPLETE
   operation, it may attempt non-reclaim locking operations, although it
   may get NFS4ERR_GRACE errors on these until the period of special
   handling is over.

   The period of special handling of locking and READs and WRITEs, operation is
   referred to as appropriate given the "grace period".  During
   OPEN with which the grace period, clients
   recover locks and operation is associated.

   In the associated state using reclaim-type locking
   requests.  During this period, case of WRITE-type operations (i.e.  WRITEs and SETATTRs which
   set size), the server must reject READ and WRITE
   operations and non-reclaim locking requests (i.e. other LOCK verify that the access mode allows writing
   and OPEN
   operations) with return an NFS4ERR_OPENMODE error of NFS4ERR_GRACE, unless if it is able to
   guarantee that these may be done safely, as described below.

   The grace period may last until all clients to have locks have done a
   RECLAIM_COMPLETE operation, indicating that they have finished
   reclaiming the locks they held before does not.  In the server reboot.  The server
   is assumed to maintain in stable storage a list case, of clients who may
   have such locks.  The
   READ, the server may also terminate perform the grace period
   before all clients have done RECLAIM_COMPLETE.  The server SHOULD NOT
   terminate corresponding check on the grace period before a time equal access
   mode, or it may choose to the lease period in
   order allow READ on opens for WRITE only, to give
   accommodate clients an opportunity whose write implementation may unavoidably do
   reads (e.g. due to find out about the server
   reboot.  Some additional time buffer cache constraints).  However, even if READs
   are allowed in order to allow time to establish a
   new clientid and session and to effect lock reclaims may be added.

   If these circumstances, the server can reliably determine MUST still check for
   locks that granting a non-reclaim
   request will not conflict with reclamation of locks by other clients, the NFS4ERR_GRACE error READ (e.g. another open specify denial
   of READs).  Note that a server which does enforce the access mode
   check on READs need not have to be returned even within explicitly check for conflicting share
   reservations since the
   grace period, although NFS4ERR_GRACE must always be returned to
   clients attempting a non-reclaim lock request before doing their own
   RECLAIM_COMPLETE.  For existence of OPEN for read access guarantees
   that no conflicting share reservation can exist.

   A special stateid of all bits 1 (one), including all fields in the server to be able
   stateid indicates a desire to service bypass locking checks.  The server MAY
   allow READ and
   WRITE operations during the grace period, it must again be able to
   guarantee that no possible conflict could arise between an impending
   reclaim bypass locking request checks at the server, when
   this special stateid is used.  However, WRITE operations with with
   this special stateid value MUST NOT bypass locking checks and are
   treated exactly the same as if a stateid of all bits 0 were used.

   A lock may not be granted while a READ or WRITE operation.  If operation using one
   of the
   server special stateids is unable to offer that guarantee, being performed and the NFS4ERR_GRACE error
   must be returned to range of the client.

   For a server to provide simple, valid handling during lock
   request conflicts with the grace
   period, range of the easiest method is to simply reject all non-reclaim
   locking requests and READ and or WRITE operations by returning operation.  For
   the
   NFS4ERR_GRACE error.  However, a server may keep information about
   granted locks in stable storage.  With purposes of this information, the server
   could determine if paragraph, a regular conflict occurs when a shared lock
   is requested and a WRITE operation is being performed, or an
   exclusive lock is requested and either a READ or a WRITE operation can be
   safely processed.

   For example, if the server maintained on stable storage summary
   information on whether mandatory locks exist, either mandatory byte- is
   being performed.  A SETATTR that sets size is treated similarly to a
   WRITE as discussed above.

8.2.  Lock Ranges

   The protocol allows a lock owner to request a lock with a byte range locks,
   and then either upgrade, downgrade, or share reservations specifying deny modes, many
   requests could be allowed during unlock a sub-range of the grace period.  If it
   initial lock.  It is known
   that no such share reservations exist, OPEN request expected that do not
   specify deny modes may this will be safely granted.  If, in addition, it is
   known that no mandatory byte-range locks exist, either through
   information stored on stable storage an uncommon type of
   request.  In any case, servers or simply because the server
   does not support such locks, READ and WRITE requests filesystems may not be safely
   processed during able
   to support sub-range lock semantics.  In the grace period.

   To reiterate, for event that a server
   receives a locking request that allows non-reclaim represents a sub-range of current
   locking state for the lock and I/O
   requests owner, the server is allowed to be processed during return the grace period, it MUST determine
   error NFS4ERR_LOCK_RANGE to signify that no lock subsequently reclaimed will be rejected and that no it does not support sub-
   range lock
   subsequently reclaimed would have prevented any I/O operation
   processed during operations.  Therefore, the grace period.

   Clients client should be prepared for the return of NFS4ERR_GRACE errors for
   non-reclaim lock and I/O requests.  In to
   receive this case the client should
   employ a retry mechanism for the request.  A delay (on error and, if appropriate, report the order of
   several seconds) between retries should be used error to avoid overwhelming
   the server.  Further discussion of the general issue is included in
   [Floyd].
   requesting application.

   The client must account for the server that is able to
   perform I/O and non-reclaim locking requests within the grace period
   as well as those that can not do so.

   A reclaim-type discouraged from combining multiple independent locking request outside the server's grace period can
   only succeed if the server can guarantee
   ranges that no conflicting lock or
   I/O happen to be adjacent into a single request has been granted since reboot or restart.

   A server may, upon restart, establish a new value for the lease
   period.  Therefore, clients should, once a new clientid is
   established, refetch the lease_time attribute
   server may not support sub-range requests and use it as the basis
   for lease renewal for reasons related to
   the lease associated with that server.
   However, recovery of file locking state in the event of server must establish, for this restart event, a grace
   period at least as long as failure.
   As discussed in the lease period for section "Server Failure and Recovery" below, the previous
   server
   instantiation.  This allows may employ certain optimizations during recovery that work
   effectively only when the client state obtained client's behavior during lock recovery is
   similar to the
   previous server instance client's locking behavior prior to be reliably re-established.

7.6.3.  Network Partitions server failure.

8.3.  Upgrading and Recovery Downgrading Locks

   If the duration a client has a write lock on a record, it can request an atomic
   downgrade of the lock to a network partition is greater than read lock via the lease
   period provided LOCK request, by setting
   the server, type to READ_LT.  If the server will have not received a
   lease renewal from supports atomic downgrade, the client.
   request will succeed.  If not, it will return NFS4ERR_LOCK_NOTSUPP.
   The client should be prepared to receive this occurs, error, and if
   appropriate, report the server may free
   all locks held for error to the client.  As requesting application.

   If a result, all stateids held by the client will become invalid or stale.  Once has a read lock on a record, it can request an atomic
   upgrade of the client is able lock to
   reach the server after such a network partition, all I/O submitted write lock via the LOCK request by setting
   the client with type to WRITE_LT or WRITEW_LT.  If the now invalid stateids server does not support
   atomic upgrade, it will fail with return NFS4ERR_LOCK_NOTSUPP.  If the server
   returning upgrade
   can be achieved without an existing conflict, the request will
   succeed.  Otherwise, the server will return either NFS4ERR_DENIED or
   NFS4ERR_DEADLOCK.  The error NFS4ERR_EXPIRED.  Once this error NFS4ERR_DEADLOCK is received, returned if the
   client will suitably notify issued the application that held LOCK request with the lock.

   As a courtesy type set to the client or as an optimization, WRITEW_LT and the
   server may
   continue to hold locks on behalf of a client for which recent
   communication has extended beyond the lease period.  If the server
   receives detected a lock or I/O request that conflicts with one of these
   courtesy locks, deadlock.  The client should be prepared to
   receive such errors and if appropriate, report the server must free error to the courtesy lock and grant
   requesting application.

8.4.  Blocking Locks

   Some clients require the
   new request.

   When support of blocking locks.  NFSv4.1 does not
   provide a network partition is combined with callback when a server reboot, there are
   edge conditions that place requirements on the server in order previously unavailable lock becomes
   available.  Clients thus have no choice but to
   avoid silent data corruption following continually poll for
   the server reboot. lock.  This presents a fairness problem.  Two of
   these edge conditions new lock types are known,
   added, READW and WRITEW, and are discussed below.

   The first edge condition has used to indicate to the following scenario:

   1.  Client A acquires a lock.

   2.  Client A and server experience mutual network partition, such that
   the client A is unable to renew its lease.

   3.  Client A's lease expires, so server releases lock.

   4.  Client B acquires requesting a lock that would have conflicted with that blocking lock.  The server should maintain
   an ordered list of
       Client A.

   5.  Client B releases pending blocking locks.  When the conflicting lock

   6.  Server reboots

   7.  Network partition between client A and server heals.

   8.  Client A issues a RENEW operation, and gets back a
       NFS4ERR_STALE_CLIENTID.

   9.  Client A reclaims its lock within
   is released, the server's grace period.

   Thus, at server may wait the final step, lease period for the server has erroneously granted client
   A's lock reclaim.  If first
   waiting client B modified to re-request the object lock.  After the lock was
   protecting, lease period
   expires the next waiting client A will experience object corruption.

   The second known edge condition follows:

   1.   Client A acquires a request is allowed the lock.

   2.   Server reboots.

   3.   Client A and server experience mutual network partition, such  Clients
   are required to poll at an interval sufficiently small that client A it is unable
   likely to reclaim its lock within acquire the grace
        period.

   4.   Server's reclaim grace period ends.  Client A has no locks
        recorded on server.

   5.   Client B acquires lock in a timely manner.  The server is not
   required to maintain a list of pending blocked locks as it is used to
   increase fairness and not correct operation.  Because of the
   unordered nature of crash recovery, storing of lock that state to stable
   storage would have conflicted with that be required to guarantee ordered granting of
        Client A.

   6.   Client B releases blocking
   locks.

   Servers may also note the lock

   7.   Server reboots a second time

   8.   Network partition between client A and server heals.

   9.   Client A issues a RENEW operation, types and gets back delay returning denial of
   the request to allow extra time for a
        NFS4ERR_STALE_CLIENTID.

   10.  Client A reclaims its conflicting lock within the server's grace period.

   As with the first edge condition, to be
   released, allowing a successful return.  In this way, clients can
   avoid the final step burden of needlessly frequent polling for blocking locks.
   The server should take care in the scenario length of delay in the second edge condition has event the server erroneously granting
   client
   A's lock reclaim.

   Solving the first and second edge conditions requires that retransmits the server
   either always assumes after it reboots that some edge condition
   occurs, and thus return NFS4ERR_NO_GRACE for all reclaim attempts, or
   that the server record some information in stable storage. request.

8.5.  Lease Renewal

   The
   amount purpose of information the server records in stable storage a lease is in
   inverse proportion to how harsh the allow a server intends to be whenever the
   edge conditions arise.  The server remove stale locks
   that is completely tolerant of all
   edge conditions will record in stable storage every lock are held by a client that has crashed or is
   acquired, removing the lock record from stable storage only when the
   lock otherwise
   unreachable.  It is released.  For the two aforementioned edge conditions, the
   harshest not a server can be, mechanism for cache consistency and still support lease
   renewals may not be denied if the lease interval has not expired.

   Since each session is associated with a grace period for
   reclaims, requires specific client, any
   operation issued on that session is an indication that the server record in stable storage
   information some minimal information.  For example, associated
   client is reachable.  When a server
   implementation could, request is issued for each client, save in stable storage a
   record containing:

   o  the client's id string

   o a boolean that indicates if the client's lease expired or if there
      was administrative intervention (see the section, Server
      Revocation given session,
   execution of Locks) to revoke a record lock, share reservation,
      or delegation

   o a boolean that indicates whether SEQUENCE operation will result in all leases for the
   associated client may have locks that it
      believes to be reclaimable in situations implicitly renewed.  This approach allows for
   low overhead lease renewal which scales well.  In the grace period
      was terminated, making typical case no
   extra RPC calls are required for lease renewal and in the server's view worst case
   one RPC is required every lease period, via a COMPOUND that consists
   solely of lock reclaimability
      suspect. a single SEQUENCE operation.  The server will set this for any client record in stable
      storage where number of locks held by
   the client has is not done a RECLAIM_COMPLETE, before
      it grants any new (i.e. not reclaimed) lock to any client.

   Assuming the above record keeping, factor since all state for the first edge condition,
   after the server reboots, the record that client A's is involved
   with the lease expired
   means renewal action.

   Since all operations that another client could have acquired create a conflicting record
   lock, share reservation, or delegation.  Hence new lease also renew existing
   leases, the server must reject maintain a reclaim from client A with the error NFS4ERR_NO_GRACE.

   For the second edge condition, after the server reboots common lease expiration time for
   all valid leases for a second
   time, the indication given client.  This lease time can then be
   easily updated upon implicit lease renewal actions.

8.6.  Crash Recovery

   The important requirement in crash recovery is that both the client had not completed its reclaims
   at
   and the time at which server know when the grace period ended means other has failed.  Additionally, it is
   required that the a client sees a consistent view of data across server
   restarts or reboots.  All READ and WRITE operations that may have
   been queued within the client or network buffers must reject wait until the
   client has successfully recovered the locks protecting the READ and
   WRITE operations.

8.6.1.  Client Failure and Recovery

   In the event that a reclaim from client A with fails, the error NFS4ERR_NO_GRACE.

   When either edge condition occurs, server may release the client's attempt to reclaim
   locks will result in when the error NFS4ERR_NO_GRACE.  When this is
   received, or associated leases have expired.  Conflicting locks
   from another client may only be granted after the this lease expiration.
   When a client reboots with no has not not failed and re-establishes his lease before
   expiration occurs, requests for conflicting locks will not be
   granted.

   To minimize client delay upon restart, lock state, requests are associated
   with an instance of the client
   will issue by a RECLAIM_COMPLETE.  When the RECLAIM_COMPLETE is
   received, the server and client are again in sync regarding
   reclaimable locks and both booleans in persistent storage can be
   reset, to be set again only when there supplied verifier.  This
   verifier is a subsequent event that
   causes lock reclaim operations to be questionable.

   Regardless part of the level and approach to record keeping, initial CREATE_CLIENTID call made by the
   client.  The server
   MUST implement one returns a clientid as a result of the following strategies (which apply to
   reclaims
   CREATE_CLIENTID operation.  The client then confirms the use of share reservations, record the
   clientid by establishing a session associated with that clientid.
   All locks, including opens, byte-range locks, delegations, and delegations):

   1.  Reject all reclaims layout
   obtained by sessions using that clientid are associated with NFS4ERR_NO_GRACE.  This is extremely
       unforgiving, but necessary if the server does not record lock
       state in stable storage.

   2.  Record sufficient state in stable storage such that all known
       edge conditions involving
   clientid.

   Since the verifier will be changed by the client upon each
   initialization, the server reboot, including can compare a new verifier to the two noted
       in this section, are detected.  False positives are acceptable.
       Note verifier
   associated with currently held locks and determine that at this time, it is they do not known if there are other edge
       conditions.

       In
   match.  This signifies the event, after client's new instantiation and subsequent
   loss of locking state.  As a server reboot, result, the server determines that
       there is unrecoverable damage or corruption free to the information in
       stable storage, then for release
   all clients and/or locks held which may be
       affected, the server MUST return NFS4ERR_NO_GRACE.

   A mandate for the client's handling of are associated with the NFS4ERR_NO_GRACE error is
   outside old clientid which was
   derived from the scope of old verifier.  At this specification, since the strategies for
   such handling are very dependent on point conflicting locks from
   other clients, kept waiting while the client's operating
   environment.  However, one potential approach is described below.

   When leaser had not yet expired, can
   be granted.

   Note that the client receives NFS4ERR_NO_GRACE, it could examine verifier must have the
   change attribute same uniqueness properties of
   the objects verifier for the client is trying to reclaim state
   for, COMMIT operation.

8.6.2.  Server Failure and use that to determine whether to re-establish Recovery

   If the server loses locking state via
   normal OPEN (usually as a result of a restart
   or LOCK requests.  This is acceptable provided the
   client's operating environment allows it.  In otherwords, the client
   implementor is advised reboot), it must allow clients time to document for his users discover this fact and re-
   establish the behavior. lost locking state.  The client could also inform must be able to re-
   establish the application that its record lock or
   share reservations (whether they were delegated or not) have been
   lost, such as via locking state without having the server deny valid
   requests because the server has granted conflicting access to another
   client.  Likewise, if there is a UNIX signal, possibility that clients have not
   yet re-established their locking state for a GUI pop-up window, etc.  See file, the
   section, "Data Caching server must
   disallow READ and Revocation" WRITE operations for that file.

   A client can determine that server failure (and thus loss of locking
   state) has occurred, when it receives one of two errors.  The
   NFS4ERR_STALE_STATEID error indicates a discussion stateid invalidated by a
   reboot or restart.  The NFS4ERR_STALE_CLIENTID error indicates a
   clientid invalidated by reboot or restart.  When either of what these are
   received, the client should do for dealing with unreclaimed delegations on client must establish a new clientid (See
   Section 8.1.1) and re-establish its locking state.

   For further discussion of revocation of locks see

   Once a session is established using the section "Server
   Revocation of Locks".

7.7.  Recovery from new clientid, the client will
   use reclaim-type locking requests (i.e.  LOCK requests with reclaim
   set to true and OPEN operations with a Lock Request Timeout claim type of CLAIM_PREVIOUS)
   to re-establish its locking state.  Once this is done, or Abort

   In if there is
   no such locking state to reclaim, the event a lock request times out, a client may decide does a RECLAIM_COMPLETE
   operation to not
   retry indicate that it has reclaimed all of the request.  The locking state
   that it will reclaim.  Once a client does a RECLAIM_COMPLETE
   operation, it may also abort the request when the
   process for which attempt non-reclaim locking operations, although it was issued
   may get NFS4ERR_GRACE errors on these until the period of special
   handling is terminated (e.g. in UNIX due to a
   signal).  It over.

   The period of special handling of locking and READs and WRITEs, is possible though that
   referred to as the server received "grace period".  During the request grace period, clients
   recover locks and acted upon it.  This would change the associated state on using reclaim-type locking
   requests.  During this period, the server without
   the client being aware must reject READ and WRITE
   operations and non-reclaim locking requests (i.e. other LOCK and OPEN
   operations) with an error of the change.  It NFS4ERR_GRACE, unless it is paramount able to
   guarantee that these may be done safely, as described below.

   The grace period may last until all clients who are known to possibly
   have had locks have done a RECLAIM_COMPLETE operation, indicating
   that they have finished reclaiming the
   client re-synchronize state with server locks they held before it attempts any other
   operation that takes a seqid and/or a stateid with the same
   lock_owner.  This
   server reboot.  The server is straightforward assumed to do without maintain in stable storage a special re-
   synchronize operation.

   Since the
   list of clients who may have such locks.  The server maintains may also
   terminate the last lock request and response
   received on grace period before all clients have done
   RECLAIM_COMPLETE.  The server SHOULD NOT terminate the lock_owner, for each lock_owner, grace period
   before a time equal to the client should
   cache lease period in order to give clients an
   opportunity to find out about the last server reboot.  Some additional
   time in order to allow time to establish a new clientid and session
   and to effect lock request it sent such that reclaims may be added.

   If the lock server can reliably determine that granting a non-reclaim
   request did will not receive a response.  From this, the next time conflict with reclamation of locks by other clients,
   the client NFS4ERR_GRACE error does not have to be returned even within the
   grace period, although NFS4ERR_GRACE must always be returned to
   clients attempting a non-reclaim lock operation for the lock_owner, it can send request before doing their own
   RECLAIM_COMPLETE.  For the cached request, if
   there is one, server to be able to service READ and if
   WRITE operations during the request was one grace period, it must again be able to
   guarantee that established state (e.g. no possible conflict could arise between a LOCK potential
   reclaim locking request and the READ or OPEN operation), WRITE operation.  If the
   server will return is unable to offer that guarantee, the cached result
   or if never saw NFS4ERR_GRACE error
   must be returned to the request, perform it.  The client can follow up
   with client.

   For a request server to remove provide simple, valid handling during the state (e.g. a LOCKU or CLOSE operation).
   With this approach, grace
   period, the sequencing easiest method is to simply reject all non-reclaim
   locking requests and stateid information on the
   client READ and server for WRITE operations by returning the given lock_owner will re-synchronize and
   NFS4ERR_GRACE error.  However, a server may keep information about
   granted locks in
   turn stable storage.  With this information, the server
   could determine if a regular lock state will re-synchronize.

7.8.  Server Revocation of Locks

   At any point, or READ or WRITE operation can be
   safely processed.

   For example, if the server can revoke maintained on stable storage summary
   information on whether mandatory locks held by a client and the
   client must exist, either mandatory byte-
   range locks, or share reservations specifying deny modes, many
   requests could be prepared for this event.  When allowed during the client detects grace period.  If it is known
   that
   its no such share reservations exist, OPEN request that do not
   specify deny modes may be safely granted.  If, in addition, it is
   known that no mandatory byte-range locks have been exist, either through
   information stored on stable storage or simply because the server
   does not support such locks, READ and WRITE requests may have been revoked, be safely
   processed during the client is
   responsible grace period.

   To reiterate, for validating a server that allows non-reclaim lock and I/O
   requests to be processed during the state information between itself grace period, it MUST determine
   that no lock subsequently reclaimed will be rejected and that no lock
   subsequently reclaimed would have prevented any I/O operation
   processed during the server.  Validating locking state grace period.

   Clients should be prepared for the client means that it
   must verify or reclaim state for each lock currently held.

   The first instance return of NFS4ERR_GRACE errors for
   non-reclaim lock revocation is upon server reboot or re-
   initialization. and I/O requests.  In this instance the client will receive an error
   (NFS4ERR_STALE_STATEID or NFS4ERR_STALE_CLIENTID) and case the client will
   proceed with normal crash recovery as described in the previous
   section.

   The second lock revocation event is the inability to renew the lease
   before expiration.  While this is considered should
   employ a rare or unusual event, retry mechanism for the client must request.  A delay (on the order of
   several seconds) between retries should be prepared used to recover.  Both avoid overwhelming
   the server and server.  Further discussion of the general issue is included in
   [Floyd].  The client
   will be must account for the server that is able to detect
   perform I/O and non-reclaim locking requests within the failure to renew grace period
   as well as those that can not do so.

   A reclaim-type locking request outside the server's grace period can
   only succeed if the server can guarantee that no conflicting lock or
   I/O request has been granted since reboot or restart.

   A server may, upon restart, establish a new value for the lease and are capable
   of recovering without data corruption.  For
   period.  Therefore, clients should, once a new clientid is
   established, refetch the server, lease_time attribute and use it tracks as the
   last basis
   for lease renewal event serviced for the client and knows when the lease
   will expire.  Similarly, associated with that server.
   However, the client server must track operations which will
   renew establish, for this restart event, a grace
   period at least as long as the lease period.  Using the time that each such request was
   sent and the time that period for the corresponding reply was received, previous server
   instantiation.  This allows the client should bound the time that the corresponding renewal could
   have occurred on state obtained during the
   previous server instance to be reliably re-established.

8.6.3.  Network Partitions and thus determine if it is possible that
   a lease period expiration could have occurred.

   The third lock revocation event can occur as a result of
   administrative intervention within Recovery

   If the lease period.  While this is
   considered duration of a rare event, it network partition is possible that greater than the server's
   administrator has decided to release or revoke a particular lock held lease
   period provided by the client.  As a result of revocation, server, the client server will receive an
   error of NFS4ERR_ADMIN_REVOKED.  In this instance the client may
   assume that only the lock_owner's locks have been lost.  The client
   notifies the lock holder appropriately.  The client may not assume
   the lease period has been renewed as received a result of failed operation.

   When
   lease renewal from the client determines client.  If this occurs, the lease period server may have expired, the
   client must mark free
   all locks held for the associated lease as
   "unvalidated".  This means the client has been unable to re-establish client, or confirm it may allow the appropriate lock state with the server.  As described
   in the previous section on crash recovery, there are scenarios in
   which the server may grant conflicting locks after the lease period
   has expired to
   remain for a client.  When it is possible that the lease period
   has expired, the client must validate each lock currently held considerable period, subject to
   ensure the constraint that if a
   request for a conflicting lock has not been granted.  The client may
   accomplish this task by issuing an I/O request, either a pending I/O
   or a zero-length read, specifying the stateid is made, locks associated with the expired
   leases do not prevent such a conflicting lock in question. from being granted but
   are revoked as necessary so as not to interfere with such conflicting
   requests.

   If the response server chooses to the request delay freeing of lock state until there is success, the
   client has validated a
   conflict, it may either free all of the clients locks governed by that stateid and
   re-established the appropriate state between itself and the server.
   If the I/O request once there is not successful, then one a
   conflict, or more it may only revoke the minimum set of locks necessary to
   allow conflicting requests.  When it adopts the finer-grained
   approach, it must revoke all locks associated with the stateid was revoked by a given stateid,
   as long as it revokes a single such lock.

   When the server and the client
   must notify the owner.

7.9.  Share Reservations

   A share reservation is a mechanism to control access chooses to free all of a file.  It
   is client's lock state, either
   immediately upon lease expiration, or a separate and independent mechanism from record locking.  When result of the first attempt
   to get a lock, all stateids held by the client opens a file, it issues an OPEN operation will become invalid or
   stale.  Once the client is able to reach the server
   specifying after such a
   network partition, the type of access required (READ, WRITE, or BOTH) and status returned by the
   type SEQUENCE operation will
   indicate a loss of access to deny others (deny NONE, READ, WRITE, or BOTH).  If
   the OPEN fails locking state.  In addition all I/O submitted by
   the client with the now invalid stateids will fail with the application's open request.

   Pseudo-code definition of server
   returning the semantics:

           if (request.access == 0)
           return (NFS4ERR_INVAL)
           else
           if ((request.access & file_state.deny)) ||
           (request.deny & file_state.access))
           return (NFS4ERR_DENIED)

   This checking error NFS4ERR_EXPIRED.  Once the client learns of share reservations on OPEN is done with no exception
   for an existing OPEN for the same open_owner.

   The constants used for
   loss of locking state, it will suitably notify the OPEN and OPEN_DOWNGRADE operations for applications that
   held the
   access and deny fields are as follows:

           const OPEN4_SHARE_ACCESS_READ   = 0x00000001;
           const OPEN4_SHARE_ACCESS_WRITE  = 0x00000002;
           const OPEN4_SHARE_ACCESS_BOTH   = 0x00000003;

           const OPEN4_SHARE_DENY_NONE     = 0x00000000;
           const OPEN4_SHARE_DENY_READ     = 0x00000001;
           const OPEN4_SHARE_DENY_WRITE    = 0x00000002;
           const OPEN4_SHARE_DENY_BOTH     = 0x00000003;

7.10.  OPEN/CLOSE Operations

   To provide correct share semantics, invalidated locks.  The client should then take action to
   free invalidated stateid's, either by establishing a new client MUST use the OPEN id
   using a new verifier or by doing a FREE_STATEID operation to obtain release
   each of the initial filehandle and indicate invalidated stateid's.

   When the desired
   access and what if any access server adopts a finer-grained approach to deny.  Even if revocation of
   locks when lease have expired, only a subset of stateids will
   normally become invalid during a network partition.  When the client intends
   is able to
   use communicate with the server after such a stateid network
   partition, the status returned by the SEQUENCE operation will
   indicate a partial loss of all 0's or all 1's, it must still obtain locking state.  In addition, operations,
   including I/O submitted by the
   filehandle for client with the regular file now invalid stateids
   will fail with the OPEN operation so server returning the
   appropriate share semantics can be applied.  For clients that do not
   have a deny mode built into their open programming interfaces, deny
   equal to NONE should be used.

   The OPEN operation with error NFS4ERR_EXPIRED.  Once
   the CREATE flag, also subsumes client learns of the CREATE
   operation for regular files as used in previous versions loss of locking state, it will use the NFS
   protocol.  This allows a create with a share to be done atomically.

   The CLOSE
   TEST_STATEID operation removes on all share reservations held by of its stateid's to determine which
   locks have been lost and them suitably notify the
   lock_owner on applications that file.  If record locks are held,
   held the invalidated locks.  The client SHOULD can then release all the
   invalidated locking state and acknowledge the revocation of the
   associated locks before issuing by doing a CLOSE.  The server MAY free all
   outstanding locks FREE_STATEID operation on CLOSE but some servers may not support the CLOSE each of the
   invalidated stateid's.

   When a file network partition is combined with a server reboot, there are
   edge conditions that still has record locks held.  The place requirements on the server MUST return
   failure, NFS4ERR_LOCKS_HELD, if any locks would exist after in order to
   avoid silent data corruption following the
   CLOSE. server reboot.  Two of
   these edge conditions are known, and are discussed below.

   The LOOKUP operation will return first edge condition arises as a filehandle without establishing
   any lock state on result of the server.  Without a valid stateid, scenarios such as
   the follwing:

   1.  Client A acquires a lock.

   2.  Client A and server
   will assume the experience mutual network partition, such
       that client has A is unable to renew its lease.

   3.  Client A's lease expires, and the least access.  For example, a file
   opened with deny READ/WRITE cannot be accessed using server releases lock.

   4.  Client B acquires a filehandle
   obtained through LOOKUP because it lock that would not have a valid stateid
   (i.e. using a stateid of all bits 0 or all bits 1).

7.10.1.  Close and Retention of State Information

   Since a CLOSE operation requests deallocation of a stateid, dealing conflicted with retransmission that of
       Client A.

   5.  Client B releases its lock.

   6.  Server reboots.

   7.  Network partition between client A and server heals.

   8.  Client A connects to new server instance and finds out about
       server reboot.

   9.  Client A reclaims its lock within the CLOSE, may pose special difficulties,
   since server's grace period.

   Thus, at the state information, which normally would be used to
   determine final step, the state of server has erroneously granted client
   A's lock reclaim.  If client B modified the open file being designated, might be
   deallocated, resulting object the lock was
   protecting, client A will experience object corruption.

   The second known edge condition arises in situations such as the
   following:

   1.   Client A acquires one or more locks.

   2.   Server reboots.

   3.   Client A and server experience mutual network partition, such
        that client A is unable to reclaim all of its locks within the
        grace period.

   4.   Server's reclaim grace period ends.  Client A has either no
        locks or an NFS4ERR_BAD_STATEID error.

   Servers may deal incomplete set of locks known to the server.

   5.   Client B acquires a lock that would have conflicted with this problem in a number lock
        of ways.  To provide
   the greatest degree assurance client A that was not reclaimed.

   6.   Client B releases the protocol is being used
   properly, lock.

   7.   Server reboots a second time.

   8.   Network partition between client A and server should, rather than deallocate the stateid, mark
   it as close-pending, heals.

   9.   Client A connects to new server instance and retain finds out about
        server reboot.

   10.  Client A reclaims its lock within the stateid server's grace period.

   As with this status, until
   later deallocation.  In this way, a retransmitted CLOSE can be
   recognized since the stateid points to state information with this
   distinctive status, so first edge condition, the final step of the scenario of
   the second edge condition has the server erroneously granting client
   A's lock reclaim.

   Solving the first and second edge conditions requires that it can be handled without error.

   When adopting this strategy, a the server should retain
   either always assumes after it reboots that some edge condition
   occurs, and thus return NFS4ERR_NO_GRACE for all reclaim attempts, or
   that the state server record some information in stable storage.  The
   amount of information until the earliest of:

   o  Another validly sequenced request for server records in stable storage is in
   inverse proportion to how harsh the same lockowner, server intends to be whenever
   edge conditions arise.  The server that is
      not a retransmission.

   o  The time completely tolerant of all
   edge conditions will record in stable storage every lock that a lockowner is freed by
   acquired, removing the lock record from stable storage only when the
   lock is released.  For the two edge conditions discussed above, the
   harshest a server due to can be, and still support a grace period
      with no activity.

   o  All locks for
   reclaims, requires that the client are freed as server record in stable storage
   information some minimal information.  For example, a result of server
   implementation could, for each client, save in stable storage a SETCLIENTID.

   Servers may avoid this complexity, at
   record containing:

   o  the cost of less complete
   protocol error checking, by simply responding NFS4_OK in client's id string

   o  a boolean that indicates if the event of client's lease expired or if there
      was administrative intervention (see Section 8.7) to revoke a CLOSE for
      record lock, share reservation, or delegation and there has been
      no acknowledgement (via FREE_STATEID) of such revocation.

   o  a deallocated stateid, on boolean that indicates whether the assumption client may have locks that this case
   must be caused by a retransmitted close.  When adopting this
   approach, it is desirable
      believes to at least log an error when returning a
   no-error indication be reclaimable in this situation.  If situations which the server maintains a
   reply-cache mechanism, it can verify grace period
      was terminated, making the CLOSE is indeed a
   retransmission and avoid error logging server's view of lock reclaimability
      suspect.  The server will set this for any client record in most cases.

7.11.  Open Upgrade and Downgrade

   When an OPEN is stable
      storage where the client has not done for a file and RECLAIM_COMPLETE, before
      it grants any new (i.e. not reclaimed) lock to any client.

   Assuming the lockowner above record keeping, for which the open
   is being done already has the file open, first edge condition,
   after the result is to upgrade server reboots, the
   open file status maintained on record that client A's lease expired
   means that another client could have acquired a conflicting record
   lock, share reservation, or delegation.  Hence the server to include must reject
   a reclaim from client A with the access and
   deny bits specified by error NFS4ERR_NO_GRACE.

   For the new OPEN as well as those second edge condition, after the server reboots for a second
   time, the existing
   OPEN.  The result is indication that there is one open file, as far as the
   protocol is concerned, and it includes client had not completed its reclaims
   at the union of time at which the access and
   deny bits for all of grace period ended means that the OPEN requests completed.  Only server
   must reject a single
   CLOSE will be done to reset the effects of both OPENs.  Note that reclaim from client A with the
   client, when issuing error NFS4ERR_NO_GRACE.

   When either edge condition occurs, the OPEN, may not know that the same file is in
   fact being opened.  The above only applies if both OPENs client's attempt to reclaim
   locks will result in the OPENed object being designated by error NFS4ERR_NO_GRACE.  When this is
   received, or after the same filehandle. client reboots with no lock state, the client
   will issue a RECLAIM_COMPLETE.  When the RECLAIM_COMPLETE is
   received, the server chooses and client are again in agreement regarding
   reclaimable locks and both booleans in persistent storage can be
   reset, to export multiple filehandles corresponding be set again only when there is a subsequent event that
   causes lock reclaim operations to the same file object and returns different filehandles on two
   different OPENs be questionable.

   Regardless of the same file object, level and approach to record keeping, the server
   MUST NOT "OR"
   together implement one of the access and deny bits following strategies (which apply to
   reclaims of share reservations, record locks, and coalesce the two open files.
   Instead delegations):

   1.  Reject all reclaims with NFS4ERR_NO_GRACE.  This is extremely
       unforgiving, but necessary if the server must maintain separate OPENs with separate
   stateids and will require separate CLOSEs to free them.

   When multiple open files on does not record lock
       state in stable storage.

   2.  Record sufficient state in stable storage such that all known
       edge conditions involving server reboot, including the client two noted
       in this section, are merged into detected.  False positives are acceptable.
       Note that at this time, it is not known if there are other edge
       conditions.

       In the event that, after a single open
   file object on server reboot, the server, server determines
       that there is unrecoverable damage or corruption to the close of one of
       information in stable storage, then for all clients and/or locks
       which may be affected, the open files (on server MUST return NFS4ERR_NO_GRACE.

   A mandate for the
   client) may necessitate change client's handling of the access and deny status NFS4ERR_NO_GRACE error is
   outside the scope of this specification, since the
   open file strategies for
   such handling are very dependent on the server.  This client's operating
   environment.  However, one potential approach is because described below.

   When the union client receives NFS4ERR_NO_GRACE, it could examine the
   change attribute of the access and
   deny bits for objects the remaining opens may be smaller (i.e. a proper
   subset) than previously.  The OPEN_DOWNGRADE operation client is used trying to
   make the necessary change reclaim state
   for, and the client should use it that to update determine whether to re-establish the
   server so that share reservation requests by state via
   normal OPEN or LOCK requests.  This is acceptable provided the
   client's operating environment allows it.  In other clients are
   handled properly.

7.12.  Short and Long Leases

   When determining words, the time period client
   implementor is advised to document for his users the server lease, behavior.  The
   client could also inform the usual
   lease tradeoffs apply.  Short leases are good application that its record lock or
   share reservations (whether they were delegated or not) have been
   lost, such as via a UNIX signal, a GUI pop-up window, etc.  See the
   section, "Data Caching and Revocation" for fast server
   recovery at a cost discussion of increased RENEW or READ (with zero length)
   requests.  Longer leases are certainly kinder and gentler to servers
   trying to handle very large numbers what the
   client should do for dealing with unreclaimed delegations on client
   state.

   For further discussion of clients.  The number revocation of RENEW
   requests drop in proportion to the lease time.  The disadvantages locks see Section 8.7.

8.7.  Server Revocation of
   long leases are slower recovery after server failure (the server must
   wait for Locks

   At any point, the leases to expire server can revoke locks held by a client and the grace period to elapse before
   granting new lock requests) and increased file contention (if
   client
   fails to transmit an unlock request then server must wait be prepared for lease
   expiration before granting new locks).

   Long leases are usable if this event.  When the server is able to store lease state in
   non-volatile memory.  Upon recovery, client detects that
   its locks have been or may have been revoked, the server can reconstruct client is
   responsible for validating the
   lease state from its non-volatile memory and continue operation with
   its clients and therefore long leases would not be an issue.

7.13.  Clocks, Propagation Delay, information between itself and Calculating Lease Expiration

   To avoid
   the need server.  Validating locking state for synchronized clocks, lease times are granted by the server as a time delta.  However, there is a requirement client means that it
   must verify or reclaim state for each lock currently held.

   The first occasion of lock revocation is upon server reboot or re-
   initialization.  In this instance the client will receive an error
   (NFS4ERR_STALE_STATEID or NFS4ERR_STALE_CLIENTID) and server clocks do not drift excessively over the duration
   of client will
   proceed with normal crash recovery as described in the lock.  There previous
   section.

   The second occasion of lock revocation is also the issue of propagation delay across inability to renew the
   network which could easily be several hundred milliseconds as well
   lease before expiration, as discussed above.  While this is
   considered a rare or unusual event, the possibility that requests will client must be lost prepared to
   recover.  The server is responsible for determining lease expiration,
   and need deciding exactly how to be
   retransmitted.

   To take propagation delay into account, deal with it, informing the client should subtract it
   from lease times (e.g. if of the client estimates
   scope of the one-way
   propagation delay as 200 msec, lock revocation.  The client then it can assume uses the status
   information provided by the server to synchronize his locking state
   with that of the lease is
   already 200 msec old when it gets it).  In addition, it will take
   another 200 msec server, in order to get recover.

   The third occasion of lock revocation can occur as a response back to the server.  So result of
   revocation of locks within the client
   must send lease period, either because of
   administrative intervention, or because a recallable lock renewal (a
   delegation or write data back to the server 400 msec
   before layout) was not returned within the lease would expire.

   The server's lease period configuration should take into account the
   network distance of ater
   having been recalled.  While these are considered rare events, they
   are possible and the clients that will client must be accessing prepared to deal with them.  When
   either of these events occur, the server's
   resources.  It is expected that client finds out about the lease period will take into
   account
   situation through the network propagation delays and other network delay
   factors for status returned by the client population.  Since SEQUENCE operation.  Any
   use of stateids associated with revoked locks will receive the protocol does not allow
   for an automatic method to determine an appropriate lease period, the
   server's administrator error
   NFS4ERR_ADMIN_REVOKED or NFS4ERR_DELEG_REVOKED, as appropriate.

   In all situations in which a subset of locking state may have to tune been
   revoked, which include all cases in which locking state is revoked
   within the lease period.

8.  Client-Side Caching

   Client-side caching of data, of file attributes, and of file names period, it is
   essential up to providing good performance with the NFS protocol.
   Providing distributed cache coherence is a difficult problem and
   previous versions of the NFS protocol have not attempted it.
   Instead, several NFS client implementation techniques have been used to reduce the problems that a lack of coherence poses for users.
   These techniques determine which
   locks have not been clearly defined by earlier protocol
   specifications revoked and it is often unclear what is valid or invalid
   client behavior.

   The NFS version 4 protocol uses many techniques similar to those that which have been used in previous protocol versions.  The NFS version 4
   protocol not.  It does not provide distributed cache coherence.  However, it
   defines a more limited set of caching guarantees to allow locks and
   share reservations to be used without destructive interference from
   client side caching.

   In addition, the NFS version 4 protocol introduces a delegation
   mechanism which allows many decisions normally made by the server to
   be made locally this by clients.  This mechanism provides efficient
   support of using
   the common cases where sharing is infrequent or where
   sharing is read-only.

8.1.  Performance Challenges for Client-Side Caching

   Caching techniques used in previous versions of TEST_STATEID operation on the NFS protocol have
   been successful in providing good performance.  However, several
   scalability challenges can arise when those techniques are used with
   very large numbers appropriate set of clients.  This is particularly true when
   clients are geographically distributed which classically increases stateid's.  Once
   the latency for cache revalidation requests.

   The previous versions set of revoked locks has been determined, the NFS protocol repeat their file data
   cache validation requests at the time applications can be
   notified, and the file is opened.  This
   behavior invalidated stateid's can have serious performance drawbacks. be freed and lock
   revocation acknowledged by using FREE_STATEID.

8.8.  Share Reservations

   A common case is
   one in which a file share reservation is only accessed by a single client.  Therefore,
   sharing is infrequent.

   In this case, repeated reference to the server mechanism to find that no
   conflicts exist is expensive.  A better option with regards control access to
   performance a file.  It
   is to allow a separate and independent mechanism from record locking.  When a
   client that repeatedly opens a file file, it issues an OPEN operation to do
   so without reference the server
   specifying the type of access required (READ, WRITE, or BOTH) and the
   type of access to deny others (deny NONE, READ, WRITE, or BOTH).  If
   the server. OPEN fails the client will fail the application's open request.

   Pseudo-code definition of the semantics:

           if (request.access == 0)
           return (NFS4ERR_INVAL)
           else
           if ((request.access & file_state.deny)) ||
           (request.deny & file_state.access))
           return (NFS4ERR_DENIED)

   This checking of share reservations on OPEN is done until potentially
   conflicting operations from another client actually occur.

   A similar situation arises in connection with file locking.  Sending
   file lock no exception
   for an existing OPEN for the same open-owner.

   The constants used for the OPEN and unlock requests to OPEN_DOWNGRADE operations for the server as well
   access and deny fields are as follows:

           const OPEN4_SHARE_ACCESS_READ   = 0x00000001;
           const OPEN4_SHARE_ACCESS_WRITE  = 0x00000002;
           const OPEN4_SHARE_ACCESS_BOTH   = 0x00000003;

           const OPEN4_SHARE_DENY_NONE     = 0x00000000;
           const OPEN4_SHARE_DENY_READ     = 0x00000001;
           const OPEN4_SHARE_DENY_WRITE    = 0x00000002;
           const OPEN4_SHARE_DENY_BOTH     = 0x00000003;

8.9.  OPEN/CLOSE Operations

   To provide correct share semantics, a client MUST use the read and
   write requests necessary OPEN
   operation to make data caching consistent with obtain the
   locking semantics (see initial filehandle and indicate the section "Data Caching desired
   access and File Locking")
   can severely limit performance.  When locking is used what if any access to provide
   protection against infrequent conflicts, a large penalty is incurred.
   This penalty may discourage deny.  Even if the client intends to
   use a stateid of all 0's or all 1's, it must still obtain the
   filehandle for the regular file locking by applications.

   The NFS version 4 protocol provides more aggressive caching
   strategies with the following design goals:

   .IP o Compatibility with OPEN operation so the
   appropriate share semantics can be applied.  For clients that do not
   have a large range of server semantics. .IP o
   Provide deny mode built into their open programming interfaces, deny
   equal to NONE should be used.

   The OPEN operation with the same caching benefits CREATE flag, also subsumes the CREATE
   operation for regular files as used in previous versions of the NFS
   protocol when unable
   protocol.  This allows a create with a share to provide be done atomically.

   The CLOSE operation removes all share reservations held by the more aggressive model. .IP o
   Requirements for aggressive caching are organized so open-
   owner on that a large
   portion of file.  If record locks are held, the benefit can be obtained even when not client SHOULD
   release all of the
   requirements can be met. .LP locks before issuing a CLOSE.  The appropriate requirements for the server are discussed in later sections in which specific forms of
   caching are covered. (see MAY free all
   outstanding locks on CLOSE but some servers may not support the section "Open Delegation").

8.2.  Delegation and Callbacks

   Recallable delegation CLOSE
   of server responsibilities for a file to that still has record locks held.  The server MUST return
   failure, NFS4ERR_LOCKS_HELD, if any locks would exist after the
   CLOSE.

   The LOOKUP operation will return a
   client improves performance by avoiding repeated requests to filehandle without establishing
   any lock state on the server.  Without a valid stateid, the server in
   will assume the absence of inter-client conflict.  With client has the use of least access.  For example, a
   "callback" RPC from server to client, file
   opened with deny READ/WRITE cannot be accessed using a server recalls delegated
   responsibilities when another client engages in sharing of filehandle
   obtained through LOOKUP because it would not have a
   delegated file.

   A delegation valid stateid
   (i.e. using a stateid of all bits 0 or all bits 1).

8.10.  Open Upgrade and Downgrade

   When an OPEN is passed from the server to done for a file and the client, specifying open-owner for which the
   object of open
   is being done already has the delegation and file open, the type of delegation.  There are
   different types of delegations but each type contains a stateid to be
   used result is to represent upgrade the delegation when performing operations that
   depend
   open file status maintained on the delegation.  This stateid is similar server to those
   associated with locks and share reservations but differs in that include the
   stateid for a delegation is associated with a clientid access and may be
   used on behalf of all
   deny bits specified by the open_owners new OPEN as well as those for the given client.  A
   delegation existing
   OPEN.  The result is made to the client that there is one open file, as a whole far as the
   protocol is concerned, and not to any specific
   process or thread it includes the union of control within it.

   Because callback RPCs may not work in all environments (due to
   firewalls, the access and
   deny bits for example), correct protocol operation does not depend
   on them.  Preliminary testing of callback functionality by means all of the OPEN requests completed.  Only a
   CB_NULL procedure determines whether callbacks can single
   CLOSE will be supported.  The
   CB_NULL procedure checks the continuity of done to reset the callback path.  A
   server makes a preliminary assessment effects of callback availability to a
   given client and avoids delegating responsibilities until it has
   determined both OPENs.  Note that callbacks are supported.  Because the granting of a
   delegation is always conditional upon
   client, when issuing the absence of conflicting
   access, clients must OPEN, may not assume know that a delegation will be granted and
   they must always be prepared for OPENs to be processed without any
   delegations the same file is in
   fact being granted.

   Once granted, a delegation behaves opened.  The above only applies if both OPENs result in most ways like a lock.  There
   is an associated lease that is subject to renewal together with all
   of
   the other leases held by that client.

   Unlike locks, an operation OPENed object being designated by a second client to a delegated file
   will cause the same filehandle.

   When the server chooses to recall a delegation through a callback.

   On recall, the client holding the delegation must flush modified
   state (such as modified data) export multiple filehandles corresponding
   to the server same file object and return returns different filehandles on two
   different OPENs of the
   delegation.  The conflicting request will not receive a response
   until same file object, the recall is complete.  The recall is considered complete when server MUST NOT "OR"
   together the client returns access and deny bits and coalesce the delegation or two open files.
   Instead the server times out on the
   recall must maintain separate OPENs with separate
   stateids and revokes will require separate CLOSEs to free them.

   When multiple open files on the delegation as client are merged into a result of single open
   file object on the timeout.
   Following server, the resolution close of one of the recall, open files (on the server has
   client) may necessitate change of the
   information necessary to grant or access and deny status of the second client's request.

   At the time the client receives a delegation recall, it may have
   substantial state that needs to be flushed to
   open file on the server.  Therefore,  This is because the server should allow sufficient time union of the access and
   deny bits for the delegation to be
   returned since it remaining opens may involve numerous RPCs to the server.  If the
   server be smaller (i.e. a proper
   subset) than previously.  The OPEN_DOWNGRADE operation is able used to determine that
   make the necessary change and the client is diligently flushing
   state should use it to update the
   server as a result of so that share reservation requests by other clients are
   handled properly.

8.11.  Short and Long Leases

   When determining the recall, time period for the server may extend lease, the usual time allowed
   lease tradeoffs apply.  Short leases are good for fast server
   recovery at a recall.  However, the time allowed for
   recall completion should not be unbounded.

   An example cost of this is when responsibility increased operations to mediate opens on a given
   file is delegated effect lease renewal
   (when there are no other operations during the period to effect lease
   renewal as a client (see the section "Open Delegation").
   The server will not know what opens side-effect).  Long leases are in certainly kinder and
   gentler to servers trying to handle very large numbers of clients.
   The number of extra requests to effect on lock renewal drop in inverse
   proportion to the client.
   Without this knowledge lease time.  The disadvantages of long leases
   include the possibility of slower recovery after certain failures.
   After server will failure, a longer grace period may be unable to determine if the
   access required when some
   clients do not promptly reclaim their locks and deny state for the file allows any particular open until
   the delegation for do a
   RECLAIM_COMPLETE.  In the file has been returned.

   A event of client failure or a network partition failure, it can result in failure longer
   period for leases to
   respond expire thus forcing conflicting requests to a recall callback.  In this case,
   wait.

   Long leases are usable if the server will revoke
   the delegation which is able to store lease state in turn will render useless any modified
   non-volatile memory.  Upon recovery, the server can reconstruct the
   lease state
   still on from its non-volatile memory and continue operation with
   its clients and therefore long leases would not be an issue.

8.12.  Clocks, Propagation Delay, and Calculating Lease Expiration

   To avoid the client.

8.2.1.  Delegation Recovery

   There need for synchronized clocks, lease times are three situations that delegation recovery must deal with:

   o  Client reboot or restart

   o  Server reboot or restart

   o  Network partition (full or callback-only)

   In granted by
   the event server as a time delta.  However, there is a requirement that the
   client reboots or restarts, and server clocks do not drift excessively over the failure to renew
   leases will result in duration
   of the revocation lock.  There is also the issue of record locks and share
   reservations.  Delegations, however, may propagation delay across the
   network which could easily be treated a bit
   differently.

   There several hundred milliseconds as well as
   the possibility that requests will be situations in which delegations will lost and need to be
   reestablished after a client reboots or restarts.  The reason for
   this is
   retransmitted.

   To take propagation delay into account, the client may have file data stored locally and this data
   was associated with should subtract it
   from lease times (e.g. if the previously held delegations.  The client estimates the one-way
   propagation delay as 200 msec, then it can assume that the lease is
   already 200 msec old when it gets it).  In addition, it will
   need take
   another 200 msec to get a response back to reestablish the appropriate file state on the server.

   To allow for this type of  So the client recovery,
   must send a lock renewal or write data back to the server MAY extend 400 msec
   before the lease would expire.

   The server's lease period for delegation recovery beyond configuration should take into account the
   network distance of the typical lease expiration
   period.  This implies that requests from other clients that conflict
   with these delegations will need to wait.  Because be accessing the normal recall
   process may require significant time for server's
   resources.  It is expected that the client to flush changed
   state to lease period will take into
   account the server, network propagation delays and other clients need be prepared network delay
   factors for delays that
   occur because of a conflicting delegation.  This longer interval
   would increase the window client population.  Since the protocol does not allow
   for clients an automatic method to reboot and consult stable
   storage so that determine an appropriate lease period, the delegations can be reclaimed.  For open
   delegations, such delegations
   server's administrator may have to tune the lease period.

8.13.  Vestigial Locking Infrastructure From V4.0

   There are reclaimed using OPEN with a claim
   type of CLAIM_DELEGATE_PREV.  (See the sections on "Data Caching and
   Revocation" and "Operation 18: OPEN" for discussion number of open
   delegation operations and the details of OPEN respectively).

   A server MAY support fields within existing
   operations that no longer have a claim type function in minor version one.  In
   one way or another, these changes are all due to the implementation
   of CLAIM_DELEGATE_PREV, but if it
   does, it MUST NOT remove delegations upon SETCLIENTID_CONFIRM, sessions which provides client context and
   instead MUST, for replay protection as a period of time no less than that of the value
   base feature of the lease_time attribute, maintain the client's delegations to allow
   time for the client to issue CLAIM_DELEGATE_PREV requests. protocol, separate from locking itself.

   The following operations have become mandatory-to-not-implement.  The
   server that supports CLAIM_DELEGATE_PREV MUST support the DELEGPURGE
   operation.

   When the server reboots or restarts, delegations should return NFS4ERR_NOTSUPP if these operations are reclaimed (using
   the OPEN operation with CLAIM_PREVIOUS) found in a similar fashion
   an NFSv4.1 COMPOUND.

   o  SETCLIENTID since its function has been replaced by
      CREATE_CLIENTID.

   o  SETCLIENTID_CONFIRM since clientid confirmation now happens by
      means of CREATE_SESSION.

   o  OPEN_CONFIRM because OPEN's no longer require confirmation to
   record
      establish an owner-based sequence value.

   o  RELEASE_LOCKOWNER because lock-owners with no associated locks
      have any sequence-related state and share reservations.  However, there is a slight
   semantic difference.  In the normal case if so can be deleted by the
      server decides at will.

   o  RENEW because every SEQUENCE operation for a session causes lease
      renewal, making a separate operation useless.

   Also, there are a number of fields, present in existing operations
   related to locking that have no use in minor version one.  They were
   used in minor version zero to perform functions now provided in a
   delegation should not be granted, it performs the requested action
   (e.g.  OPEN) without granting any delegation.  For reclaim, the
   server grants
   different fashion.

   o  Sequence id's used to sequence requests for a given state-owner
      and to provide replay protection, now provided via sessions.

   o  Clientid's used to identify the delegation but client associated with a special designation given
      request.  Client identification is applied so
   that now available using the client treats
      clientid associated with the delegation as having been granted but
   recalled current session, without needing an
      explicit clientid field.

   Such vestigial fields in existing operations should be set by the server.  Because of this, the
   client has the duty to
   write all modified state to zero.  When they are not, the server and then MUST return the
   delegation.  This process an
   NFS4ERR_INVAL error.

9.  Client-Side Caching

   Client-side caching of handling delegation reclaim reconciles
   three principles data, of file attributes, and of file names is
   essential to providing good performance with the NFS version 4 protocol:

   o  Upon reclaim, protocol.
   Providing distributed cache coherence is a difficult problem and
   previous versions of the NFS protocol have not attempted it.
   Instead, several NFS client reporting resources assigned implementation techniques have been used
   to it reduce the problems that a lack of coherence poses for users.
   These techniques have not been clearly defined by an earlier server instance must be granted those resources.

   o protocol
   specifications and it is often unclear what is valid or invalid
   client behavior.

   The server has unquestionable authority to determine whether
      delegations are to be granted and, once granted, whether they are NFS version 4 protocol uses many techniques similar to be continued.

   o those that
   have been used in previous protocol versions.  The use of callbacks is NFS version 4
   protocol does not provide distributed cache coherence.  However, it
   defines a more limited set of caching guarantees to allow locks and
   share reservations to be depended upon until the used without destructive interference from
   client
      has proven its ability to receive them.

   When side caching.

   In addition, the NFS version 4 protocol introduces a network partition occurs, delegations are subject to freeing delegation
   mechanism which allows many decisions normally made by the server when the lease renewal period expires.  This is similar to
   be made locally by clients.  This mechanism provides efficient
   support of the behavior common cases where sharing is infrequent or where
   sharing is read-only.

9.1.  Performance Challenges for locks and share reservations.  For delegations,
   however, the server may extend Client-Side Caching

   Caching techniques used in previous versions of the period NFS protocol have
   been successful in which conflicting
   requests providing good performance.  However, several
   scalability challenges can arise when those techniques are held off.  Eventually the occurrence of a conflicting
   request from another client will cause revocation used with
   very large numbers of clients.  This is particularly true when
   clients are geographically distributed which classically increases
   the delegation.
   A loss latency for cache revalidation requests.

   The previous versions of the callback path (e.g. by later network configuration
   change) will have NFS protocol repeat their file data
   cache validation requests at the same effect.  A recall request will fail and
   revocation of time the delegation will result. file is opened.  This
   behavior can have serious performance drawbacks.  A client normally finds out about revocation of a delegation when it
   uses common case is
   one in which a stateid associated with file is only accessed by a delegation and receives single client.  Therefore,
   sharing is infrequent.

   In this case, repeated reference to the error
   NFS4ERR_EXPIRED.  It also may server to find out about delegation revocation
   after a client reboot when it attempts that no
   conflicts exist is expensive.  A better option with regards to reclaim
   performance is to allow a delegation and
   receives that same error.  Note client that in the case of repeatedly opens a revoked write
   open delegation, there are issues because data may have been modified
   by file to do
   so without reference to the client whose delegation server.  This is revoked done until potentially
   conflicting operations from another client actually occur.

   A similar situation arises in connection with file locking.  Sending
   file lock and separately by other
   clients.  See the section "Revocation Recovery for Write Open
   Delegation" for a discussion of such issues.  Note also that when
   delegations are revoked, information about the revoked delegation
   will be written by unlock requests to the server to stable storage (as described in as well as the
   section "Crash Recovery").  This is done read and
   write requests necessary to deal make data caching consistent with the case in
   which a server reboots after revoking a delegation but before the
   client holding the revoked delegation is notified about
   locking semantics (see the
   revocation.

8.3.  Data section "Data Caching and File Locking")
   can severely limit performance.  When applications share access locking is used to provide
   protection against infrequent conflicts, a set of files, they need to be
   implemented so as to take account of large penalty is incurred.
   This penalty may discourage the possibility use of conflicting
   access file locking by another application.  This is true whether the applications
   in question execute on different clients or reside on the same
   client.

   Share reservations and record locks are the facilities the applications.

   The NFS version 4 protocol provides to allow applications to coordinate
   access by providing mutual exclusion facilities.  The NFS version 4
   protocol's data more aggressive caching must be implemented such that it does not
   invalidate
   strategies with the assumptions that those using these facilities depend
   upon.

8.3.1.  Data Caching and OPENs

   In order to avoid invalidating following design goals:

   .IP o Compatibility with a large range of server semantics. .IP o
   Provide the same caching benefits as previous versions of the sharing assumptions that
   applications rely on, NFS version 4 clients should not provide cached
   data
   protocol when unable to applications or modify it on behalf provide the more aggressive model. .IP o
   Requirements for aggressive caching are organized so that a large
   portion of an application the benefit can be obtained even when it
   would not all of the
   requirements can be valid to obtain or modify that same data via a READ or
   WRITE operation.

   Furthermore, in met. .LP The appropriate requirements for the absence
   server are discussed in later sections in which specific forms of open delegation
   caching are covered. (see the section "Open
   Delegation") two additional rules apply.  Note that these rules are
   obeyed in practice by many NFS version 2 Delegation").

9.2.  Delegation and version 3 clients.

   o  First, cached data present on Callbacks

   Recallable delegation of server responsibilities for a file to a
   client must be revalidated after
      doing an OPEN.  Revalidating means that the client fetches the
      change attribute from the server, compares it with the cached
      change attribute, and if different, declares the cached data (as
      well as the cached attributes) as invalid.  This is improves performance by avoiding repeated requests to ensure that
      the data for the OPENed file is still correctly reflected
   server in the
      client's cache.  This validation must be done at least when absence of inter-client conflict.  With the
      client's OPEN operation includes DENY=WRITE or BOTH thus
      terminating use of a period in which other clients may have had the
      opportunity
   "callback" RPC from server to open client, a server recalls delegated
   responsibilities when another client engages in sharing of a
   delegated file.

   A delegation is passed from the file with WRITE access.  Clients may
      choose server to do the revalidation more often (i.e. at OPENs client, specifying
      DENY=NONE) to parallel the NFS version 3 protocol's practice for
   object of the benefit delegation and the type of users assuming this degree delegation.  There are
   different types of cache revalidation.

      Since delegations but each type contains a stateid to be
   used to represent the change attribute delegation when performing operations that
   depend on the delegation.  This stateid is updated similar to those
   associated with locks and share reservations but differs in that the
   stateid for data a delegation is associated with a clientid and metadata
      modifications, some client implementors may be tempted
   used on behalf of all the open_owners for the given client.  A
   delegation is made to use the
      time_modify attribute client as a whole and not change to validate cached data, so
      that metadata changes do any specific
   process or thread of control within it.

   Because callback RPCs may not spuriously invalidate clean data.
      The implementor is cautioned work in this approach.  The change
      attribute is guaranteed all environments (due to change
   firewalls, for each update to the file,
      whereas time_modify is guaranteed to change only at the
      granularity example), correct protocol operation does not depend
   on them.  Preliminary testing of the time_delta attribute.  Use callback functionality by means of a
   CB_NULL procedure determines whether callbacks can be supported.  The
   CB_NULL procedure checks the client's data
      cache validation logic continuity of time_modify the callback path.  A
   server makes a preliminary assessment of callback availability to a
   given client and not change runs avoids delegating responsibilities until it has
   determined that callbacks are supported.  Because the risk granting of a
   delegation is always conditional upon the client incorrectly marking stale data as valid.

   o  Second, modified data absence of conflicting
   access, clients must not assume that a delegation will be granted and
   they must always be flushed prepared for OPENs to the server before closing be processed without any
   delegations being granted.

   Once granted, a file OPENed for write.  This delegation behaves in most ways like a lock.  There
   is complementary an associated lease that is subject to renewal together with all
   of the first rule.
      If other leases held by that client.

   Unlike locks, an operation by a second client to a delegated file
   will cause the data is not flushed at CLOSE, server to recall a delegation through a callback.

   On recall, the revalidation done after client OPENs holding the delegation must flush modified
   state (such as file is unable modified data) to achieve its purpose. the server and return the
   delegation.  The other
      aspect to flushing conflicting request will not receive a response
   until the data before close recall is that complete.  The recall is considered complete when
   the data must be
      committed to stable storage, at client returns the server, before delegation or the CLOSE
      operation is requested by server times out on the client.  In
   recall and revokes the case of delegation as a result of the timeout.
   Following the resolution of the recall, the server
      reboot has the
   information necessary to grant or restart and deny the second client's request.

   At the time the client receives a CLOSEd file, delegation recall, it may not have
   substantial state that needs to be possible flushed to
      retransmit the data server.  Therefore,
   the server should allow sufficient time for the delegation to be written
   returned since it may involve numerous RPCs to the file.  Hence, this
      requirement.

8.3.2.  Data Caching and File Locking

   For those applications that choose to use file locking instead of
   share reservations to exclude inconsistent file access, there is an
   analogous set of constraints that apply to client side data caching.
   These rules are effective only if the file locking is used in a way
   that matches in an equivalent way server.  If the actual READ and WRITE
   operations executed.  This
   server is as opposed able to file locking determine that the client is
   based on pure convention.  For example, it is possible diligently flushing
   state to manipulate the server as a two-megabyte file by dividing result of the file into two one-megabyte
   regions and protecting access to recall, the two regions by file locks on
   bytes zero and one.  A lock for write on byte zero of server may extend
   the file would
   represent usual time allowed for a recall.  However, the right time allowed for
   recall completion should not be unbounded.

   An example of this is when responsibility to do READ and WRITE operations mediate opens on a given
   file is delegated to a client (see the first
   region.  A lock for write section "Open Delegation").
   The server will not know what opens are in effect on byte one of the file would represent client.
   Without this knowledge the
   right server will be unable to do READ and WRITE operations on determine if the second region.  As long
   as all applications manipulating
   access and deny state for the file obey this convention, they
   will work on a local filesystem.  However, they may not work with allows any particular open until
   the
   NFS version 4 protocol unless clients refrain from data caching.

   The rules delegation for data caching in the file locking environment are:

   o  First, when a has been returned.

   A client obtains failure or a file lock for network partition can result in failure to
   respond to a particular region, recall callback.  In this case, the data cache corresponding to that region (if server will revoke
   the delegation which in turn will render useless any cache data
      exists) must be revalidated.  If modified state
   still on the change attribute indicates client.

9.2.1.  Delegation Recovery

   There are three situations that delegation recovery must deal with:

   o  Client reboot or restart

   o  Server reboot or restart

   o  Network partition (full or callback-only)

   In the file may have been updated since event the cached data was
      obtained, client reboots or restarts, the failure to renew
   leases will result in the revocation of record locks and share
   reservations.  Delegations, however, may be treated a bit
   differently.

   There will be situations in which delegations will need to be
   reestablished after a client must flush reboots or invalidate restarts.  The reason for
   this is the cached client may have file data for stored locally and this data
   was associated with the newly locked region.  A previously held delegations.  The client might choose will
   need to invalidate all
      of non-modified cached data that it has for reestablish the appropriate file but state on the only
      requirement server.

   To allow for correct operation is to invalidate all this type of client recovery, the data
      in server MAY extend the newly locked region.

   o  Second, before releasing a write lock for a region, all modified
      data
   period for delegation recovery beyond the typical lease expiration
   period.  This implies that region must be flushed requests from other clients that conflict
   with these delegations will need to wait.  Because the server.  The modified
      data must also be written normal recall
   process may require significant time for the client to stable storage.

   Note that flushing data flush changed
   state to the server and the invalidation server, other clients need be prepared for delays that
   occur because of cached
   data must reflect a conflicting delegation.  This longer interval
   would increase the actual byte ranges locked or unlocked.
   Rounding these up or down window for clients to reflect client cache block boundaries
   will cause problems if not carefully done. reboot and consult stable
   storage so that the delegations can be reclaimed.  For example, writing open
   delegations, such delegations are reclaimed using OPEN with a
   modified block when only half claim
   type of that block is within an area being
   unlocked may cause invalid modification to CLAIM_DELEGATE_PREV.  (See the region outside sections on "Data Caching and
   Revocation" and "Operation 18: OPEN" for discussion of open
   delegation and the
   unlocked area.  This, in turn, may be part details of OPEN respectively).

   A server MAY support a region locked by
   another client.  Clients can avoid this situation by synchronously
   performing portions claim type of write operations that overlap that portion
   (initial or final) that is not a full block.  Similarly, invalidating CLAIM_DELEGATE_PREV, but if it
   does, it MUST NOT remove delegations upon SETCLIENTID_CONFIRM, and
   instead MUST, for a locked area which is not an integral number period of full buffer blocks
   would require the client to read one or two partial blocks from the
   server if the revalidation procedure shows time no less than that of the data which value of
   the
   client possesses may not be valid.

   The data that is written to lease_time attribute, maintain the server as a prerequisite client's delegations to allow
   time for the
   unlocking of a region must be written, at the server, client to stable
   storage. issue CLAIM_DELEGATE_PREV requests.  The client may accomplish this either with synchronous
   writes or by following asynchronous writes with a COMMIT
   server that supports CLAIM_DELEGATE_PREV MUST support the DELEGPURGE
   operation.
   This is required because retransmission of

   When the modified data after a server reboot might conflict reboots or restarts, delegations are reclaimed (using
   the OPEN operation with a lock held by another client.

   A client implementation may choose to accommodate applications which
   use record locking CLAIM_PREVIOUS) in non-standard ways (e.g. using a similar fashion to
   record lock as locks and share reservations.  However, there is a global semaphore) by flushing to slight
   semantic difference.  In the normal case if the server more data upon an LOCKU
   than is covered by decides that a
   delegation should not be granted, it performs the locked range.  This may include modified data
   within files other than requested action
   (e.g.  OPEN) without granting any delegation.  For reclaim, the one for which
   server grants the unlocks are being done.
   In such cases, delegation but a special designation is applied so
   that the client must not interfere with applications whose
   READs and WRITEs are being done only within treats the bounds of record
   locks which delegation as having been granted but
   recalled by the application holds.  For example, an application locks
   a single byte server.  Because of a file and proceeds to write that single byte.  A this, the client that chose has the duty to handle a LOCKU by flushing
   write all modified data state to the server could validly write that single byte in response to an
   unrelated unlock.  However, it would not be valid to write and then return the entire
   block in which that single written byte was located since
   delegation.  This process of handling delegation reclaim reconciles
   three principles of the NFS version 4 protocol:

   o  Upon reclaim, a client reporting resources assigned to it includes by an area that is not locked and might
      earlier server instance must be locked by another client.
   Client implementations can avoid this problem by dividing files with
   modified data into granted those for which all modifications resources.

   o  The server has unquestionable authority to determine whether
      delegations are done to
   areas covered by an appropriate record lock and those for which there be granted and, once granted, whether they are modifications not covered by a record lock.  Any writes done for
   the former class of files must not include areas not locked and thus
   not modified on the client.

8.3.3.  Data Caching and Mandatory File Locking

   Client side data caching needs
      to respect mandatory file locking when
   it is in effect. be continued.

   o  The presence use of mandatory file locking for a given
   file callbacks is indicated when not to be depended upon until the client gets back NFS4ERR_LOCKED from a
   READ or WRITE on a file it
      has an appropriate share reservation for. proven its ability to receive them.

   When mandatory locking is in effect for a file, network partition occurs, delegations are subject to freeing
   by the client must check
   for an appropriate file lock for data being read or written.  If a
   lock exists for server when the range being read or written, lease renewal period expires.  This is similar
   to the client may
   satisfy behavior for locks and share reservations.  For delegations,
   however, the request using server may extend the client's validated cache.  If an
   appropriate file lock is not period in which conflicting
   requests are held for off.  Eventually the range occurrence of a conflicting
   request from another client will cause revocation of the read or write, delegation.
   A loss of the read or write request must not be satisfied callback path (e.g. by later network configuration
   change) will have the client's cache
   and the same effect.  A recall request must be sent to will fail and
   revocation of the server for processing.  When delegation will result.

   A client normally finds out about revocation of a
   read or write request partially overlaps delegation when it
   uses a locked region, the request
   should be subdivided into multiple pieces stateid associated with each region (locked or
   not) treated appropriately.

8.3.4.  Data Caching a delegation and File Identity

   When clients cache data, the file data needs to be organized
   according to receives the filesystem object error
   NFS4ERR_EXPIRED.  It also may find out about delegation revocation
   after a client reboot when it attempts to which reclaim a delegation and
   receives that same error.  Note that in the case of a revoked write
   open delegation, there are issues because data belongs.  For
   NFS version 3 clients, the typical practice has may have been to assume for modified
   by the purpose client whose delegation is revoked and separately by other
   clients.  See the section "Revocation Recovery for Write Open
   Delegation" for a discussion of caching such issues.  Note also that distinct filehandles represent distinct
   filesystem objects.  The client then has when
   delegations are revoked, information about the choice revoked delegation
   will be written by the server to organize and
   maintain stable storage (as described in the data cache on this basis.

   In
   section "Crash Recovery").  This is done to deal with the NFS version 4 protocol, there case in
   which a server reboots after revoking a delegation but before the
   client holding the revoked delegation is now notified about the possibility
   revocation.

9.3.  Data Caching

   When applications share access to have
   significant deviations from a "one filehandle per object" model
   because a filehandle may set of files, they need to be constructed on
   implemented so as to take account of the basis possibility of conflicting
   access by another application.  This is true whether the object's
   pathname.  Therefore, applications
   in question execute on different clients need a reliable method to determine if
   two filehandles designate or reside on the same filesystem object.  If clients
   were simply to assume that all distinct filehandles denote distinct
   objects
   client.

   Share reservations and proceed to do data caching on this basis, caching
   inconsistencies would arise between the distinct client side objects
   which mapped to record locks are the same server side object.

   By providing a method to differentiate filehandles, facilities the NFS
   version 4 protocol alleviates a potential functional regression in comparison
   with the provides to allow applications to coordinate
   access by providing mutual exclusion facilities.  The NFS version 3 protocol.  Without this method, 4
   protocol's data caching
   inconsistencies within the same client could occur and this has not
   been present in previous versions of the NFS protocol.  Note that it
   is possible to have must be implemented such inconsistencies with applications executing
   on multiple clients but that is it does not
   invalidate the issue being addressed here.

   For the purposes of data caching, assumptions that those using these facilities depend
   upon.

9.3.1.  Data Caching and OPENs

   In order to avoid invalidating the following steps allow an sharing assumptions that
   applications rely on, NFS version 4 client to determine whether two distinct filehandles denote
   the same server side object:

   o  If GETATTR directed clients should not provide cached
   data to two filehandles returns different values applications or modify it on behalf of
      the fsid attribute, then the filehandles represent distinct
      objects.

   o  If GETATTR for any file with an fsid application when it
   would not be valid to obtain or modify that matches the fsid of the
      two filehandles in question returns a unique_handles attribute
      with same data via a value READ or
   WRITE operation.

   Furthermore, in the absence of TRUE, then open delegation (see the section "Open
   Delegation") two objects additional rules apply.  Note that these rules are distinct.
   obeyed in practice by many NFS version 2 and version 3 clients.

   o  If GETATTR directed to  First, cached data present on a client must be revalidated after
      doing an OPEN.  Revalidating means that the two filehandles does not return client fetches the
      fileid
      change attribute for both of from the handles, then server, compares it cannot be
      determined whether with the two objects are cached
      change attribute, and if different, declares the same.  Therefore,
      operations which depend on that knowledge (e.g. client side cached data
      caching) cannot be done reliably.

   o  If GETATTR directed (as
      well as the cached attributes) as invalid.  This is to ensure that
      the two filehandles returns different
      values data for the fileid attribute, then they are distinct objects.

   o  Otherwise they are the same object.

8.4.  Open Delegation

   When a OPENed file is being OPENed, the server may delegate further handling
   of opens and closes for that file to still correctly reflected in the opening client.  Any such
   delegation is recallable, since
      client's cache.  This validation must be done at least when the circumstances that allowed for
      client's OPEN operation includes DENY=WRITE or BOTH thus
      terminating a period in which other clients may have had the delegation are subject
      opportunity to change.  In particular, open the server file with WRITE access.  Clients may
   receive a conflicting OPEN from another client,
      choose to do the server must
   recall revalidation more often (i.e. at OPENs specifying
      DENY=NONE) to parallel the delegation before deciding whether NFS version 3 protocol's practice for
      the OPEN from benefit of users assuming this degree of cache revalidation.

      Since the other change attribute is updated for data and metadata
      modifications, some client implementors may be granted.  Making a delegation is up tempted to use the server
      time_modify attribute and
   clients should not assume change to validate cached data, so
      that any particular OPEN either will or
   will metadata changes do not result in an open delegation. spuriously invalidate clean data.
      The following implementor is a typical
   set of conditions that servers might use cautioned in deciding whether OPEN
   should be delegated:

   o this approach.  The client must be able to respond change
      attribute is guaranteed to the server's callback
      requests.  The server will use the CB_NULL procedure change for a test of
      callback ability.

   o  The client must have responded properly each update to previous recalls.

   o  There must be no current open conflicting with the requested
      delegation.

   o  There should be no current delegation that conflicts with file,
      whereas time_modify is guaranteed to change only at the
      delegation being requested.

   o  The probability
      granularity of future conflicting open requests should be low
      based on the recent history of time_delta attribute.  Use by the file.

   o  The existence of any server-specific semantics client's data
      cache validation logic of OPEN/CLOSE that
      would make the required handling incompatible with the prescribed
      handling that time_modify and not change runs the delegated client would apply (see below).

   There are two types risk
      of open delegations, read and write.  A read open
   delegation allows a the client incorrectly marking stale data as valid.

   o  Second, modified data must be flushed to handle, on its own, requests to open the server before closing
      a file OPENed for reading that do not deny read access write.  This is complementary to others.  Multiple
   read open delegations may be outstanding simultaneously and do the first rule.
      If the data is not
   conflict.  A write open delegation allows flushed at CLOSE, the revalidation done after
      client to handle, on
   its own, all opens.  Only one write open delegation may exist for a
   given OPENs as file at a given time and it is inconsistent with any read open
   delegations.

   When a client has a read open delegation, it may not make any changes unable to achieve its purpose.  The other
      aspect to flushing the contents or attributes of the file but it data before close is assured that no
   other client may do so.  When a client has a write open delegation,
   it may modify the file data since no other client will must be accessing
      committed to stable storage, at the file's data.  The client holding a write delegation may only
   affect file attributes which are intimately connected with server, before the file
   data: size, time_modify, change.

   When CLOSE
      operation is requested by the client.  In the case of a client has an open delegation, server
      reboot or restart and a CLOSEd file, it does may not send OPENs or
   CLOSEs be possible to
      retransmit the server but updates data to be written to the appropriate status internally. file.  Hence, this
      requirement.

9.3.2.  Data Caching and File Locking

   For a read open delegation, opens that cannot be handled locally
   (opens for write or those applications that deny read access) must be sent choose to the
   server.

   When an open delegation is made, the response use file locking instead of
   share reservations to the OPEN contains exclude inconsistent file access, there is an
   open delegation structure which specifies the following:

   o  the type
   analogous set of delegation (read or write)

   o  space limitation information constraints that apply to control flushing of client side data on close
      (write open delegation only, see caching.
   These rules are effective only if the section "Open Delegation and
      Data Caching")

   o  an nfsace4 specifying read and write permissions
   o file locking is used in a stateid to represent way
   that matches in an equivalent way the delegation for actual READ and WRITE

   The delegation stateid
   operations executed.  This is separate and distinct from the stateid for
   the OPEN proper.  The standard stateid, unlike the delegation
   stateid, as opposed to file locking that is associated with
   based on pure convention.  For example, it is possible to manipulate
   a particular lock_owner two-megabyte file by dividing the file into two one-megabyte
   regions and will continue protecting access to be valid after the delegation is recalled two regions by file locks on
   bytes zero and one.  A lock for write on byte zero of the file remains
   open.

   When a request internal to would
   represent the client is made right to open a file do READ and open
   delegation is in effect, it will be accepted or rejected solely WRITE operations on the basis first
   region.  A lock for write on byte one of the following conditions.  Any requirement for other
   checks file would represent the
   right to be made by do READ and WRITE operations on the delegate should result in open delegation
   being denied so that second region.  As long
   as all applications manipulating the checks can be made by file obey this convention, they
   will work on a local file system.  However, they may not work with
   the server itself.

   o NFS version 4 protocol unless clients refrain from data caching.

   The access and deny bits rules for the request and the file as described data caching in the section "Share Reservations". file locking environment are:

   o  The read and write permissions as determined below.

   The nfsace4 passed with delegation can be used  First, when a client obtains a file lock for a particular region,
      the data cache corresponding to avoid frequent
   ACCESS calls.  The permission check should that region (if any cache data
      exists) must be as follows:

   o revalidated.  If the nfsace4 change attribute indicates
      that the open file may be done, then it should
      be granted without reference to have been updated since the server.

   o  If cached data was
      obtained, the nfsace4 indicates that client must flush or invalidate the open may not be done, then an
      ACCESS request must be sent to cached data for
      the server newly locked region.  A client might choose to obtain the definitive
      answer.

   The server may return an nfsace4 that is more restrictive than the
   actual ACL of the file.  This includes an nfsace4 that specifies
   denial of invalidate all access.  Note
      of non-modified cached data that some common practices such as
   mapping the traditional user "root" to the user "nobody" may make it
   incorrect to return the actual ACL of has for the file in the delegation
   response.

   The use of delegation together with various other forms of caching
   creates but the possibility that no server authentication will ever be
   performed only
      requirement for a given user since correct operation is to invalidate all of the user's requests might be
   satisfied locally.  Where the client is depending on data
      in the server newly locked region.

   o  Second, before releasing a write lock for
   authentication, the client should be sure authentication occurs a region, all modified
      data for
   each user by use of the ACCESS operation.  This should that region must be flushed to the case
   even if an ACCESS operation would not server.  The modified
      data must also be required otherwise.  As
   mentioned before, written to stable storage.

   Note that flushing data to the server may enforce frequent authentication by
   returning an nfsace4 denying all access with every open delegation.

8.4.1.  Open Delegation and Data Caching

   OPEN delegation allows much of the message overhead associated with invalidation of cached
   data must reflect the opening and closing files actual byte ranges locked or unlocked.
   Rounding these up or down to be eliminated.  An open when an open
   delegation is in effect does reflect client cache block boundaries
   will cause problems if not require that carefully done.  For example, writing a validation message be
   sent
   modified block when only half of that block is within an area being
   unlocked may cause invalid modification to the server.  The continued endurance of region outside the "read open
   delegation" provides
   unlocked area.  This, in turn, may be part of a guarantee that no OPEN for write and thus no region locked by
   another client.  Clients can avoid this situation by synchronously
   performing portions of write has occurred. operations that overlap that portion
   (initial or final) that is not a full block.  Similarly, when closing invalidating
   a file opened for write
   and if write open delegation locked area which is in effect, not an integral number of full buffer blocks
   would require the client to read one or two partial blocks from the
   server if the revalidation procedure shows that the data written does which the
   client possesses may not
   have to be flushed valid.

   The data that is written to the server until as a prerequisite to the open delegation is
   recalled.
   unlocking of a region must be written, at the server, to stable
   storage.  The continued endurance client may accomplish this either with synchronous
   writes or by following asynchronous writes with a COMMIT operation.
   This is required because retransmission of the open delegation provides modified data after a
   guarantee that no open and thus no read or write has been done
   server reboot might conflict with a lock held by another client.

   For

   A client implementation may choose to accommodate applications which
   use record locking in non-standard ways (e.g. using a record lock as
   a global semaphore) by flushing to the purposes of open delegation, server more data upon an LOCKU
   than is covered by the locked range.  This may include modified data
   within files other than the one for which the unlocks are being done.
   In such cases, the client must not interfere with applications whose
   READs and WRITEs done without an
   OPEN are treated as being done only within the functional equivalents bounds of record
   locks which the application holds.  For example, an application locks
   a corresponding
   type single byte of OPEN.  This refers to the READs a file and WRITEs proceeds to write that use the
   special stateids consisting of all zero bits or all one bits.
   Therefore, READs or WRITEs with single byte.  A
   client that chose to handle a special stateid done LOCKU by another
   client will force flushing all modified data to
   the server could validly write that single byte in response to an
   unrelated unlock.  However, it would not be valid to recall a write open delegation.  A
   WRITE with a special stateid done the entire
   block in which that single written byte was located since it includes
   an area that is not locked and might be locked by another client will force a
   recall of read open delegations.

   With delegations, a client is able to client.
   Client implementations can avoid writing this problem by dividing files with
   modified data into those for which all modifications are done to
   areas covered by an appropriate record lock and those for which there
   are modifications not covered by a record lock.  Any writes done for
   the
   server when the CLOSE former class of a files must not include areas not locked and thus
   not modified on the client.

9.3.3.  Data Caching and Mandatory File Locking

   Client side data caching needs to respect mandatory file locking when
   it is serviced. in effect.  The presence of mandatory file locking for a given
   file close system
   call is the usual point at which indicated when the client is notified of gets back NFS4ERR_LOCKED from a
   READ or WRITE on a lack of
   stable storage for the modified file data generated by the
   application.  At the close, file data is written to the server and
   through normal accounting the server it has an appropriate share reservation for.
   When mandatory locking is able to determine if the
   available filesystem space in effect for a file, the client must check
   for an appropriate file lock for data has been exceeded (i.e.
   server returns NFS4ERR_NOSPC being read or NFS4ERR_DQUOT).  This accounting
   includes quotas.  The introduction of delegations requires that written.  If a
   alternative method be in place
   lock exists for the same type of communication to
   occur between range being read or written, the client and server.

   In may
   satisfy the delegation response, request using the server provides either client's validated cache.  If an
   appropriate file lock is not held for the limit range of the size of read or write,
   the file read or write request must not be satisfied by the number of modified blocks client's cache
   and associated
   block size.  The server must ensure that the client will request must be able to
   flush data sent to the server of for processing.  When a size equal to that provided in
   read or write request partially overlaps a locked region, the
   original delegation.  The server must make this assurance for all
   outstanding delegations.  Therefore, the server must request
   should be careful in
   its management of available space for new or modified data taking subdivided into account available filesystem space and any applicable quotas.
   The server can recall delegations as a result of managing the
   available filesystem space.  The client should abide by the server's
   state space limits for delegations.  If the client exceeds the stated
   limits for the delegation, the server's behavior is undefined.

   Based on server conditions, quotas multiple pieces with each region (locked or available filesystem space,
   not) treated appropriately.

9.3.4.  Data Caching and File Identity

   When clients cache data, the
   server may grant write open delegations with very restrictive space
   limitations.  The limitations may be defined in a way that will
   always force modified file data needs to be flushed organized
   according to the server on close.

   With respect file system object to authentication, flushing modified which the data to belongs.  For
   NFS version 3 clients, the server
   after a CLOSE typical practice has occurred may be problematic.  For example, been to assume for
   the user purpose of the application may have logged off the caching that distinct filehandles represent distinct
   file system objects.  The client and unexpired
   authentication credentials may not be present.  In this case, then has the
   client may need to take special care choice to ensure that local unexpired
   credentials will in fact be available.  This may be accomplished by
   tracking the expiration time of credentials organize and flushing
   maintain the data well in
   advance of their expiration or by making private copies of
   credentials cache on this basis.

   In the NFS version 4 protocol, there is now the possibility to assure their availability when needed.

8.4.2.  Open Delegation and File Locks

   When have
   significant deviations from a client holds "one filehandle per object" model
   because a write open delegation, lock operations are
   performed locally.  This includes those required for mandatory file
   locking.  This can filehandle may be done since constructed on the delegation implies that there
   can be no conflicting locks.  Similarly, all basis of the revalidations object's
   pathname.  Therefore, clients need a reliable method to determine if
   two filehandles designate the same file system object.  If clients
   were simply to assume that would normally be associated with obtaining locks all distinct filehandles denote distinct
   objects and the
   flushing of proceed to do data associated with caching on this basis, caching
   inconsistencies would arise between the releasing of locks need not be
   done.

   When a distinct client holds a read open delegation, lock operations are not
   performed locally.  All lock operations, including those requesting
   non-exclusive locks, are sent side objects
   which mapped to the same server for resolution.

8.4.3.  Handling of CB_GETATTR

   The server needs to employ special handling for side object.

   By providing a GETATTR where method to differentiate filehandles, the
   target is a file that has NFS version 4
   protocol alleviates a write open delegation potential functional regression in effect.  The
   reason for comparison
   with the NFS version 3 protocol.  Without this is that method, caching
   inconsistencies within the same client holding the write delegation may
   have modified the data could occur and the server needs to reflect this change to has not
   been present in previous versions of the second client NFS protocol.  Note that submitted the GETATTR.  Therefore, the client
   holding the write delegation needs it
   is possible to be interrogated.  The server
   will use the CB_GETATTR operation.  The only attributes have such inconsistencies with applications executing
   on multiple clients but that the
   server can reliably query via CB_GETATTR are size and change.

   Since CB_GETATTR is not the issue being used addressed here.

   For the purposes of data caching, the following steps allow an NFS
   version 4 client to satisfy another client's GETATTR
   request, determine whether two distinct filehandles denote
   the same server only needs side object:

   o  If GETATTR directed to know if two filehandles returns different values of
      the client holding fsid attribute, then the
   delegation has filehandles represent distinct
      objects.

   o  If GETATTR for any file with an fsid that matches the fsid of the
      two filehandles in question returns a modified version unique_handles attribute
      with a value of TRUE, then the file. two objects are distinct.

   o  If GETATTR directed to the client's copy two filehandles does not return the
      fileid attribute for both of the delegated file is not modified (data or size), handles, then it cannot be
      determined whether the server can
   satisfy two objects are the second client's same.  Therefore,
      operations which depend on that knowledge (e.g. client side data
      caching) cannot be done reliably.

   o  If GETATTR request from directed to the attributes
   stored locally at two filehandles returns different
      values for the server.  If fileid attribute, then they are distinct objects.

   o  Otherwise they are the same object.

9.4.  Open Delegation

   When a file is modified, being OPENed, the server
   only needs may delegate further handling
   of opens and closes for that file to know about this modified state.  If the server
   determines opening client.  Any such
   delegation is recallable, since the circumstances that allowed for
   the file is currently modified, it will respond delegation are subject to change.  In particular, the second client's GETATTR as if server may
   receive a conflicting OPEN from another client, the file had been modified locally
   at server must
   recall the server.

   Since delegation before deciding whether the form of OPEN from the change attribute other
   client may be granted.  Making a delegation is determined by up to the server and
   clients should not assume that any particular OPEN either will or
   will not result in an open delegation.  The following is opaque a typical
   set of conditions that servers might use in deciding whether OPEN
   should be delegated:

   o  The client must be able to respond to the client, the client and server's callback
      requests.  The server need to agree on a
   method of communicating will use the modified state CB_NULL procedure for a test of the file.  For the size
   attribute, the
      callback ability.

   o  The client will report its must have responded properly to previous recalls.

   o  There must be no current view of the file size.
   For the change attribute, the handling is more involved.

   For the client, open conflicting with the following steps will requested
      delegation.

   o  There should be taken when receiving a
   write delegation: no current delegation that conflicts with the
      delegation being requested.

   o  The value probability of the change attribute will future conflicting open requests should be obtained from low
      based on the server
      and cached.  Let this value be represented by c. recent history of the file.

   o  The client will create a value greater than c existence of any server-specific semantics of OPEN/CLOSE that will be used
      for communicating modified data is held at
      would make the client.  Let this
      value be represented by d.

   o  When required handling incompatible with the client is queried via CB_GETATTR for prescribed
      handling that the change
      attribute, it checks delegated client would apply (see below).

   There are two types of open delegations, read and write.  A read open
   delegation allows a client to see if it holds modified data.  If the handle, on its own, requests to open a
   file is modified, the value d is returned for the change attribute
      value.  If this file is reading that do not currently modified, the client returns
      the value c for the change attribute.

   For simplicity of implementation, deny read access to others.  Multiple
   read open delegations may be outstanding simultaneously and do not
   conflict.  A write open delegation allows the client MAY to handle, on
   its own, all opens.  Only one write open delegation may exist for each CB_GETATTR
   return the same value d.  This a
   given file at a given time and it is true even if, between successive
   CB_GETATTR operations, the inconsistent with any read open
   delegations.

   When a client again modifies in has a read open delegation, it may not make any changes
   to the file's data contents or metadata in its cache.  The client can return the same value
   because attributes of the only requirement file but it is assured that no
   other client may do so.  When a client has a write open delegation,
   it may modify the file data since no other client will be able to indicate
   to the server that accessing
   the client holds modified file's data.  Therefore, the
   value of d  The client holding a write delegation may always be c + 1.

   While the change attribute is opaque to only
   affect file attributes which are intimately connected with the file
   data: size, time_modify, change.

   When a client in the sense that
   it has no idea what units of time, if any, the server is counting
   change with, an open delegation, it is does not opaque in that the client has send OPENs or
   CLOSEs to treat it as
   an unsigned integer, and the server has to be able to see the results
   of but updates the client's changes to appropriate status internally.
   For a read open delegation, opens that integer.  Therefore, the server MUST
   encode the change attribute in network order when sending it cannot be handled locally
   (opens for write or that deny read access) must be sent to the
   client.  The client MUST decode it from network order to its native
   order when receiving it and
   server.

   When an open delegation is made, the client MUST encode it network order
   when sending it response to the server.  For this reason, change is defined as
   an unsigned integer rather than OPEN contains an opaque array of octets.

   For the server,
   open delegation structure which specifies the following steps will be taken when providing a
   write delegation: following:

   o  Upon providing a write delegation,  the server will cache a copy type of
      the change attribute in the data structure it uses delegation (read or write)

   o  space limitation information to record control flushing of data on close
      (write open delegation only, see the
      delegation.  Let this value be represented by sc. section "Open Delegation and
      Data Caching")

   o  an nfsace4 specifying read and write permissions
   o  When a second client sends  a GETATTR operation on the same file stateid to represent the server, the server obtains the change attribute delegation for READ and WRITE

   The delegation stateid is separate and distinct from the first
      client.  Let this value be cc.

   o  If stateid for
   the value cc OPEN proper.  The standard stateid, unlike the delegation
   stateid, is equal associated with a particular lock_owner and will continue
   to sc, be valid after the file delegation is not modified recalled and the
      server returns the current values for change, time_metadata, and
      time_modify (for example) file remains
   open.

   When a request internal to the second client.

   o  If the value cc client is NOT equal made to sc, the open a file is currently modified
      at the first client and most likely open
   delegation is in effect, it will be modified at accepted or rejected solely on
   the server
      at a future time.  The server then uses its current time to
      construct attribute values for time_metadata and time_modify.  A
      new value basis of sc, which we will call nsc, is computed the following conditions.  Any requirement for other
   checks to be made by the
      server, such delegate should result in open delegation
   being denied so that nsc >= sc + 1.  The the checks can be made by the server then returns itself.

   o  The access and deny bits for the
      constructed time_metadata, time_modify, request and nsc values to the
      requester.  The server replaces sc file as described
      in the delegation record with
      nsc.  To prevent the possibility of time_modify, time_metadata, section "Share Reservations".

   o  The read and change from appearing write permissions as determined below.

   The nfsace4 passed with delegation can be used to go backward (which would happen if avoid frequent
   ACCESS calls.  The permission check should be as follows:

   o  If the client holding nfsace4 indicates that the delegation fails open may be done, then it should
      be granted without reference to write its modified data the server.

   o  If the nfsace4 indicates that the open may not be done, then an
      ACCESS request must be sent to the server before the delegation is revoked or returned), to obtain the definitive
      answer.

   The server SHOULD update may return an nfsace4 that is more restrictive than the file's metadata record with
   actual ACL of the
      constructed attribute values.  For reasons file.  This includes an nfsace4 that specifies
   denial of reasonable
      performance, committing all access.  Note that some common practices such as
   mapping the constructed attribute values traditional user "root" to stable
      storage is OPTIONAL.

   As discussed earlier in this section, the client MAY user "nobody" may make it
   incorrect to return the same
   cc value on subsequent CB_GETATTR calls, even if actual ACL of the file was
   modified in the client's cache yet again between successive
   CB_GETATTR calls.  Therefore, delegation
   response.

   The use of delegation together with various other forms of caching
   creates the server must assume possibility that no server authentication will ever be
   performed for a given user since all of the file
   has been modified yet again, and MUST take care to ensure that user's requests might be
   satisfied locally.  Where the
   new nsc it constructs and returns client is greater than depending on the previous nsc it
   returned.  An example implementation's delegation record would
   satisfy this mandate by including a boolean field (let us call it
   "modified") that is set to false when server for
   authentication, the delegation is granted, and
   an sc value set at the time of grant to the change attribute value.
   The modified field would client should be set to true the first time cc != sc, and
   would stay true until the delegation is returned or revoked.  The
   processing sure authentication occurs for constructing nsc, time_modify, and time_metadata would
   each user by use this pseudo code:

   if (!modified) {
       do CB_GETATTR for change and size;

       if (cc != sc)
           modified = TRUE;
   } else {
       do CB_GETATTR for size;
   }

   if (modified) {
       sc = sc + 1;
       time_modify = time_metadata = current_time;
       update sc, time_modify, time_metadata into file's metadata;
   }

   return to client (that sent GETATTR) the attributes
   it requested, but make sure size comes from what
   CB_GETATTR returned. Do not update the file's metadata
   with of the client's modified size.

   In ACCESS operation.  This should be the case that the file attribute size is different than the
   server's current value,
   even if an ACCESS operation would not be required otherwise.  As
   mentioned before, the server treats this as a modification
   regardless may enforce frequent authentication by
   returning an nfsace4 denying all access with every open delegation.

9.4.1.  Open Delegation and Data Caching

   OPEN delegation allows much of the value of message overhead associated with
   the change attribute retrieved via
   CB_GETATTR opening and responds closing files to the second client as be eliminated.  An open when an open
   delegation is in effect does not require that a validation message be
   sent to the last step.

   This methodology resolves issues server.  The continued endurance of clock differences between client the "read open
   delegation" provides a guarantee that no OPEN for write and server thus no
   write has occurred.  Similarly, when closing a file opened for write
   and other scenarios where if write open delegation is in effect, the use of CB_GETATTR break
   down.

   It should data written does not
   have to be noted that the server is under no obligation flushed to use
   CB_GETATTR and therefore the server MAY simply recall until the open delegation
   to avoid its use.

8.4.4.  Recall of Open Delegation is
   recalled.  The following events necessitate recall continued endurance of an the open delegation:

   o  Potentially conflicting OPEN request (or READ/WRITE delegation provides a
   guarantee that no open and thus no read or write has been done with
      "special" stateid)

   o  SETATTR issued by
   another client

   o  REMOVE request for the file

   o  RENAME request for client.

   For the file as either source or target purposes of open delegation, READs and WRITEs done without an
   OPEN are treated as the
      RENAME

   Whether a RENAME functional equivalents of a directory in the path leading corresponding
   type of OPEN.  This refers to the file
   results in recall of an open delegation depends on READs and WRITEs that use the semantics
   special stateids consisting of
   the server filesystem.  If that filesystem denies such RENAMEs when all zero bits or all one bits.
   Therefore, READs or WRITEs with a
   file is open, the recall must be performed to determine whether the
   file in question is, in fact, open.

   In addition to the situations above, special stateid done by another
   client will force the server may choose to recall a write open delegations at any time if resource constraints make it
   advisable to do so.  Clients should always be prepared for the
   possibility of recall.

   When delegation.  A
   WRITE with a special stateid done by another client receives will force a
   recall for an of read open delegation, it needs delegations.

   With delegations, a client is able to avoid writing data to
   update state on the
   server before returning when the delegation.  These
   same updates must be done whenever CLOSE of a file is serviced.  The file close system
   call is the usual point at which the client chooses to return is notified of a
   delegation voluntarily.  The following items lack of state need to be
   dealt with:

   o  If
   stable storage for the modified file associated with data generated by the delegation
   application.  At the close, file data is no longer open and
      no previous CLOSE operation has been sent written to the server, a CLOSE
      operation must be sent server and
   through normal accounting the server is able to determine if the server.

   o  If a
   available file has other open references at the client, then OPEN
      operations must be sent to system space for the server. data has been exceeded (i.e.
   server returns NFS4ERR_NOSPC or NFS4ERR_DQUOT).  This accounting
   includes quotas.  The appropriate stateids
      will introduction of delegations requires that a
   alternative method be provided by the server in place for subsequent use by the same type of communication to
   occur between client
      since and server.

   In the delegation stateid will not longer be valid.  These OPEN
      requests are done with response, the claim type server provides either the limit of CLAIM_DELEGATE_CUR.  This
      will allow
   the presentation size of the delegation stateid so file or the number of modified blocks and associated
   block size.  The server must ensure that the client can establish the appropriate rights will be able to
   flush data to perform the OPEN.
      (see server of a size equal to that provided in the section "Operation 18: OPEN"
   original delegation.  The server must make this assurance for details.)

   o  If there are granted file locks, all
   outstanding delegations.  Therefore, the corresponding LOCK operations
      need to server must be performed.  This applies to the write open delegation
      case only.

   o  For a write open delegation, if at the time careful in
   its management of recall the file is
      not open available space for write, all new or modified data for taking
   into account available file system space and any applicable quotas.
   The server can recall delegations as a result of managing the
   available file must be flushed
      to system space.  The client should abide by the server. server's
   state space limits for delegations.  If the delegation had not existed, the client
      would have done this data flush before exceeds the CLOSE operation.

   o  For a stated
   limits for the delegation, the server's behavior is undefined.

   Based on server conditions, quotas or available file system space,
   the server may grant write open delegation when delegations with very restrictive
   space limitations.  The limitations may be defined in a file is still open at the time
      of recall, any way that will
   always force modified data for the file needs to be flushed to the server.

   o server on close.

   With respect to authentication, flushing modified data to the write open delegation in place, it is possible that the
      file was truncated during the duration of the delegation. server
   after a CLOSE has occurred may be problematic.  For example, the truncation could have occurred as a result of an OPEN
      UNCHECKED with a size attribute value of zero.  Therefore, if a
      truncation user
   of the file has occurred application may have logged off the client and this operation has unexpired
   authentication credentials may not
      been propagated to the server, be present.  In this case, the truncation must occur before
      any modified data is written
   client may need to take special care to ensure that local unexpired
   credentials will in fact be available.  This may be accomplished by
   tracking the server.

   In the case expiration time of write open delegation, file locking imposes some
   additional requirements.  To precisely maintain the associated
   invariant, it is required to flush any modified credentials and flushing data well in any region
   for which
   advance of their expiration or by making private copies of
   credentials to assure their availability when needed.

9.4.2.  Open Delegation and File Locks

   When a client holds a write open delegation, lock was released while the write delegation was in
   effect.  However, because operations are
   performed locally.  This includes those required for mandatory file
   locking.  This can be done since the write open delegation implies that there
   can be no other
   locking by other clients, a simpler implementation is to flush conflicting locks.  Similarly, all
   modified of the revalidations
   that would normally be associated with obtaining locks and the
   flushing of data associated with the releasing of locks need not be
   done.

   When a client holds a read open delegation, lock operations are not
   performed locally.  All lock operations, including those requesting
   non-exclusive locks, are sent to the server for resolution.

9.4.3.  Handling of CB_GETATTR

   The server needs to employ special handling for a GETATTR where the
   target is a file (as described just above) if any write
   lock that has been released while the a write open delegation was in effect.

   An implementation need not wait until  The
   reason for this is that the client holding the write delegation recall (or deciding may
   have modified the data and the server needs to voluntarily return a delegation) reflect this change to perform any of
   the above
   actions, if implementation considerations (e.g. resource availability
   constraints) make second client that desirable.  Generally, however, submitted the fact that GETATTR.  Therefore, the actual open state of client
   holding the file may continue to change makes it not
   worthwhile write delegation needs to send information about opens be interrogated.  The server
   will use the CB_GETATTR operation.  The only attributes that the
   server can reliably query via CB_GETATTR are size and closes change.

   Since CB_GETATTR is being used to satisfy another client's GETATTR
   request, the server,
   except as part of delegation return.  Only in server only needs to know if the case client holding the
   delegation has a modified version of closing the
   open that resulted in obtaining file.  If the delegation would clients be
   likely to do this early, since, in that case, client's copy
   of the close once done
   will delegated file is not be undone.  Regardless of modified (data or size), the server can
   satisfy the second client's choices on scheduling
   these actions, all must be performed before GETATTR request from the delegation attributes
   stored locally at the server.  If the file is
   returned, including (when applicable) modified, the close that corresponds server
   only needs to know about this modified state.  If the open server
   determines that resulted in the delegation.  These actions can be
   performed either in previous requests or in previous operations in the same COMPOUND request.

8.4.5.  Clients that Fail to Honor Delegation Recalls

   A client may fail to file is currently modified, it will respond to a recall for various reasons, such
   the second client's GETATTR as
   a failure if the file had been modified locally
   at the server.

   Since the form of the callback path from change attribute is determined by the server
   and is opaque to the client.  The client, the client
   may be unaware of and server need to agree on a failure in
   method of communicating the callback path.  This lack modified state of
   awareness could result in the client finding out long after file.  For the size
   attribute, the
   failure that its delegation has been revoked, and another client has
   modified will report its current view of the data for which file size.
   For the client had a delegation.  This change attribute, the handling is
   especially a problem for more involved.

   For the client that held client, the following steps will be taken when receiving a
   write delegation. delegation:

   o  The server also has a dilemma in that value of the client that fails to
   respond to change attribute will be obtained from the recall might also server
      and cached.  Let this value be sending other NFS requests,
   including those represented by c.

   o  The client will create a value greater than c that renew the lease before the lease expires.
   Without returning an error will be used
      for those lease renewing operations, communicating modified data is held at the
   server leads client.  Let this
      value be represented by d.

   o  When the client to believe that is queried via CB_GETATTR for the delegation change
      attribute, it has is in
   force.

   This difficulty checks to see if it holds modified data.  If the
      file is solved by modified, the following rules:

   o  When value d is returned for the callback path change attribute
      value.  If this file is down, not currently modified, the server MUST NOT revoke client returns
      the
      delegation if one value c for the change attribute.

   For simplicity of implementation, the following occurs:

      *  The client has issued a RENEW operation and MAY for each CB_GETATTR
   return the server has
         returned an NFS4ERR_CB_PATH_DOWN error.  The server MUST renew same value d.  This is true even if, between successive
   CB_GETATTR operations, the lease for any record locks and share reservations client again modifies in the file's data
   or metadata in its cache.  The client has that can return the server has known about (as opposed to those
         locks and share reservations same value
   because the only requirement is that the client has established but not
         yet sent be able to the server, due indicate
   to the delegation).  The server
         SHOULD give that the client a reasonable time to return its
         delegations to holds modified data.  Therefore, the server before revoking
   value of d may always be c + 1.

   While the change attribute is opaque to the client's
         delegations.

      *  The client in the sense that
   it has not issued a RENEW operation for some period no idea what units of
         time after time, if any, the server attempted is counting
   change with, it is not opaque in that the client has to recall treat it as
   an unsigned integer, and the delegation.  This
         period of time MUST NOT server has to be less than able to see the value results
   of the
         lease_time attribute.

   o  When client's changes to that integer.  Therefore, the client holds a delegation, server MUST
   encode the change attribute in network order when sending it can not rely on operations,
      except for RENEW, that take a stateid, to renew delegation leases
      across callback path failures. the
   client.  The client that wants MUST decode it from network order to keep
      delegations in force across callback path failures must use RENEW its native
   order when receiving it and the client MUST encode it network order
   when sending it to do so.

8.4.6.  Delegation Revocation

   At the point a delegation server.  For this reason, change is revoked, if there are associated opens
   on defined as
   an unsigned integer rather than an opaque array of octets.

   For the client, server, the applications holding these opens need to following steps will be
   notified.  This notification usually occurs by returning errors for
   READ/WRITE operations or taken when providing a close is attempted for
   write delegation:

   o  Upon providing a write delegation, the open file.

   If no opens exist for server will cache a copy of
      the change attribute in the data structure it uses to record the
      delegation.  Let this value be represented by sc.

   o  When a second client sends a GETATTR operation on the same file at to
      the point server, the delegation is
   revoked, then notification of server obtains the revocation change attribute from the first
      client.  Let this value be cc.

   o  If the value cc is unnecessary.
   However, if there equal to sc, the file is not modified data present at and the client for
      server returns the
   file, current values for change, time_metadata, and
      time_modify (for example) to the user of second client.

   o  If the application should be notified.  Unfortunately,
   it may not be possible value cc is NOT equal to notify sc, the user since active applications
   may not be present file is currently modified
      at the client.  See first client and most likely will be modified at the section "Revocation
   Recovery for Write Open Delegation" server
      at a future time.  The server then uses its current time to
      construct attribute values for additional details.

8.5.  Data Caching and Revocation

   When locks time_metadata and delegations are revoked, the assumptions upon time_modify.  A
      new value of sc, which
   successful caching depend are no longer guaranteed.  For any locks or
   share reservations we will call nsc, is computed by the
      server, such that have been revoked, nsc >= sc + 1.  The server then returns the corresponding owner
   needs
      constructed time_metadata, time_modify, and nsc values to be notified.  This notification includes applications with a
   file open that has a corresponding the
      requester.  The server replaces sc in the delegation which has been revoked.
   Cached data associated record with
      nsc.  To prevent the revocation must be removed possibility of time_modify, time_metadata,
      and change from appearing to go backward (which would happen if
      the
   client.  In client holding the case of delegation fails to write its modified data existing in the client's cache,
   that data must be removed from the client without it being written
      to the server.  As mentioned, server before the assumptions made by delegation is revoked or returned), the client are no
   longer valid at
      server SHOULD update the point when a lock or delegation has been revoked. file's metadata record with the
      constructed attribute values.  For example, another reasons of reasonable
      performance, committing the constructed attribute values to stable
      storage is OPTIONAL.

   As discussed earlier in this section, the client may have been granted a conflicting lock
   after MAY return the revocation of same
   cc value on subsequent CB_GETATTR calls, even if the lock at file was
   modified in the first client. client's cache yet again between successive
   CB_GETATTR calls.  Therefore, the
   data within server must assume that the lock range may have file
   has been modified by the other
   client.  Obviously, yet again, and MUST take care to ensure that the first client
   new nsc it constructs and returns is unable to guarantee to greater than the
   application what has occurred previous nsc it
   returned.  An example implementation's delegation record would
   satisfy this mandate by including a boolean field (let us call it
   "modified") that is set to false when the file in delegation is granted, and
   an sc value set at the case time of revocation.

   Notification grant to a lock owner will in many cases consist of simply
   returning an error on the next and all subsequent READs/WRITEs change attribute value.
   The modified field would be set to true the
   open file or on the close.  Where first time cc != sc, and
   would stay true until the methods available to a client
   make such notification impossible because errors for certain
   operations may not be returned, more drastic action such as signals delegation is returned or process termination may be appropriate. revoked.  The justification
   processing for constructing nsc, time_modify, and time_metadata would
   use this is that an invariant for which an application depends on may be
   violated.  Depending on how errors are typically treated pseudo code:

   if (!modified) {
       do CB_GETATTR for the
   client operating environment, further levels of notification
   including logging, console messages, change and GUI pop-ups may be
   appropriate.

8.5.1.  Revocation Recovery for Write Open Delegation

   Revocation recovery for a write open delegation poses the special
   issue of size;

       if (cc != sc)
           modified data in the = TRUE;
   } else {
       do CB_GETATTR for size;
   }

   if (modified) {
       sc = sc + 1;
       time_modify = time_metadata = current_time;
       update sc, time_modify, time_metadata into file's metadata;
   }

   return to client cache while (that sent GETATTR) the file is not
   open.  In this situation, any client which does attributes
   it requested, but make sure size comes from what
   CB_GETATTR returned. Do not flush update the file's metadata
   with the client's modified
   data to size.

   In the server on each close must ensure case that the user receives
   appropriate notification of file attribute size is different than the failure
   server's current value, the server treats this as a result modification
   regardless of the
   revocation.  Since such situations may require human action to
   correct problems, notification schemes in which value of the appropriate user
   or administrator is notified may be necessary.  Logging change attribute retrieved via
   CB_GETATTR and console
   messages are typical examples.

   If there is modified data on the client, it must not be flushed
   normally responds to the server.  A second client may attempt to provide a copy of
   the file data as modified during the delegation under a different
   name in the filesystem name space to ease recovery.  Note that when
   the last step.

   This methodology resolves issues of clock differences between client can determine that the file has not been modified by any
   and server and other client, or when the client has a complete cached copy of file
   in question, such a saved copy of scenarios where the client's view use of the file may CB_GETATTR break
   down.

   It should be of particular value for recovery.  In other case, recovery using a
   copy of the file based partially on noted that the client's cached data server is under no obligation to use
   CB_GETATTR and
   partially on therefore the server copy as modified by other clients, will be
   anything but straightforward, so clients may avoid saving file
   contents in these situations or mark MAY simply recall the results specially to warn
   users of possible problems.

   Saving of such modified data in delegation revocation situations may
   be limited
   to files avoid its use.

9.4.4.  Recall of a certain size or might be used only when
   sufficient disk space is available within the target filesystem.
   Such saving may also be restricted to situations when the Open Delegation

   The following events necessitate recall of an open delegation:

   o  Potentially conflicting OPEN request (or READ/WRITE done with
      "special" stateid)

   o  SETATTR issued by another client has
   sufficient buffering resources to keep

   o  REMOVE request for the cached copy available
   until it is properly stored to file

   o  RENAME request for the file as either source or target filesystem.

8.6.  Attribute Caching

   The attributes discussed in this section do not include named
   attributes.  Individual named attributes are analogous to files and
   caching of the data for these needs
      RENAME

   Whether a RENAME of a directory in the path leading to be handled just as data
   caching is for ordinary files.  Similarly, LOOKUP the file
   results from in recall of an
   OPENATTR directory are to be cached open delegation depends on the same basis as any other
   pathnames and similarly for directory contents.

   Clients may cache file attributes obtained from semantics of
   the server and use
   them to avoid subsequent GETATTR requests.  Such caching is write
   through in file system.  If that modification to file attributes system denies such RENAMEs when
   a file is always done by
   means of requests to open, the server and should not recall must be done locally and
   cached.  The exception to this are modifications performed to attributes that
   are intimately connected with data caching.  Therefore, extending a determine whether the
   file by writing data in question is, in fact, open.

   In addition to the local data cache is reflected immediately
   in situations above, the size as seen on server may choose to recall
   open delegations at any time if resource constraints make it
   advisable to do so.  Clients should always be prepared for the
   possibility of recall.

   When a client without this change being
   immediately reflected receives a recall for an open delegation, it needs to
   update state on the server.  Normally such changes are not
   propagated directly server before returning the delegation.  These
   same updates must be done whenever a client chooses to return a
   delegation voluntarily.  The following items of state need to be
   dealt with:

   o  If the server but when file associated with the modified data delegation is
   flushed no longer open and
      no previous CLOSE operation has been sent to the server, analogous attribute changes are made on a CLOSE
      operation must be sent to the server.  When

   o  If a file has other open delegation is in effect, references at the modified attributes
   may client, then OPEN
      operations must be returned sent to the server in the response to a CB_RECALL call. server.  The result of local caching of attributes is that the attribute
   caches maintained on individual clients appropriate stateids
      will not be coherent.
   Changes made in one order on provided by the server may be seen in a different
   order on one client and in a third order on a different client.

   The typical filesystem application programming interfaces do not
   provide means to atomically modify or interrogate attributes for
   multiple files at subsequent use by the same time.  The following rules provide an
   environment where client
      since the potential incoherences mentioned above can delegation stateid will not longer be
   reasonably managed. valid.  These rules OPEN
      requests are derived from done with the practice claim type of
   previous NFS protocols.

   o  All attributes for a given file (per-fsid attributes excepted) are
      cached as a unit at CLAIM_DELEGATE_CUR.  This
      will allow the client presentation of the delegation stateid so that no non-serializability can
      arise within the context of a single file.

   o  An upper time boundary is maintained on how long a
      client cache
      entry can be kept without being refreshed from establish the server.

   o  When operations are performed that change attributes at appropriate rights to perform the
      server, OPEN.
      (see the updated attribute set is requested as part of section "Operation 18: OPEN" for details.)

   o  If there are granted file locks, the
      containing RPC.  This includes directory corresponding LOCK operations that update
      attributes indirectly.
      need to be performed.  This is accomplished by following the
      modifying operation with a GETATTR operation and then using the
      results of the GETATTR applies to update the client's cached attributes.

   Note that write open delegation
      case only.

   o  For a write open delegation, if at the full set time of attributes to be cached is requested by
   READDIR, the results can be cached by the client on recall the same basis as
   attributes obtained via GETATTR.

   A client may validate its cached version of attributes for a file by
   fetching just both is
      not open for write, all modified data for the change and time_access attributes and assuming
   that if file must be flushed
      to the change attribute has server.  If the same value as it did when delegation had not existed, the
   attributes were cached, then no attributes other than time_access client
      would have changed.  The reason why time_access is also fetched is because
   many servers operate in environments where done this data flush before the operation that updates
   change does not update time_access. CLOSE operation.

   o  For example, POSIX file
   semantics do not update access time a write open delegation when a file is modified by the
   write system call.  Therefore, the client that wants a current
   time_access value should fetch it with change during still open at the attribute
   cache validation processing and update its cached time_access.

   The client may maintain a cache time
      of recall, any modified attributes for those
   attributes intimately connected with data of modified regular files
   (size, time_modify, and change).  Other than those three attributes, for the client MUST NOT maintain a cache of modified attributes.
   Instead, attribute changes are immediately sent file needs to be flushed to
      the server.

   In some operating environments,

   o  With the equivalent to time_access write open delegation in place, it is
   expected to be implicitly updated by each read of the content of possible that the
      file object.  If an NFS client is caching was truncated during the content duration of the delegation.  For
      example, the truncation could have occurred as a file
   object, whether it is result of an OPEN
      UNCHECKED with a regular file, directory, or symbolic link,
   the client SHOULD NOT update the time_access size attribute (via SETATTR
   or value of zero.  Therefore, if a small READ or READDIR request) on
      truncation of the server with each read that
   is satisfied from cache.  The reason is that file has occurred and this can defeat operation has not
      been propagated to the
   performance benefits of caching content, especially since an explicit
   SETATTR of time_access may alter server, the change attribute on truncation must occur before
      any modified data is written to the server.
   If the change attribute changes, clients that are caching the content
   will think

   In the content has changed, and will re-read unmodified data
   from case of write open delegation, file locking imposes some
   additional requirements.  To precisely maintain the server.  Nor associated
   invariant, it is the client encouraged required to maintain a flush any modified
   version of time_access data in its cache, since this would mean that any region
   for which a write lock was released while the
   client will either eventually have to write delegation was in
   effect.  However, because the access time write open delegation implies no other
   locking by other clients, a simpler implementation is to flush all
   modified data for the
   server with bad performance effects, or it would never update file (as described just above) if any write
   lock has been released while the
   server's time_access, thereby resulting write open delegation was in effect.

   An implementation need not wait until delegation recall (or deciding
   to voluntarily return a situation where an
   application delegation) to perform any of the above
   actions, if implementation considerations (e.g. resource availability
   constraints) make that caches access time between a close and desirable.  Generally, however, the fact that
   the actual open state of the
   same file observes the access time oscillating between the past may continue to change makes it not
   worthwhile to send information about opens and
   present.  The time_access attribute always means closes to the time server,
   except as part of last
   access to a file by a read delegation return.  Only in the case of closing the
   open that was satisfied by resulted in obtaining the server.  This
   way delegation would clients will tend be
   likely to see only time_access changes that go forward do this early, since, in time.

8.7.  Data and Metadata Caching and Memory Mapped Files

   Some operating environments include that case, the capability for an application
   to map a file's content into close once done
   will not be undone.  Regardless of the application's address space.  Each
   time client's choices on scheduling
   these actions, all must be performed before the application accesses a memory location delegation is
   returned, including (when applicable) the close that corresponds to a
   block that has not been loaded into the address space, a page fault
   occurs and the file is read (or if
   the block does not exist open that resulted in the
   file, the block is allocated and then instantiated delegation.  These actions can be
   performed either in previous requests or in previous operations in
   the
   application's address space).

   As long same COMPOUND request.

9.4.5.  Clients that Fail to Honor Delegation Recalls

   A client may fail to respond to a recall for various reasons, such as each memory mapped access
   a failure of the callback path from server to the file requires client.  The client
   may be unaware of a page
   fault, failure in the relevant attributes callback path.  This lack of
   awareness could result in the file client finding out long after the
   failure that are used to detect
   access and modification (time_access, time_metadata, time_modify, its delegation has been revoked, and
   change) will be updated.  However, in many operating environments,
   when page faults are not required these attributes will not be
   updated on reads or updates to another client has
   modified the file via memory access (regardless
   whether data for which the file is local file or is being access remotely).  A client or server MAY fail to update attributes of had a file that is
   being accessed via memory mapped I/O. delegation.  This has several implications:

   o  If there is an application on
   especially a problem for the server client that held a write delegation.

   The server also has memory mapped a
      file dilemma in that a client is also accessing, the client may not be able that fails to get a consistent value of the change attribute
   respond to determine
      whether its cache is stale or not.  A server that knows that the
      file is memory mapped could always pessimistically return updated
      values for change so as to force recall might also be sending other NFS requests,
   including those that renew the application to always get lease before the
      most up to date data and metadata lease expires.
   Without returning an error for those lease renewing operations, the file.  However, due
   server leads the client to believe that the negative performance implications of this, such behavior delegation it has is
      OPTIONAL. in
   force.

   This difficulty is solved by the following rules:

   o  If  When the memory mapped file callback path is not being modified on down, the server, and
      instead is just being read by an application via server MUST NOT revoke the memory mapped
      interface,
      delegation if one of the following occurs:

      *  The client will not see has issued a RENEW operation and the server has
         returned an updated time_access
      attribute.  However, in many operating environments, neither will NFS4ERR_CB_PATH_DOWN error.  The server MUST renew
         the lease for any process running on record locks and share reservations the server.  Thus NFS clients are at no
      disadvantage with respect to local processes.

   o  If there is another
         client has that is memory mapping the file, server has known about (as opposed to those
         locks and if
      that share reservations the client is holding a write delegation, has established but not
         yet sent to the same set of issues
      as discussed in server, due to the previous two bullet items apply.  So, when a delegation).  The server does a CB_GETATTR to a file that
         SHOULD give the client has modified in a reasonable time to return its cache,
         delegations to the response from CB_GETATTR will not necessarily be
      accurate.  As discussed earlier, server before revoking the client's obligation is to
      report that the file
         delegations.

      *  The client has been modified since the delegation was
      granted, not whether it has been modified again between successive
      CB_GETATTR calls, and issued a RENEW operation for some period of
         time after the server MUST assume that any file attempted to recall the
      client has modified in cache has been modified again between
      successive CB_GETATTR calls.  Depending on delegation.  This
         period of time MUST NOT be less than the nature value of the
      client's memory management system, this weak obligation may
         lease_time attribute.

   o  When the client holds a delegation, it can not be
      possible.  A rely on operations,
      except for RENEW, that take a stateid, to renew delegation leases
      across callback path failures.  The client MAY return stale information that wants to keep
      delegations in CB_GETATTR
      whenever force across callback path failures must use RENEW
      to do so.

9.4.6.  Delegation Revocation

   At the file point a delegation is memory mapped.

   o  The mixture of memory mapping and file locking revoked, if there are associated opens
   on the same file is
      problematic.  Consider client, the following scenario, where applications holding these opens need to be
   notified.  This notification usually occurs by returning errors for
   READ/WRITE operations or when a page size
      on each client close is 8192 bytes.

      *  Client A memory maps first page (8192 bytes) of file X

      *  Client B memory maps first page (8192 bytes) of attempted for the open file.

   If no opens exist for the file X

      *  Client A write locks first 4096 bytes

      *  Client B write locks second 4096 bytes

      *  Client A, via a STORE instruction modifies part of its locked
         region.

      *  Simultaneous to client A, client B issues a STORE on part of
         its locked region.

   Here at the challenge point the delegation is for each client to resynchronize to get a
   correct view
   revoked, then notification of the first page.  In many operating environments, revocation is unnecessary.
   However, if there is modified data present at the
   virtual memory management systems on each client only know a page is
   modified, not that a subset of for the page corresponding to
   file, the
   respective lock regions has been modified.  So user of the application should be notified.  Unfortunately,
   it is may not be possible for
   each client to do notify the right thing, user since active applications
   may not be present at the client.  See the section "Revocation
   Recovery for Write Open Delegation" for additional details.

9.5.  Data Caching and Revocation

   When locks and delegations are revoked, the assumptions upon which is to only write to
   successful caching depend are no longer guaranteed.  For any locks or
   share reservations that have been revoked, the
   server corresponding owner
   needs to be notified.  This notification includes applications with a
   file open that portion has a corresponding delegation which has been revoked.
   Cached data associated with the revocation must be removed from the
   client.  In the case of modified data existing in the page client's cache,
   that is locked.  For example, if
   client A simply writes out data must be removed from the page, and then client B writes out without it being written to
   the server.  As mentioned, the assumptions made by the
   page, client A's data is lost.

   Moreover, if mandatory locking is enabled on are no
   longer valid at the file, then we point when a lock or delegation has been revoked.

   For example, another client may have been granted a
   different problem.  When clients A and B issue conflicting lock
   after the STORE
   instructions, revocation of the resulting page faults require a record lock on at the
   entire page.  Each client then tries to extend their locked first client.  Therefore, the
   data within the lock range to may have been modified by the entire page, which results in a deadlock.  Communicating other
   client.  Obviously, the
   NFS4ERR_DEADLOCK error to a STORE instruction is difficult at best.

   If a first client is locking unable to guarantee to the entire memory mapped file, there is no
   problem with advisory or mandatory record locking, at least until
   application what has occurred to the
   client unlocks a region file in the middle case of the file.

   Given the above issues the following are permitted:

   o  Clients and servers MAY deny memory mapping a file they know there
      are record locks for.

   o  Clients and servers MAY deny revocation.

   Notification to a record lock owner will in many cases consist of simply
   returning an error on a file they know is
      memory mapped.

   o  A client MAY deny memory mapping a file that it knows requires
      mandatory locking for I/O. If mandatory locking is enabled after the file is opened next and mapped, all subsequent READs/WRITEs to the client MAY deny
   open file or on the application
      further access close.  Where the methods available to its mapped file.

8.8.  Name Caching

   The results of LOOKUP and READDIR a client
   make such notification impossible because errors for certain
   operations may not be cached to avoid
   the cost of subsequent LOOKUP operations.  Just returned, more drastic action such as in the case of
   attribute caching, inconsistencies signals
   or process termination may arise among be appropriate.  The justification for
   this is that an invariant for which an application depends on may be
   violated.  Depending on how errors are typically treated for the various
   client
   caches.  To mitigate the effects operating environment, further levels of these inconsistencies notification
   including logging, console messages, and given GUI pop-ups may be
   appropriate.

9.5.1.  Revocation Recovery for Write Open Delegation

   Revocation recovery for a write open delegation poses the context special
   issue of typical filesystem APIs, an upper time boundary is
   maintained on how long a modified data in the client name cache entry can be kept without
   verifying that while the entry has file is not been made invalid by a directory
   change operation performed by another client. .LP When a
   open.  In this situation, any client is which does not making changes flush modified
   data to a directory for which there exist name cache
   entries, the client needs to periodically fetch attributes for that
   directory to server on each close must ensure that it is not being modified.  After determining
   that no modification has occurred, the expiration time for user receives
   appropriate notification of the
   associated name cache entries failure as a result of the
   revocation.  Since such situations may be updated require human action to
   correct problems, notification schemes in which the appropriate user
   or administrator is notified may be necessary.  Logging and console
   messages are typical examples.

   If there is modified data on the current time
   plus client, it must not be flushed
   normally to the name cache staleness bound.

   When a server.  A client is making changes may attempt to provide a given directory, it needs to
   determine whether there have been changes made to the directory by
   other clients.  It does this by using copy of
   the change attribute file data as
   reported before and after modified during the directory operation delegation under a different
   name in the associated
   change_info4 value returned for the operation.  The server is able to
   communicate file system name space to ease recovery.  Note that when
   the client whether the change_info4 data is provided
   atomically with respect to the directory operation.  If can determine that the change
   values are provided atomically, file has not been modified by any
   other client, or when the client is then able to compare has a complete cached copy of file
   in question, such a saved copy of the pre-operation change value with client's view of the change file may
   be of particular value in for recovery.  In other case, recovery using a
   copy of the client's
   name cache.  If file based partially on the comparison indicates that client's cached data and
   partially on the directory was
   updated server copy as modified by another client, the name cache associated with other clients, will be
   anything but straightforward, so clients may avoid saving file
   contents in these situations or mark the results specially to warn
   users of possible problems.

   Saving of such modified directory data in delegation revocation situations may
   be limited to files of a certain size or might be used only when
   sufficient disk space is purged from the client.  If the comparison
   indicates no modification, available within the name cache can target file system.
   Such saving may also be updated on restricted to situations when the client has
   sufficient buffering resources to reflect keep the directory operation and cached copy available
   until it is properly stored to the associated timeout
   extended. target file system.

9.6.  Attribute Caching

   The post-operation change value attributes discussed in this section do not include named
   attributes.  Individual named attributes are analogous to files and
   caching of the data for these needs to be saved handled just as data
   caching is for ordinary files.  Similarly, LOOKUP results from an
   OPENATTR directory are to be cached on the same basis as any other
   pathnames and similarly for future change_info4 comparisons.

   As demonstrated by directory contents.

   Clients may cache file attributes obtained from the scenario above, name server and use
   them to avoid subsequent GETATTR requests.  Such caching requires is write
   through in that the
   client revalidate name cache data modification to file attributes is always done by inspecting the change attribute
   means of a directory at the point when requests to the name cache item was server and should not be done locally and
   cached.
   This requires  The exception to this are modifications to attributes that
   are intimately connected with data caching.  Therefore, extending a
   file by writing data to the server update the change attribute for
   directories when local data cache is reflected immediately
   in the contents of size as seen on the corresponding directory is
   modified.  For a client to use without this change being
   immediately reflected on the change_info4 information
   appropriately and correctly, server.  Normally such changes are not
   propagated directly to the server must report but when the pre and post
   operation change modified data is
   flushed to the server, analogous attribute values atomically.  When changes are made on the server
   server.  When open delegation is
   unable to report in effect, the before and after values atomically with respect modified attributes
   may be returned to the directory operation, the server must indicate that fact in the
   change_info4 return value.  When the information response to a CB_RECALL call.

   The result of local caching of attributes is not atomically
   reported, the client should not assume that other the attribute
   caches maintained on individual clients have will not
   changed the directory.

8.9.  Directory Caching

   The results of READDIR operations may be used to avoid subsequent
   READDIR operations.  Just as coherent.
   Changes made in one order on the cases of attribute and name
   caching, inconsistencies server may arise among the various be seen in a different
   order on one client caches.
   To mitigate the effects of these inconsistencies, and given the
   context of in a third order on a different client.

   The typical filesystem APIs, file system application programming interfaces do not
   provide means to atomically modify or interrogate attributes for
   multiple files at the same time.  The following rules should provide an
   environment where the potential incoherences mentioned above can be
   followed:
   reasonably managed.  These rules are derived from the practice of
   previous NFS protocols.

   o  Cached READDIR information  All attributes for a directory which is not obtained
      in a single READDIR operation must always be a consistent snapshot
      of directory contents.  This is determined by using given file (per-fsid attributes excepted) are
      cached as a GETATTR
      before the first READDIR and after unit at the last of READDIR client so that
      contributes to no non-serializability can
      arise within the cache. context of a single file.

   o  An upper time boundary is maintained to indicate the length of
      time on how long a directory client cache
      entry is considered valid before the client
      must revalidate the cached information.

   The revalidation technique parallels that discussed in can be kept without being refreshed from the case of
   name caching. server.

   o  When operations are performed that change attributes at the client is not changing the directory in
   question, checking
      server, the change updated attribute set is requested as part of the
      containing RPC.  This includes directory with GETATTR operations that update
      attributes indirectly.  This is adequate.  The lifetime of accomplished by following the cache entry can be extended at
   these checkpoints.  When a client is
      modifying operation with a GETATTR operation and then using the directory,
      results of the
   client needs GETATTR to use update the change_info4 data to determine whether there
   are other clients modifying client's cached attributes.

   Note that if the directory.  If it full set of attributes to be cached is determined that
   no other requested by
   READDIR, the results can be cached by the client modifications are occurring, on the same basis as
   attributes obtained via GETATTR.

   A client may update
   its directory cache to reflect validate its own changes.

   As demonstrated previously, directory caching requires that the
   client revalidate directory cache data by inspecting the change
   attribute cached version of attributes for a directory at the point when file by
   fetching just both the directory was cached.
   This requires change and time_access attributes and assuming
   that the server update if the change attribute for
   directories when has the contents of same value as it did when the corresponding directory
   attributes were cached, then no attributes other than time_access
   have changed.  The reason why time_access is
   modified.  For a client to use the change_info4 information
   appropriately and correctly, the server must report also fetched is because
   many servers operate in environments where the pre and post operation that updates
   change attribute values atomically.  When the server does not update time_access.  For example, POSIX file
   semantics do not update access time when a file is
   unable to report the before and after values atomically with respect
   to modified by the directory operation,
   write system call.  Therefore, the server must indicate client that fact in wants a current
   time_access value should fetch it with change during the
   change_info4 return value.  When the information is not atomically
   reported, the client should not assume that other clients have not
   changed the directory.

9.  Security Negotiation

   The NFSv4.0 specification contains three oversights attribute
   cache validation processing and ambiguities
   with respect to the SECINFO operation.

   First, it is impossible update its cached time_access.

   The client may maintain a cache of modified attributes for those
   attributes intimately connected with data of modified regular files
   (size, time_modify, and change).  Other than those three attributes,
   the client MUST NOT maintain a cache of modified attributes.
   Instead, attribute changes are immediately sent to use the SECINFO operation
   to determine server.

   In some operating environments, the correct security triple for accessing a parent
   directory.  This equivalent to time_access is because SECINFO takes as arguments the current
   file handle and a component name.  However, NFSv4.0 uses the LOOKUPP
   operation
   expected to get be implicitly updated by each read of the parent directory content of the current
   file handle. object.  If
   the an NFS client uses the wrong security when issuing is caching the LOOKUPP, and gets
   back an NFS4ERR_WRONGSEC error, SECINFO