[ On Thursday, March 13, 2003 at 14:41:56 (-0800), Bill Studenmund wrote: ]
> Subject: Re: /sbin/umount should support umount_* (PR#698)
>
> It would depend on what needs to be done. I tend to think that we don't
> need unmount_foo, but I don't know what every file system will need.

Well, yes, exactly -- that's why I'm suggesting that /sbin/umount just
(silently (*)) call umount(2) when an exec of /sbin/umount_FSTYPE fails.

(*) I think it would be nice to report and log the exec failure, though
that does imply having a basic /sbin/umount_generic program which just
calls umount(2) and which can be hard linked to /sbin/umount_ffs and so
on to deal with all the non-special filesystems.  This too is a bit of a
pain, but perhaps a small price to pay for the operational peace of mind
of knowing when some special program fails or goes missing.


> The reason for having the kernel do something is it is the entity that
> knows best what userland object, if any, is the special one, since that
> process had to register itself w/ the file system in the first place. :-)

Either way I still think if you want to make things flexible enough for
the kernel to always trigger the user-land interaction for any abitrary
filesystem implementation then about the only good choice you have(*) is
to use a lone sentinel process which the kernel can signal from inside
umount(2) and which can then implement that arbitrary action in its
signal handler.

The alternative requires the filesystem code to keep private data which
tells it how to relate to the user-land objects related to a given mount
of a given special filesystem.  This makes me nervous because there's no
generic interface back to the likes of statfs(2) and getfsstat(2) so
that an administrator can see those relationships.  SysVr4's statvfs(2)
has f_fstr which, IIRC, could return at least some arbitrary information
which might be used to show such relationships, but *BSD statfs()
doesn't (yet) have anything like that, though of course we do use the
device name for a similar purpose in some cases such as with MFS (**).

In any case I definitely want to always be able to find out what
user-land object(s) are associated with any given mount point, if any,
and at least with a common lone sentinel process I know that all such
information is going to be plainly visible in userland some how or some
way, not hidden in a private kernel structure in FS-specific code.

(*) I suppose a socketpair() or pipe() with one end-point in the kernel
would work too, but that seems like a lot more hackery for zero real
gain, not to mention that the de facto standard way for Unix kernels to
notify Unix user-land of exceptions has always been, and still is, the
plain old simple signal.

(**) I think a proper f_pid field should be added to struct statfs if
this sentinel process idea is to become the standard for such hooks....


> We KNOW that all file systems will have a call to the fs-specific unmount
> routine, so we should use it. While most all umount(2) calls may come
> from umount(1), if we limit it to that, we limit what other tools can do.
> We've GOT to use the system call, so we might as well use it. :-)

Yes, that's a very good point, but given your next point:

> Also, don't forget we're talking about a file system that NEEDS some
> special userland helper. Most don't.

That's why I'm suggesting that umount(1) invoke the magic hooks for
those few special filesystems which need user-land magic at unmount.

The general principle I think I'm advocating here is to initiate such
user-land actions from user-land, and I think its especially relevant
given the rarity of the need in this case.

I'm not suggesting that umount(2) never be called for those sepcial
cases -- rather the opposite as of course somehow the kernel also has to
be told about the unmount operation and umount(2) is the obvious entry
point.  Additionally the kernel should still always unmount the
filesystem (i.e. make it unavailable) when umount(2) is called for such
a special filesystem, regardless of what might or might not happen or
have happened to any associated user-land object(s).

If the user-land action doesn't happen then there may be some cruft left
over, but this shouldn't be critical to the kernel (assuming it's done
the unmount carefully and completely) and the system will still continue
operating correctly, though maybe that special filesystem won't be
re-usable until after the cruft from its last use is cleaned up
manually.

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>