The client periodically talks to the server to update its leases. </p>
<p> There is a deep interaction between file handles and the dentry
-cache of the vfs. Without nfs, a filesystems can rely on the following
+cache of the vfs. Without nfs, a filesystem can rely on the following
"closure" property: For any positive dentry, all its parent directories
are also positive dentries. This is no longer true if a filesystem
is exported. Therefore the filesystem maps any file handles sent to
guaranteed to see the write operation of the blue client while there
is no such guarantee for the red client. </p>
-SUBSECTION(«Delegations»)
-
-nfs4 introduced a feature called <em>file delegation</em>. A file
-delegation allows the client to treat a file temporarily as if no
-other client is accessing it. Once a file has been delegated to a
-client, the client might cache all write operations for this file,
-and only contact the server when memory pressure forces the client
-to free memory by writing back file contents. The server notifies
-the client if another client attempts to access that file.
+SUBSECTION(«File and Directory Delegations»)
+
+<p> nfs4 introduced a per-file state management feature called
+<em>file delegation</em>. Once a file has been delegated to a client,
+the server blocks write access to the file for other nfs clients and
+for local processes. Therefore the client may assume that the file
+does not change unexpectedly. This cache-coherency guarantee can
+improve performance because the client may cache all write operations
+for this file, and only contact the server when memory pressure forces
+the client to free memory by writing back file contents. </p>
+
+<p> A drawback of file delegations is that they delay conflicting open
+requests by other clients because existing delegations must be recalled
+before the open request completes. This is particularly important if
+an nfs client which is holding a delegation gets disconnected from
+the network. To detect this condition, clients report to the server
+that they are still alive by periodically sending a <code>RENEW</code>
+request. If no such request has arrived for the <em>lease time</em>
+(typically 90 seconds), the server may recall any delegations it
+has granted to the disconnected client. This allows accesses from
+other clients that would normally be prevented because of the
+delegation. </p>
+
+<p> However, the server is not obliged to recall <em>uncontested</em>
+delegations for clients whose lease period has expired. In fact,
+newer Linux NFS server implementations retain the uncontested
+state of unresponsive clients for up to 24 hours. This so-called
+<em>courteous server</em> feature was introduced in Linux-5.19
+(released in 2022). </p>
+
+<p> Let us finally remark that the delegations as discussed above
+work only for regular files. NFS versions up to and including 4.0
+do not grant delegations for directories. With nfs4.1 an nfs client
+may ask the server to be notified whenever changes are made to the
+directory by another client. Among other benefits, this feature allows
+for <em>strong directory cache coherency</em>. However, as of 2022,
+directory delegations are not yet implemented by Linux. </p>
SUBSECTION(«Silly Renames and Stale File Handles»)
to the thusly silly-renamed file is closed, the client removes the
file by issuing an appropriate rpc. </p>
-<p> This approach is not perfect. For one, if the client crashes,
-a stale <code>.nfs12345</code> file remains on the server. Second,
-since silly renames are only known to the nfs client, bad things
-happen if a different client removes the file. </p>
-
+<p> This approach is not perfect. For one, if the client crashes, a
+stale <code>.nfs12345</code> file remains on the server. Second, since
+silly renames are only known to the nfs client, bad things happen if a
+different client removes the file. Finally, if an application running
+on a client removes the last regular file in a directory, and this
+file got silly-renamed because it was still held open, a subsequent
+<code>rmdir</code> will fail unexpectedly with <code>Directory not
+empty</code>. Version 4.1 of the NFS protocol finally got rid of
+silly renames: An NFS4.1 server knows when it its safe to unlink a
+file and communicates this information to the client. </p>
<p> The file handle which an nfs client received through some earlier
rpc can become invalid at any time due to operations on a different
<li> On an nfs server, run <code>collectl -s F -i 5</code> and discuss
the output. </li>
- <li> In an nfs-mounted directory, run <code>cat > foo &</code>. Note
- that the cat process automatically receives the STOP signal.
- Run <code>rm foo; ls -ltra</code>. Read section D2 of the
- <a href="http://nfs.sourceforge.net/">nfs HOWTO</a> for the
- explanation. </li>
+ <li> In an nfs-mounted directory (nfs version 4.0 or earlier), run
+ <code>cat > foo &</code>. Note that the cat process automatically
+ receives the STOP signal. Run <code>rm foo; ls -ltra</code>. Read
+ section D2 of the <a href="http://nfs.sourceforge.net/">nfs HOWTO</a>
+ for the explanation. </li>
<li> In an nfs-mounted directory, run <code>{ while :; do echo; sleep
1; done; } > baz &</code>. What happens if you remove the file on a
projects / aple.git / blobdiff