RFC: possible issue with kqueue

[Ian Lepore]

On Tue, 2021-03-30 at 15:01 -0600, Warner Losh wrote:
> 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

Yeah, I was kinda wondering what do about the case where the unmount
ultimately failed.  The only thought I had was some kind of followup
event to inform folks of that (either a fake mount event, or a specific
unmount-failed event).

-- Ian