Re: [patch/rfc] allow exported (and *not* exported) filesystems to be unmounted.

[NeilBrown <neilb@suse.de>]

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

On Wed, 5 Jun 2013 09:36:58 -0400 "J. Bruce Fields" <bfields@fieldses.org>
wrote:

> On Wed, Jun 05, 2013 at 04:19:34PM +1000, NeilBrown wrote:
> > On Wed, 5 Jun 2013 04:41:15 +0100 Al Viro <viro@ZenIV.linux.org.uk> wrote:
> > 
> > > On Wed, Jun 05, 2013 at 01:05:41PM +1000, NeilBrown wrote:
> > > > 
> > > > Hi Bruce,
> > > >  this is a little issue that seems to keep coming up so I thought it might be
> > > >  time to fix it.
> > > > 
> > > >  As you know, a filesystem that is exported cannot be unmounted as the export
> > > >  cache holds a reference to it.  Though if it hasn't been accessed for a
> > > >  while then it can.
> > > > 
> > > >  As I hadn't realised before sometimes *non* exported filesystems can be
> > > >  pinned to.  A negative entry in the cache can pin a filesystem just as
> > > >  easily as a positive entry.
> > > >  An amusing, if somewhat contrived, example is that if you export '/' with
> > > >  crossmnt and:
> > > > 
> > > >     mount localhost:/ /mnt
> > > >     ls -l /
> > > >     umount /mnt
> > > > 
> > > >  the umount might fail.  This is because the "ls -l" tried to export every
> > > >  filesystem found mounted in '/'.  The export of "/mnt" failed of course
> > > >  because you cannot re-export an NFS filesystem.  But it is still in the
> > > >  cache.
> > > >  An 'exportfs -f' fixes this, but shouldn't be necessary.
> 
> Yeah, ugh.  As a less contrived example, can the default v4 root export
> lead to arbitrary filesystems being pinned just because a client tried
> to mount the wrong path?

I think it can only pin filesystems that are exported, either explicitly or
via a parent being exported with 'crossmnt'.

> 
> Could the export cache be indexed on a path string instead of a struct
> path?

Yes.  It would mean lots of extra pathname lookups and possibly lots of
"d_path()" calls.

> 
> The problem of negative entries aside, anyone counting on the ability to
> unexport mounted filesystems on a running nfs server is setting
 ^unmount exported^?
> themselves up for trouble: suppose we fix this problem, what if an rpc
> is in progress, or a lock or v4 open or delegation is held?

All of these should prevent the unmount - and I think people would expect
that - you cannot unmount a filesystem that is still being used, and all of
these are examples of current use.  At the very least, the  filesystem must
be mounted on some client.

In the (few) times this has been raised over the years, the position has been
"I'm not using it any more, why cannot I unmount it?  fuser/lsof doesn't
show any users!".

An alternate approach to the problem might be to get rpc.mountd to hold an
open file descriptor for every exported filesystem.  That would guide people
(via lsof/fuser) to stopping nfsd, which would make the filesystem
unmountable.
However I don't find that approach particularly elegant...

NeilBrown


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