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

[du -g comments deleted. I like the idea of tools being able to dump more
information. But that's orthogonal to the point I want to make :-) ]

> A basic re-implementation of umount(1) that handles special user-land
> interactions with filesystems could simply do what 'df' does to get all
> these struct statfs values (getmntinfo() for "umount -a" or statfs() for
> a single FS) and then it could append the f_fstypename field's value to
> "/sbin/umount_" and exec the resulting pathname (forking first for
> multiple operations), passing the mount point and device name as
> command-line parameters.  Each /sbin/umount_* program could do any
> special actions necessary before and/or after calling umount(2).  If the
> exec fails then umount(1) would just call umount(2) under the assumption
> nothing else special needes to be done.

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.

> I'm not so sure any more that it's worthwhile having the kernel try to
> do anything to some other user-land object (such as a process) upon
> umount of a special fileystem that has such an object associated with
> it.  The only thing that would make sense would be to always use a lone
> sentinel process for each such filesystem and to have the kernel keep
> track of its pid and to send a SIGTERM to it on umount.  I'm not sure
> the added kernel complexity is worth the effort since most(all?) of the
> umount operations will(should) be initiated from userland by
> /sbin/umount anyway, and in the case of a "clean" shutdown or reboot
> then all processes will normally get a SIGTERM anyway before umount()s
> are forced by the kernel.

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

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

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

Take care,

Bill