> umount.udisks talks to the udisks daemon which keeps state > on the block devices it manages and it also cleans up things that were > created (directories etc.) at mount time That does sound similar to the problem that some network fs face. How to cleanup resources (e.g. cached metadata) better at umount time (since kill_sb can take a while to be invoked) > The first step should be to identify what exactly keeps your mount busy > in generic/044 and generic/043. That is a little tricky to debug (AFAIK no easy way to tell exactly which reference is preventing the VFS from proceeding with the umount and calling kill_sb). My best guess is something related to deferred close (cached network file handles) that had a brief refcount on something being checked by umount, but when I experimented with deferred close settings that did not seem to affect the problem so looking for other possible causes. I just did a quick experiment by adding a 1 second wait inside umount and confirmed that that does fix it for those two tests when mounted to Samba, but not clear why the slight delay in umount helps as there is no pending network traffic at that point. On Mon, Jul 29, 2024 at 4:50 AM Christian Brauner <brauner@xxxxxxxxxx> wrote: > > On Sun, Jul 28, 2024 at 02:09:14PM GMT, Steve French wrote: > > 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? > > Helpers such as mount.* or umount.* are used by util-linux. They're not > supposed to be directly used (usually). > > For example, umount.udisks talks to the udisks daemon which keeps state > on the block devices it manages and it also cleans up things that were > created (directories etc.) at mount time. Such mounts are usually marked > e.g., via helper=udisks to instruct util-linux to call umount.udisks > > Similar things probably apply to the others. > > > 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) > > The first step should be to identify what exactly keeps your mount busy > in generic/044 and generic/043. If you don't know what the cause of this > is no notification from VFS will help you. My guess is that this ends up > being fixable in cifs. -- Thanks, Steve
