RFC: possible issue with kqueue

[Warner Losh]

On Tue, Mar 30, 2021 at 12:51 PM Ian Lepore <ian at freebsd.org> wrote:

> On Tue, 2021-03-30 at 11:14 -0700, John-Mark Gurney wrote:
> > Emanuel Haupt wrote this message on Sat, Mar 27, 2021 at 13:10 +0100:
> > > Can someone familiar with kqueue please comment on:
> > >
> > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254024
> >
> > Done:
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254024#c11
> >
> > Looks like the user wasn't force unmounting the FS.  There really
> > isn't any problem w/ kqueue, as a normal unmount is expected to be
> > refused while files are open.
> >
> > I guess there COULD be a new flag added to file descriptors that
> > flag them as being able to be closed upon unmount.  Then when an
> > unmount happens and only these flagged files remain, they are closed
> > allowing the fs to unmount.  But this is a new feature and
> > independent
> > of kqueue.
> >
>
> While it's not a kqueue bug per se, it is a weakness in freebsd that
> there is no way to monitor a volume, or items within that volume,
> without making it impossible to unmount the volume.  I've been fighting
> this with various implementations of desktop software for like 20 years
> on freebsd.  Usually I have to just disable all monitoring and live
> with the reduced desktop functionality.
>
> I wonder if a reasonable fix might be to have some sort of pre-unmount
> event that can be delivered via kqueue, so that a userland entity
> monitoring on that volume has a chance to close related descriptors so
> that the unmount can proceed?
>

That's not a bad idea. I've often thought we need a wider range of quiesce
calls / events / whatever that would allow people with 'soft' references to
drop
them in advance of an attempted event. I've never been sure what to do if
the attempted event failed, so I've not gotten off the mark... this is but
one
example...

Warner