Using NFS protocol, the NFS client can mount the filesystem existing on a NFS server, just like a local filesystem. For example, you will be able to mount “/home” directory of host.nfs_server.com to your client machine as follows:
# mount host.nfs_server.com:/home /techhome
The directory “/techhome” should be created in your machine to hold the NFS partition. This NFS mount can be done in either as a “soft mount” or as a “hard mount”. These mount options define how the NFS client should handle NFS server crash/failure. In this article, we will see the difference between soft and hard mounts.
1) Soft Mount
Suppose you have mounted a NFS filesystem using “soft mount”. When a program or application requests a file from the NFS filesystem, NFS client daemons will try to retrieve the data from the NFS server. But, if it doesn’t get any response from the NFS server (due to any crash or failure of NFS server), the NFS client will report an error to the process on the client machine requesting the file access. The advantage of this mechanism is “fast responsiveness” as it doesn’t wait for the NFS server to respond. But the main disadvantage of this method is data corruption or loss of data. So this is not a recommended option to use.
mount -o rw,soft host.nf_server.com/home /techhome
2) Hard Mount
If you have mounted the NFS filesystem using hard mount, it will repeatedly retry to contact the server. Once the server is back online, the program will continue to execute undisturbed from the state where it was during server crash. We can use the mount option “intr” which allows NFS requests to be interrupted if the server goes down or cannot be reached. Hence the recommended settings are hard and intr options.
mount -o rw,hard,intr host.nf_server.com/home /techhome