Re: race-free exportfs and unmount?

[NeilBrown <neilb@suse.de>]

[-- Attachment #1: Type: text/plain, Size: 1842 bytes --]

On Fri, 21 Mar 2014 16:58:07 -0600 Chris Friesen
<chris.friesen@windriver.com> wrote:

> On 03/21/2014 02:20 PM, J. Bruce Fields wrote:
> > On Fri, Mar 21, 2014 at 02:17:13PM -0600, Chris Friesen wrote:
> >>
> >> Hi,
> >>
> >> There was a linux-nfs thread in July 2012 with the subject "Linux
> >> NFS and cached properties".  It discussed the fact that you can't
> >> reliably do
> >>
> >> exportfs -u 192.168.1.11:/mnt
> >> umount /mnt
> >>
> >> since there could be rpc users still running when exportfs returns,
> >> so the umount fails thinking the filesystem is busy.
> >
> > There could also be clients holding opens, locks, or delegations on the
> > export.
> >
> >> I'm running into this on a production system.
> >>
> >> Was anything ever done to resolve this issue?
> >> If not are there any workarounds?
> >
> > You can shut down the server completely, unmount, and restart.
> 
> 
> What is different with shutting down the server completely vs unexporting?
> 
> Does shutting down the server somehow wait for in-flight operations to 
> complete whereas the unexport doesn't?  I'm assuming that it can't just 
> cancel in-progress disk I/O and as long as that's happening then we 
> won't be able to unmount the filesystem.

Shutting down the server waits for all nfsd threads to complete what they are
currently doing.
I think you can simply:

 exportfs -u the filesystem
 N=`cat /proc/fs/nfsd/thread`
 echo 0 > /proc/fs/nfsd/threads
 echo $N > /proc/fs/nfsd/threads
 umount the filesystem

to reliably unmount a filesystem used by nfsd.
NFS service will be stopped for a moment but clients shouldn't notice beyond
slight delay and the need to re-establish a connection.

If this doesn't work for some reason, we should probably fix it.

NeilBrown

> 
> Thanks,
> Chris


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]