RFC: possible issue with kqueue

[John-Mark Gurney]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254024

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...

[Ian Lepore]

Emanuel Haupt wrote this message on Sat, Mar 27, 2021 at 13:10

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254024

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

[Graham Perrin]

Looks like the user wasn't force unmounting the FS.

I very rarely apply force without knowing what's open.

Some technical skill was required to discover what was open.

It's quicker and easier for me to kill the gvfsd-trash process. Not
complaining; just saying :-)

[Damjan Jovanovic]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254024

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.
--
John-Mark Gurney Voice: [phone]

Linux's inotify avoids this problem by monitoring filesystem paths instead
of file descriptors, which also has the advantage of not contributing to
the open file limit. Can we do something like that?

Damjan

[Gleb Popov]

Post by Damjan Jovanovic

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254024

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.
--
John-Mark Gurney Voice: [phone]

Linux's inotify avoids this problem by monitoring filesystem paths instead
of file descriptors, which also has the advantage of not contributing to
the open file limit. Can we do something like that?

The "O_PATH" flag support is being cooked in
https://reviews.freebsd.org/D29323 , maybe it'd be possible to build
something upon it.

However, I was under the impression that the Linux advantage is the ability
to set a single watch on a whole directory, while kqueue requires opening
each file.

Post by Damjan Jovanovic
https://reviews.freebsd.org/D19690
I do not finish this.
Plan was: implement this and catch unmount notify in my FAM, that in
glib20.

Hum, but I do see mount/unmount events in devd on CURRENT!

[Warner Losh]

Post by Gleb Popov

Post by Rozhuk Ivan
https://reviews.freebsd.org/D19690
I do not finish this.
Plan was: implement this and catch unmount notify in my FAM, that in
glib20.

Hum, but I do see mount/unmount events in devd on CURRENT!

I did this in conjunction with the forced unmount work of ***@. I was
unaware of this review, but this commit, and those that followed it, added
a similar feature.

Warner

commit 8ef773d1b4236ed3da368f9c91d15c5325d2e735
Author: Warner Losh <***@FreeBSD.org>
Date: Wed Aug 19 17:10:04 2020 +0000

Add VFS FS events for mount and unmount to devctl/devd

Report when a filesystem is mounted, remounted or unmounted via devd,
along with
details about the mount point and mount options.

Discussed with: kib@
Reviewed by: kirk@ (prior version)
Sponsored by: Netflix
Diffential Revision: https://reviews.freebsd.org/D25969

Notes:
svn path=/head/; revision=364402

[Rozhuk Ivan]

On Sat, 3 Apr 2021 11:21:50 -0600

Post by Gleb Popov

Post by Rozhuk Ivan
https://reviews.freebsd.org/D19690
I do not finish this.
Plan was: implement this and catch unmount notify in my FAM, that
in glib20.

Hum, but I do see mount/unmount events in devd on CURRENT!

Where I can learn more about this?

[Warner Losh]

Post by Rozhuk Ivan
On Sat, 3 Apr 2021 11:21:50 -0600

Post by Gleb Popov

Post by Rozhuk Ivan
https://reviews.freebsd.org/D19690
I do not finish this.
Plan was: implement this and catch unmount notify in my FAM, that
in glib20.

Hum, but I do see mount/unmount events in devd on CURRENT!

Where I can learn more about this?

The devd stuff is documented in devd.conf(5).

The umount stuff is documented in the commit message for hash
d79ff54b5caad61e657b9cc651aa256f3949b97a

commit d79ff54b5caad61e657b9cc651aa256f3949b97a
Author: Chuck Silvers <***@FreeBSD.org>
Date: Mon May 25 23:47:31 2020 +0000

This commit enables a UFS filesystem to do a forcible unmount when
the underlying media fails or becomes inaccessible. For example
when a USB flash memory card hosting a UFS filesystem is unplugged.
...
https://cgit.freebsd.org/src/commit/?id=d79ff54b5caad61e657b9cc651aa256f3949b97a

has the whole commit message. I'm not aware of other documentation for it
though.

Warner

[Rozhuk Ivan]

On Tue, 6 Apr 2021 22:50:16 -0600

Post by Warner Losh

Post by Rozhuk Ivan

Post by Gleb Popov

Post by Rozhuk Ivan
https://reviews.freebsd.org/D19690
I do not finish this.
Plan was: implement this and catch unmount notify in my FAM,
that in glib20.

Hum, but I do see mount/unmount events in devd on CURRENT!

Where I can learn more about this?

The devd stuff is documented in devd.conf(5).
The umount stuff is documented in the commit message for hash
d79ff54b5caad61e657b9cc651aa256f3949b97a

Sorry, it is unclear to me: who uses mount/unmount devd notifications?

[Warner Losh]

Post by Rozhuk Ivan
On Tue, 6 Apr 2021 22:50:16 -0600

Post by Warner Losh

Post by Rozhuk Ivan

Post by Gleb Popov

Post by Rozhuk Ivan
https://reviews.freebsd.org/D19690
I do not finish this.
Plan was: implement this and catch unmount notify in my FAM,
that in glib20.

Hum, but I do see mount/unmount events in devd on CURRENT!

Where I can learn more about this?

The devd stuff is documented in devd.conf(5).
The umount stuff is documented in the commit message for hash
d79ff54b5caad61e657b9cc651aa256f3949b97a

Sorry, it is unclear to me: who uses mount/unmount devd notifications?

Devd has a config file that you can use to configure scripts that run when
mount/umount happens. The bsdisk port uses it to track what was mounted.

Warner

[Rozhuk Ivan]

On Sat, 27 Mar 2021 13:10:11 +0100

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254024

Because FreeBSD does not have O_NOATIME and O_EVTONLY, like MacOS.

[Rozhuk Ivan]

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?

https://reviews.freebsd.org/D19690

I do not finish this.
Plan was: implement this and catch unmount notify in my FAM, that in glib20.