resize2fs(8) without specifying the new size.
+SUBSECTION(«Fast Commits»)
+
++ +Optimization introduced in 2020 (Linux-5.10). + +activated at mkfs time + +light-weight journaling method + +Idea: parts of the metadata written to the log can instead be derived +from the inode. Leads to more compact format. + +Implementation: additional journal for fast commits, i.e., for those +operations that can be optimized. Contains changes at the *file* level + +
/proc/fs/ext4/dev/fc_info to see whether fast
+commits are supported in the runing kernel. nfs4 introduced a per-file state management feature called +file delegation. 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.
+ + 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 RENEW
+request. If no such request has arrived for the lease time
+(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.
However, the server is not obliged to recall uncontested +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 +courteous server feature was introduced in Linux-5.19 +(released in 2022).
+ +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 strong directory cache coherency. However, as of 2022, +directory delegations are not yet implemented by Linux.
SUBSECTION(«Silly Renames and Stale File Handles») @@ -1345,14 +1394,19 @@ is still open. Only after all the last file descriptor that refers to the thusly silly-renamed file is closed, the client removes the file by issuing an appropriate rpc. - This approach is not perfect. For one, if the client crashes,
-a stale .nfs12345 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.
This approach is not perfect. For one, if the client crashes, a
+stale .nfs12345 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
+rmdir will fail unexpectedly with Directory not
+empty. 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.
The file handle which an nfs client received through some earlier -rpc can become invalid at any time due to operations on a different +rpc can become invalid at any time due to operations on different hosts. This happens, for example, if the file was deleted on the server or on a different nfs client, or when the directory that contains the file is no longer exported by the server due to a configuration @@ -1396,11 +1450,11 @@ EXERCISES()
collectl -s F -i 5 and discuss
the output. cat > foo &. Note
- that the cat process automatically receives the STOP signal.
- Run rm foo; ls -ltra. Read section D2 of the
- nfs HOWTO for the
- explanation. cat > foo &. Note that the cat process automatically
+ receives the STOP signal. Run rm foo; ls -ltra. Read
+ section D2 of the nfs HOWTO
+ for the explanation. { while :; do echo; sleep
1; done; } > baz &. What happens if you remove the file on a
@@ -1408,7 +1462,7 @@ EXERCISES()