X-Git-Url: http://git.tuebingen.mpg.de/?a=blobdiff_plain;f=Filesystems.m4;h=ca894346e55d865ee7171c1052c22a01a005acf4;hb=63ef3ef23517d1f63b4a17da8cecb88b8fa1ebdf;hp=9035de5218f1ab8da1e4c6e399438f2b523002a8;hpb=d9515637ca709f2ad9fbb4e1e90690981b8db1ad;p=aple.git diff --git a/Filesystems.m4 b/Filesystems.m4 index 9035de5..ca89434 100644 --- a/Filesystems.m4 +++ b/Filesystems.m4 @@ -955,6 +955,11 @@ file fragmentation, but they can cause confusion because they are accounted identically to other blocks, making files appear to use more data blocks than expected.
+If the system crashes while preallocated post-EOF blocks exist, +the space will be recovered the next time the affected file gets closed +(after it has been opened of course) by the normal reclaim mechanism +which happens when a file is being closed.
+ SUBSECTION(«Reverse Mapping»)This feature was implemented in 2018. It adds yet another B-tree to @@ -1199,7 +1204,7 @@ re-used subsequently. File handles are based on leases: The client periodically talks to the server to update its leases.
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 @@ -1340,11 +1345,16 @@ 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 @@ -1391,11 +1401,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