This content has been marked as final. Show 6 replies
Thanks for replying.
Yes. I'm talking about NFS.
I have 3 servers. one is Oracle-Linux 6.3. other servers are Oracle-Linux 5.8.
OL63 is NFS server. OL5.8 is clients. All server is 64bit.
Sometimes I can not shutdown one of OL58 servers. because application which is using nfs is not responding.(By using hard-mount)
I can use soft-mount from NFS clients. but, I've been thinking about another way to control which is hard-mount or soft-mount from NFS server.
I've looked into it on the internet. but I couldn't find anything about it.
Do you think I can do?
Thanks a lot help.
Edited by: 964888 on 2012/11/07 23:09
Edited by: 964888 on 2012/11/07 23:18
Edited by: 964888 on 2012/11/08 0:25
I'm not aware of a NFS server option to force the client to use hard or soft mount. So my answer to this was no.
An NFS file system that is mounted with the soft option returns an error if the server does not respond. The hard option causes the mount to continue to retry until the server responds. The recommended option is to hard mount. Personally I have always used tcp only and soft mounting. I guess it depends on what you use the NFS share for.
If hard is specified, the user cannot terminate the process waiting for the NFS communication to resume unless the intr option is also specified. However, even when using the intr mount option, you will not always succeed in killing a task that is hanging on NFS.
The subject is covered in more details in the Oracle Linux 5 Deployment Guide at https://linux.oracle.com/documentation/OL5/Red_Hat_Enterprise_Linux-5-Deployment_Guide-en-US.pdf Chapter 20.4. Common NFS Mount Options.
See also http://nfs.sourceforge.net Chapter D6.
Unless you KNOW your apps are all properly coded to handle IO errors robustly, don't use soft NFS mounts. Or you'll wind up with data corruption.
And even if you know your apps ARE coded properly, you'll still have problems with mmap'd data. Like that used by running binaries from an NFS-mounted file system.
Forcing TCP does help a LOT, as random UDP packet drops won't cause NFS errors. And if you control the servers and the network, maybe that's OK. As long as you're willing to deal with other issues - data corruption, apps crashing w/ SIGSEGV or SIGBUS, etc. when you do lose NFS mounts.
Well, the way I see it, if write operations fail due to network issues or a system crash, data consistency on the NFS share is in jeopardy regardless of hard or soft mount. Older NFS implementation did not support the INTR option. Having to deal with a remote server that requires to push the hard reset button because of a stupid NFS hang is not always acceptable. In particular if you do not control the network or have to deal with security issues like spoofing. In the end you still get a corrupted file on an NFS volume, so where's the advantage of hard mount?
Like I said it depends on what you use it for. I would prefer hard mount when using a NFS share like a local disk, e.g. to run applications, etc. Issues like paging, etc. come into play - the way how the system reacts to NFS errors in such cases is system dependent. But for the purpose of sharing files for backup, etc. I prefer TCP and soft mount and simply clean up and retry should an error occur.