Re: nfs client performance while server is down

[Ray Van Dolson <rvandolson@esri.com>]

On Wed, Jan 27, 2010 at 11:25:39AM -0800, Whoop Whouzer wrote:
> I am not stating this is an NFS problem at all. I am not asking
> anybody to fix anything.  I asked if this issue was by design. I was
> told it wasn't (as nfs is stateless).  So, therefore I considered it
> as a bug (which I don't believe to reside in either nfs or nautilus).
> I am just trying to figure out where the problem lies.
> 
> I am not talking about implementing "disconnected NFS" mode,
> synchronisation or anything like that. There is not something
> missing, there is something not working properly, somewhere, and I'm
> trying to find out where..

My impression is that this is "by design" in that NFS mounts, when
mounted in "hard" mode (which is the case by default) will "block"
until the remote server responds.

For the most part this is a good thing.  Applications expect their
filesystem calls to behave a certain way regardless of what type of
filesystem is underneath.

In this case, it seems like Nautilus tries to open the mount point and
it just hangs... forever.  This would be expected with an NFS mount in
my view.

One way I could think of getting around it would be to ensure that the
NFS mount is mounted with "intr", and then get Nautilus to monitor how
long it takes to read a mount point and "terminate" after a timeout is
reached, perhaps flagging that mount so future accesses are quicker.

Anyways, that goes beyond the scope of NFS... and good luck convincing
the GNOME developers to make a change like that. :)

Also, even if you mount an NFS share with "intr", you can't always
guarantee that you'll be able to kill a process trying to access said
mount..... at least in my experience.

Ray