On Wed, 5 Jun 2013 09:36:58 -0400 "J. Bruce Fields" <bfields@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx> 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:
signature.asc
Description: PGP signature
