RFC: possible issue with kqueue

[John-Mark Gurney]

Ian Lepore wrote this message on Tue, Mar 30, 2021 at 12:51 -0600:
> 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?

Why not the soft close flag that I propose?  It's nice and simple in
that you just have to flag the various fd's in the app as opposed to
add additional logic, and figure out how to tell the app to close the
fd's...

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."