I noticed that nfs has a umount helper (/sbin/umount.nfs) as does hfs
(as does /sbin/umount.udisks2). Any ideas why those are the only
three filesystems have them but other fs don't?
Since umount does not notify the filesystem on unmount until
references are closed (unless you do "umount --force") and therefore
the filesystem is only notified at kill_sb time, an easier approach to
fixing some of the problems where resources are kept around too long
(e.g. cached handles or directory entries etc. or references on the
mount are held) may be to add a mount helper which notifies the fs
(e.g. via fs specific ioctl) when umount has begun. That may be an
easier solution that adding a VFS call to notify the fs when umount
begins. As you can see from fs/namespace.c there is no mount
notification normally (only on "force" unmounts)
/*
* If we may have to abort operations to get out of this
* mount, and they will themselves hold resources we must
* allow the fs to do things. In the Unix tradition of
* 'Gee thats tricky lets do it in userspace' the umount_begin
* might fail to complete on the first run through as other tasks
* must return, and the like. Thats for the mount program to worry
* about for the moment.
*/
if (flags & MNT_FORCE && sb->s_op->umount_begin) {
sb->s_op->umount_begin(sb);
}
Any thoughts on why those three fs are the only cases where there are
umount helpers? And why they added them?
I do notice umount failures (which can cause the subsequent mount to
fail) on some of our functional test runs e.g. generic/043 and
generic/044 often fail to Samba with
QA output created by 043
+umount: /mnt-local-xfstest/scratch: target is busy.
+mount error(16): Device or resource busy
Ideas?
--
Thanks,
Steve
