Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 24 Jan 2006 18:53:58 +0100
From:      Jean-Yves Lefort <jylefort@FreeBSD.org>
To:        Alex Dupre <ale@FreeBSD.org>
Cc:        ports@FreeBSD.org, kris@obsecurity.org
Subject:   Re: fam vs gamin
Message-ID:  <20060124185358.085c7af4.jylefort@FreeBSD.org>
In-Reply-To: <43D558E1.5080703@FreeBSD.org>
References:  <20060123040721.GA95972@xor.obsecurity.org> <43D47E36.1070906@FreeBSD.org> <20060123212614.6f570f8f.jylefort@FreeBSD.org> <43D558E1.5080703@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
--Signature=_Tue__24_Jan_2006_18_53_58_+0100_XVs5s4rIBow_O.MH
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, 23 Jan 2006 23:29:53 +0100
Alex Dupre <ale@FreeBSD.org> wrote:

> 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.
>=20
> 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):
>=20
>     /**
>      * Todo: check if write will block, or use non-blocking options
>      */
>=20
> I suspect the write to one client blocks and until some events are read
> no more events are delivered even to other clients.

You're probably right. Good catch.

> > 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.
>=20
> 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
>=20
> In any case I'll be more precise tomorrow.

Are you sure that:

  - you were monitoring the directories with FAMMonitorDirectory() and
    not FAMMonitorFile()?
  - you had the permission to open the directories?

--=20
Jean-Yves Lefort

jylefort@FreeBSD.org
http://lefort.be.eu.org/

--Signature=_Tue__24_Jan_2006_18_53_58_+0100_XVs5s4rIBow_O.MH
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (FreeBSD)

iD8DBQFD1mm2yzD7UaO4AGoRAkFJAJ9+k+be2Z6EfSS7OR6q9PQxs0IKQgCfQlkA
uIh0fsenf7DggcxyDwGwqp8=
=dR6B
-----END PGP SIGNATURE-----

--Signature=_Tue__24_Jan_2006_18_53_58_+0100_XVs5s4rIBow_O.MH--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060124185358.085c7af4.jylefort>