Morning guys...
Trying to get input regarding nfs (erver/client) and stale file handles..
Research indicates the stale file issue can arise when the nfs file changes and the client attempts to interact with an older/out of date file handle..
The usual solutions have information on doing a remount process on either the client or serverside of the nfs..
Is this what you guys have seen?
In my use case as I have a bunch of clients interacting/modifying with the nfs files might be difficult to refresh on the serverside due to conflicts from the clients using the nfs files..
On the clientside easy enough to automate a process/logic to every so often do a umount/remount process on the individual client.
Any thoughts/comments??
On Tue, 29 Nov 2016 10:05:15 -0500 bruce wrote:
On the clientside easy enough to automate a process/logic to every so often do a umount/remount process on the individual client.
That will work, but it is pretty heavy handed, and "umount -l" is almost always necessary because something, somewhere, on the system is always referencing the remote file and it will refuse a normal "umount" (and umount -f has to time out for hours before it forces the unmount).
I get this crap all them time when a symlink changes on the server, and the client doesn't see the change (which isn't supposed to be a problem, but is). Usually removing the symlink, doing an "ls -lL' on the client to convince it that it is gone, then recreating it on the server works.
I've never been able to understand how it is that NFS is so widely used, yet so broken.
On Tue, Nov 29, 2016 at 11:37 AM, Tom Horsley horsley1953@gmail.com wrote:
On Tue, 29 Nov 2016 10:05:15 -0500 bruce wrote:
On the clientside easy enough to automate a process/logic to every so often do a umount/remount process on the individual client.
Automounter.
That will work, but it is pretty heavy handed, and "umount -l" is almost always necessary because something, somewhere, on the system is always referencing the remote file and it will refuse a normal "umount" (and umount -f has to time out for hours before it forces the unmount).
It may be worthwhile tracking down the reasons remote files are being held open. Sometimes it is just sloppy habits of users who leave buffers active in emacs and sometimes there are config files that can be moved to the client.
I get this crap all them time when a symlink changes on the server, and the client doesn't see the change (which isn't supposed to be a problem, but is). Usually removing the symlink, doing an "ls -lL' on the client to convince it that it is gone, then recreating it on the server works.
I've never been able to understand how it is that NFS is so widely used, yet so broken.
Your breakage is another person's feature.
When NFS over UPD appeared on the CDC mainframe at work, I started a job on a 7/24 client to write a timestamp to the server every 30 mins. Clients were vaxen and a few unix workstations.
Over a couple years, I never lost a timestamp that was generated on the client. This was thru crashes on the server, etc.
Whenever the server or network went down, all the clients would hang as soon as something tried to touch the server, and clients trying write "too much" data would run out of buffer space.
A few years later, VMS was being replaced by UNIX and NeXT and automounters were a big help reducing the number of times times clients would hang on a not-responding NFS server.
Today, in a typical research lab environment lab with Windows and linux and macOS workstations, the linux and macOS users like it that they just need to be logged on their workstation to get automounted NFS shares, while SMB/CIFS require that they provide credentials at mount time.
On 11/29/2016 07:37 AM, Tom Horsley wrote:
On Tue, 29 Nov 2016 10:05:15 -0500 bruce wrote:
On the clientside easy enough to automate a process/logic to every so often do a umount/remount process on the individual client.
That will work, but it is pretty heavy handed, and "umount -l" is almost always necessary because something, somewhere, on the system is always referencing the remote file and it will refuse a normal "umount" (and umount -f has to time out for hours before it forces the unmount).
I get this crap all them time when a symlink changes on the server, and the client doesn't see the change (which isn't supposed to be a problem, but is). Usually removing the symlink, doing an "ls -lL' on the client to convince it that it is gone, then recreating it on the server works.
I've never been able to understand how it is that NFS is so widely used, yet so broken.
You have to stop expecting a NAS (network attached storage) volume to behave like a local device. It is a completely independent device and not under control of your client's kernel. Many of the internal notification mechanisms you rely on simply aren't there because there is no way to implement them reliably (inotify, open file counts and such). Some of these things you don't even know you're using on a native volume. Look at the issues involved in sharing a file with read/write access among separate processes on the same machine. Now multiply that by a hundred, add in network latency issues and you'll see it's "a fine kettle of fish".
A big cause of stale handles and such is due to the various client caches. Yes, the caches speed things up and can reduce network usage, but with these benefits come trade-offs. Because it's a cache and items can change on the server--either directly on the server or by other clients' activities--the client may find that the NAS has "changed" since the last time it updated its cache.
That's the nature of NAS--be it NFS, CIFS, WebDAV, whatever. If you really can't tolerate these things, you can usually disable much of the client-side cache when the filesystem is mounted. You'll take a performance hit and you'll flog the network much harder, but the stale filehandle issue will be reduced. You won't eliminate it, but it'll be better. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - ----------------------------------------------------------------------
-
bruce -
George N. White III -
Rick Stevens -
Tom Horsley