From 63ef3ef23517d1f63b4a17da8cecb88b8fa1ebdf Mon Sep 17 00:00:00 2001
From: Andre Noll
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 @@ -1396,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
--
2.39.5