Skip site navigation (1)Skip section navigation (2)
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>