On Fri, 15 May 2015 17:11:34 -0400 "J. Bruce Fields" <bfields@xxxxxxxxxxxx>
wrote:
> On Wed, May 13, 2015 at 02:25:15PM +1000, NeilBrown wrote:
> > On Mon, 11 May 2015 21:08:47 +0800 Kinglong Mee <kinglongmee@xxxxxxxxx> wrote:
> >
> > > On 5/8/2015 9:47 PM, J. Bruce Fields wrote:
> > > > It could also be useful to have the ability to force an unmount even in
> > > > the presence of locks. That's not a safe default, but an
> > > > "allow_force_unmount" export option might be useful.
> >
> > We already have a mechanism to forcibly drop any locks by writing some magic
> > to /proc/fs/nfsd/unlock_{ip,filesystem}. I don't think we need any more.
>
> Yeah, I remember thinking this sort of approach would have advantages,
> maybe I was wrong, I need to revisit it.
>
> The unlock_{ip,filesystem} approach requires temporarily shutting down
> mountd, doesn't it?
Not necessarily.
It does require ensuring that new locks aren't suddenly taken though.
I imagine an early step in the migration process is to "ifconfig down" the
virtual interface with the floating ID. Then you can safely "unlock" and
unmount any filesystems are that only accessed via the IP.
But you are right that using the "unlock_*" interface and then unmounting is
racy in a way that we are trying to make "unmount" not racy. So maybe an
"allow_force_unmount" would have a place.
Thanks,
NeilBrown
Attachment:
pgpzG9lpphodJ.pgp
Description: OpenPGP digital signature
