Re: Continually count the number of open files

On 12 Sep 2023, at 17:19, Bakul Shah <bakul@iitbombay.org> wrote:
> 
> FreeBSD
> should add inotify.

inotify is also probably not the right thing.  If someone is interested in adding this, Apple’s fsevents API is a better inspiration.  It is carefully designed to ensure that the things monitoring for events can’t ever block filesystem operations from making progress.  I think there’s a nice design possible with a bloom filter in the kernel of events that ensures that monitors may get spurious events but don’t miss out on anything.  

On macOS because files have a stronger idea of which directory they live in and so it’s 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’d then have occasional spurious notifications but you’d 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’s 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’m 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’re closed, which is incredibly suboptimal.

David