From owner-freebsd-ports@FreeBSD.ORG Mon Jan 23 22:57:47 2006 Return-Path: X-Original-To: ports@FreeBSD.org Delivered-To: freebsd-ports@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B325E16A535 for ; Mon, 23 Jan 2006 22:57:28 +0000 (GMT) (envelope-from ale@FreeBSD.org) Received: from andxor.it (relay.andxor.it [195.223.2.3]) by mx1.FreeBSD.org (Postfix) with SMTP id E9A014402A for ; Mon, 23 Jan 2006 22:29:56 +0000 (GMT) (envelope-from ale@FreeBSD.org) Received: (qmail 42358 invoked from network); 23 Jan 2006 22:29:55 -0000 Received: from unknown (HELO ?192.168.178.2?) (a.premoli@andxor.it@81.174.31.42) by andxor.it with SMTP; 23 Jan 2006 22:29:55 -0000 Message-ID: <43D558E1.5080703@FreeBSD.org> Date: Mon, 23 Jan 2006 23:29:53 +0100 From: Alex Dupre User-Agent: Thunderbird 1.5 (X11/20060113) MIME-Version: 1.0 To: Jean-Yves Lefort References: <20060123040721.GA95972@xor.obsecurity.org> <43D47E36.1070906@FreeBSD.org> <20060123212614.6f570f8f.jylefort@FreeBSD.org> In-Reply-To: <20060123212614.6f570f8f.jylefort@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ports@FreeBSD.org, kris@obsecurity.org Subject: Re: fam vs gamin X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2006 22:57:47 -0000 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