I have just implemented a more-or-less SysVr4-like "df -g" for NetBSD
(the frag size and filename length fields are faked, at least for now
since the necessary information isn't (yet) in struct statfs and I
didn't bother doing the extra pathconf(foo, _PC_NAME_MAX) for the latter).

As you can see in the sample output from it below the filesystem type is
indeed already always available.

(though apparently only as a name, the f_type field really is still
always zero, as the manual page suggests, but that's fine for now!):

$ ./df -g / /tmp /kern /proc /fdesc /most/big1               
       / (/dev/sd0a   ):  1024 block size      1024 frag size
  490591 total blocks   202041 free blocks   177511 available 123902 total files
  109748 free files           0x00000400:0x0000078b filesys id
  ffs[0] fstype         0x5100 flag             255 filename length
       0 owner             440 syncwrites    457462 asyncwrites

    /tmp (mfs:129     ):  1024 block size      1024 frag size
  247703 total blocks   247170 free blocks   234784 available  63294 total files
   63278 free files           0x0000ff00:0x0000078b filesys id
  mfs[0] fstype         0x1158 flag             255 filename length
       0 owner               0 syncwrites      3232 asyncwrites

   /kern (kernfs      ):   512 block size      1024 frag size
       2 total blocks        0 free blocks        0 available      0 total files
       0 free files           0x0000a001:0x0001d28b filesys id
kernfs[0] fstype         0x1000 flag             255 filename length
       0 owner               0 syncwrites         0 asyncwrites

   /proc (procfs      ):  4096 block size      1024 frag size
       1 total blocks        0 free blocks        0 available   4116 total files
    3985 free files           0x00003001:0x0001ae1b filesys id
procfs[0] fstype         0x1000 flag             255 filename length
       0 owner               0 syncwrites         0 asyncwrites

  /fdesc (fdesc       ):   512 block size      1024 frag size
       2 total blocks        0 free blocks        0 available     97 total files
      65 free files           0x00001401:0x000078ff filesys id
fdesc[0] fstype         0x1000 flag             255 filename length
       0 owner               0 syncwrites         0 asyncwrites

/most/big1 (most.weird.com:/big1):   512 block size      1024 frag size
 8016882 total blocks  1206000 free blocks   805154 available 1011262 total files
  839378 free files           0x00002001:0x0000070b filesys id
  nfs[0] fstype           0x18 flag             255 filename length
       0 owner               0 syncwrites         0 asyncwrites


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.

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.


Note that for something like MFS the PID of the associated process is
already also stored in the kernel as part of the "device" name, so
passing that name to the /sbin/umount_mfs program would make it trivial
for a signal to be sent to the running mount_mfs process upon umount.

$ ./df /tmp
Filesystem 512-blocks     Used    Avail %Cap Mounted on
mfs:129        495406     1066   469568   0% /tmp
$ ps -p 129
PID TT STAT   TIME COMMAND
129 ?? Is   0:04.28 mount_mfs -o nodev -o nosuid -o async -s 512000 /dev/sd0b /t


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