Using NFS protocol, the NFS client can mount the filesystem existing on a NFS server, just like a local filesystem.
NFS mount can be done in either as a
soft mount or
hard mount. These mount options define how the NFS client should handle NFS server crash or failure.
In this tutorial, we will see the difference between soft and hard mounts in NFS.
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 where importance is for data integrity.
$ sudo mount -o rw,soft host.nf_server.com/share_name /mnt/nfs_data
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 setting is to use hard with intr options.
$ sudo mount -o rw,hard,intr host.nf_server.com/share_name /mnt/nfs_data
On a newer version of Linux,
intr option is disabled as it's hardcoded into the kernel (after kernel 2.6.25). Hence you have to use kill -9 to stop the NFS process.
For the critical application that can't afford any data corruption, the recommended option is to use a hard mount.
In this tutorial, we discussed the difference between the soft and hard mount options on NFS mount.