Date: Wed, 13 Sep 2023 09:46:22 +0100 From: David Chisnall <theraven@FreeBSD.org> To: Bakul Shah <bakul@iitbombay.org> Cc: Graham Perrin <grahamperrin@gmail.com>, FreeBSD CURRENT <freebsd-current@freebsd.org> Subject: Re: Continually count the number of open files Message-ID: <1D86A8FB-ACC6-427E-ABB0-2E1A5989170E@FreeBSD.org> In-Reply-To: <592123F4-E610-446E-82B4-ACC519C0BA3E@iitbombay.org> References: <291ad2de-ba0e-4bdf-786a-19614eacec49@gmail.com> <592123F4-E610-446E-82B4-ACC519C0BA3E@iitbombay.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12 Sep 2023, at 17:19, Bakul Shah <bakul@iitbombay.org> wrote: >=20 > FreeBSD > should add inotify. inotify is also probably not the right thing. If someone is interested = in adding this, Apple=E2=80=99s fsevents API is a better inspiration. = It is carefully designed to ensure that the things monitoring for events = can=E2=80=99t ever block filesystem operations from making progress. I = think there=E2=80=99s a nice design possible with a bloom filter in the = kernel of events that ensures that monitors may get spurious events but = don=E2=80=99t miss out on anything. =20 On macOS because files have a stronger idea of which directory they live = in and so it=E2=80=99s easier to have an API that notifies for changes = to files in a directory. inotify monitors individual files but loses = notifications if you write through the wrong hard link to a file (hard = link foo from a/foo to b/foo, use inotify to watch a, write though = b/foo, observe no notification). I think the right kernel API would = walk the directory and add the vnodes to a bloom filter and trigger a = notification on a match in the filter. You=E2=80=99d then have = occasional spurious notifications but you=E2=80=99d have something that = could be monitored via kqueue and could be made to not block anything = else in the kernel. If anyone is interested in improving the current kqueue code here: = there=E2=80=99s currently no mechanism for tracking when the last = writable file descriptor for a file has been closed, which is useful for = consuming files that are dropped via sftp or similar. NOTE_CLOSED_WRITE = is hard to use without race conditions and tells you only that *a* file = descriptor with write permission has closed, not that the last one has = closed. I=E2=80=99m currently resorting to a process that runs as root = that uses libprocstat to walk the entire list of open file descriptors = and report that they=E2=80=99re closed, which is incredibly suboptimal. David
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1D86A8FB-ACC6-427E-ABB0-2E1A5989170E>