fam vs gamin

Alex Dupre ale at FreeBSD.org
Mon Jan 23 14:57:47 PST 2006


Jean-Yves Lefort wrote:
> The delays are likely caused by the fact that you have reached the
> file descriptor limit; beyond that limit, gamin can no longer monitor
> files with kqueue, and has to periodically lstat() them. You should
> try to set a very large kern.maxfiles in /boot/loader.conf (you need
> one file descriptor per monitored file); see pkg-message for details.

Yes, I did it, but the problem about delays was different (not a matter
of a few seconds related to kqueue or polling). Today I discovered it's
present also with polling and probably due to this (from gam_channel.c):

    /**
     * Todo: check if write will block, or use non-blocking options
     */

I suspect the write to one client blocks and until some events are read
no more events are delivered even to other clients.

> However, events should never be lost (although they can be
> substantially delayed when monitoring a very large directory on a slow
> machine, because event processing time increases linearly with the
> number of files contained in the directory). Please cc your findings
> to me.

Of course. Today I had no time to test the kqueue backend, but I'll do
it tomorrow. If I remember correctly, this was the scenario where I
detected lost events:
- a few dirs with thousans file (5 dirs with 2000 files)
- new fam connection and 5 monitors on these dirs
- one or two directory correctly delivered Exists events for the
existing files, the others delivered only Exists and EndExist for the
directories, as if they were empty

In any case I'll be more precise tomorrow.

--
Alex Dupre



More information about the freebsd-ports mailing list