On Thu, 13 Mar 2003, Greg A. Woods wrote:

> [ 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.

It doesn't have to be a signal handler, but I think the general idea is
right.

> 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 (**).

Hmm.. Being able to dump what's depending on what would be useful. So
that's a vote for whatever happens being a generic filesystem behavior.

I don't think we can depend on how MFS shoves the PID in the device name.

> 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.

Yes, but those exceptions almost always have to do with the process
itself or apply to all processes (like SIGMEM for systems that have it).
Here we're talking about a very specific IPC, so a signal mightn't be the
best thing. We have a lot more options than we did when signals were
developed, so we might as well use them.

Additionally, the shutdown notification (as a generic signal) is only part
of why I think the kernel should be involved. What happens if the helper/
sentiel dies? If the fs has a pipe pair open with the kernel, it can
readily notice the death, and note that its idea of who the sentinel is is
stale. There are other ways to do this too. The essential point is that
the file system strikes me as the best place to pay attention to the
helper's live cycle, and should be used as the repository of that info.

> (**) 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....

That would probably be good.

> > 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.

What file systems will need userland unmount magic that won't also need
userland help while running? What are these umount helper functions going
to be doing other than killing the mount-helper process?

Also, by forcing umount(1), you implicitly curtail other tools from
directly calling umount(2), since different things will happen if
umount(1) called umount(2) or something else did.

> 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.

We're really discussing different ways for the userland decision to
unmount a file system to get propogated to the helper/sentinel. You're
suggesting fork()/exec()/kill(), and I'm suggesting umount()/kill() or
umount()/ipc.

The one place I see that umount_foo would be a big win would be a special
file system that needs cleanup on umount but nothing special while the
file system is running.

Also, remember how this all started. It started because of a special file
system that currently has a helper ap, that needs to know when its mount
dies.

Take care,

Bill