Forcibly Unmounting NFS Filesystems

forcibly unmounting nfs filesystems
available solutions
10
Depending upon the design of the application, most processes, upon receiving
an ESTALE error, will give up attempting to contact the NFS server and will either
exit on their own or will transition to a state where they can be successfully killed.
In this example, the dd(1) application returned an error and exited.
10. Even though the dd(1) command has exited, the filesystem cannot be
immediately unmounted. Remember that the client’s buffer cache was holding
memory pages associated with the target NFS filesystem. These pages must be
invalidated from the client’s cache before the filesystem is considered “not busy.”
This is a good example of the principle described on page 5 – if an initial
umount(1M) attempt fails, wait for a period of time and try again. In this
example, the final working umount(1M) command occurred approximately 2
minutes after the dd(1) command exited. Of course, the actual time it takes for
your applications to relinquish their NFS resources will vary.
11. Eventually all buffer cache memory pages associated with the NFS filesystem are
invalidated and the filesystem can be successfully unmounted.
12. Once all NFS clients have successfully unmounted any filesystems associated with
the “down” server, the ifconfig(1M) command should be used to un-plumb the
original server’s IP address. This step is important to remember in order to avoid
an IP address conflict once the original NFS server returns to normal operation.
This procedure is by no means foolproof, nor is it guaranteed to work in every situation.
However, by configuring an available system to masquerade as the down NFS server,
there is a good chance that most NFS client processes will eventually give up waiting for
the original server and relinquish their resources, allowing hung NFS filesystems to be
successfully unmounted until the original server can be made available again.