[ale] Stale NFS mounts - Switch to iSCSI?

[Lightner, Jeffrey]

I'd think you'd have a worse issue and more complexity with iSCSI.

I highly recommend autofs for filesystems that aren't in use a high percentage of the time.    If the exporting server goes down you see impact only on the servers where the mount is currently active.

If you're doing planned maintenance you can run a script from a central server to go to each of your other servers, unmount the share if mounted, then disable autofs.   After maintenance run another script that goes and re-enables autofs.   (No need to remount as autofs will do that when someone tries to access the shared filesystem.

For unplanned events you can resolve the hung NFS mount effect by running the "lazy" unmount (umount -l <filesystem>) on the affected host.   That works where "force (umount -f) doesn't.

Of course there are cluster shares like gfs available but that also has some complexity.


From: Ale [mailto:ale-bounces at ale.org] On Behalf Of Raj Wurttemberg via Ale
Sent: Tuesday, March 27, 2018 9:12 AM
To: 'Atlanta Linux Enthusiasts'
Subject: [ale] Stale NFS mounts - Switch to iSCSI?

Many of our client systems share data via NFS (v3) and everything works fine except when the server with the NFS export is rebooted, which happens regularly due to OS patching (not my decision). The systems that have the NFS export mounted can no longer do even a simple 'ls', they just hang. Unmounting and remounting the NFS export or rebooting the client system does resolve the issue, but I was curious if I switched to iSCSI if I would experience the same issue? I know the easy answer is to mount the NFS directly off the SAN (EMC) but I was told that the storage team would not create NFS exports for me.  I was also looking at using autofs for the NFS mounts instead of putting them in the fstab file.

Just curious if anyone else had any advice.

Thanks,
/Raj

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20180327/f4f46541/attachment.html>