fixing "umount -f" for the NFS client

Rick Macklem rmacklem at uoguelph.ca
Thu Aug 29 12:50:56 UTC 2013


Mark Felder wrote:
> On Wed, Aug 28, 2013, at 19:15, Rick Macklem wrote:
> > I've been doing a little more testing of "umount -f" for NFS
> > mounts and they seem to be working unless some other process/thread
> > has busied the file system via vfs_busy().
> > 
> > Unfortunately, it is pretty easy to vfs_busy() the file system
> > by using a command like "df" that is stuck on the unresponsive
> > NFS server.
> > 
> 
> always mount your nfs with options "soft,intr" or you'll run into
> this
> :)
I'm not sure if your smiley is because you already know what I think
of "soft, intr", but...

Application software generally doesn't expect I/O syscalls (read, write...)
to fail with ETIMEDOUT or EINTR. As such, I would never use "soft", except
maybe for some read-only volume where intermittent failures aren't an issue.
As for "intr", I believe that processes can get stuck in uninterruptible
situations when they are waiting for a buffer/page that is in use by
another thread (that no "intr" signal has been issued for). However,
this just means the process won't "interrupt", so so long as there isn't
an unexpected interruption caused by a signal, it could be ok.

Finally, neither of these options are safe to use for NFSv4, because
operations that manipulate state (like locks) cannot be safely interrupted,
since they will leave the lock in an undefined state, at least for the
FreeBSD server.
So, at least for NFSv4, a forced dismount is a necessary alternative.

Personally, when I was a sysadmin, I tried to make sure my NFS server and
network ran reliably and always used hard mounts (no "intr, soft") to avoid
the issue.

rick

> _______________________________________________
> freebsd-fs at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"
> 


More information about the freebsd-fs mailing list