A hard mount is generally used for block resources like a local disk or SAN. A soft mount is usually used for network file protocols like NFS or CIFS.
The advantage of a soft mount is that if your NFS server is unavailable, the kernel will time out the I/O operation after a pre-configured period of time. The disadvantage is that if your NFS driver caches data and the soft mount times out, your application may not know which writes to the NFS volumes were actually committed to disk.
hard mounts and "intr" (interruptible) is a good compromise (for kernels before 2.6.25, see comment by Ryan Horrisberger) . The application is not fooled about successful writes, yet you can kill them if something clogs up the tubes.
A hard mount using some kind of network file system (nfs or fuse) can (sometimes) block forever while trying to re-establish a broken connection. This means, every process trying to access that mount goes into disk sleep (D) until the device is available again or the system is rebooted.
Disk sleep can not be interrupted or killed. Its like the zombie of zombie processes.
In short, do not use hard mounts for network file systems, ever. You want the file system to fail (immediately, to processes using syscalls) if I/O is not possible. Otherwise, the memory that they claim may as well be leaked if the FS fails.
A soft or hard mount depends on the usage of the filesystem and impacts the write operation guarantees from the underlying software stack. From the nfs man page (the mount options also apply to nfsv4), "A so-called "soft" timeout can cause silent data corruption in certain cases. As such, use the soft option only when client responsiveness is more important than data integrity."
For mission critical read-write application use, always use hard mounts to prevent file corruption (this is the reason why it is default for most systems).
For read-only filesystems it is safe to use soft because there is no danger of losing data an application thought has been written to the filesystem and therefore preferred because it won't block the application; only return no-data or an error - both of which can and should be detected by an application.
A hard mount is generally used for block resources like a local disk or SAN. A soft mount is usually used for network file protocols like NFS or CIFS.
The advantage of a soft mount is that if your NFS server is unavailable, the kernel will time out the I/O operation after a pre-configured period of time. The disadvantage is that if your NFS driver caches data and the soft mount times out, your application may not know which writes to the NFS volumes were actually committed to disk.
hard mounts and "intr" (interruptible) is a good compromise (for kernels before 2.6.25, see comment by Ryan Horrisberger) . The application is not fooled about successful writes, yet you can kill them if something clogs up the tubes.
A hard mount using some kind of network file system (nfs or fuse) can (sometimes) block forever while trying to re-establish a broken connection. This means, every process trying to access that mount goes into disk sleep (D) until the device is available again or the system is rebooted.
Disk sleep can not be interrupted or killed. Its like the zombie of zombie processes.
In short, do not use hard mounts for network file systems, ever. You want the file system to fail (immediately, to processes using syscalls) if I/O is not possible. Otherwise, the memory that they claim may as well be leaked if the FS fails.
A
soft
orhard
mount depends on the usage of the filesystem and impacts the write operation guarantees from the underlying software stack. From the nfs man page (the mount options also apply to nfsv4), "A so-called "soft" timeout can cause silent data corruption in certain cases. As such, use thesoft
option only when client responsiveness is more important than data integrity."For mission critical read-write application use, always use
hard
mounts to prevent file corruption (this is the reason why it is default for most systems).For read-only filesystems it is safe to use
soft
because there is no danger of losing data an application thought has been written to the filesystem and therefore preferred because it won't block the application; only return no-data or an error - both of which can and should be detected by an application.