From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 11 23:18:50 2015 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 958AFBD for ; Wed, 11 Mar 2015 23:18:50 +0000 (UTC) Received: from gw.catspoiler.org (cl-1657.chi-02.us.sixxs.net [IPv6:2001:4978:f:678::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 418ECD86 for ; Wed, 11 Mar 2015 23:18:50 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id t2BNIboU092815; Wed, 11 Mar 2015 15:18:41 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201503112318.t2BNIboU092815@gw.catspoiler.org> Date: Wed, 11 Mar 2015 16:18:37 -0700 (PDT) From: Don Lewis Subject: Re: file system change notifications To: mjguzik@gmail.com In-Reply-To: <20150311224831.GB18699@dft-labs.eu> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-hackers@FreeBSD.org, int0dster@gmail.com, oliver.pinter@hardenedbsd.org, shawn.webb@hardenedbsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 23:18:50 -0000 On 11 Mar, Mateusz Guzik wrote: > On Wed, Mar 11, 2015 at 11:11:14PM +0100, Oliver Pinter wrote: >> Take a look at dazuko kernel module. Probably you should forward port >> them, because they are obsoleted. >> > > I checked the module out of curiosity. Their approach was to wrap various > syscalls and work from there. This is used to be the common approach > several years back it has a lot of shortcomings, complete lack of > reliability being the biggest one. > > As for better implementation: current namecache does not guarantee name > resolution (even if name was entered) and not all names end up in the > cache in the first place. > > Lack of reliability comes from the fact that the cache does not pin > vnodes in any way. I seem to recall reading a long time ago that DragonFly pins directories in the cache, or something like that.