Date: Wed, 31 Mar 2021 07:45:49 +0200 From: Damjan Jovanovic <damjan.jov@gmail.com> To: Emanuel Haupt <ehaupt@freebsd.org> Cc: hackers@freebsd.org Subject: Re: RFC: possible issue with kqueue Message-ID: <CAJm2B-kbkJPUHiurCfYsOmrCFSNPBD74FYsHsuNNdOVC6F4C%2BQ@mail.gmail.com> In-Reply-To: <20210330181402.GM14975@funkthat.com> References: <20210327131011.e16291cac86475e75a33812c@FreeBSD.org> <20210330181402.GM14975@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Mar 30, 2021 at 8:14 PM John-Mark Gurney <jmg@funkthat.com> 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. > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJm2B-kbkJPUHiurCfYsOmrCFSNPBD74FYsHsuNNdOVC6F4C%2BQ>