On Fri, 21 Mar 2014 16:58:07 -0600 Chris Friesen <chris.friesen@xxxxxxxxxxxxx> 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:
signature.asc
Description: PGP signature
