From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 12 14:38:22 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 037965F2; Thu, 12 Mar 2015 14:38:22 +0000 (UTC) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 833B7194; Thu, 12 Mar 2015 14:38:21 +0000 (UTC) Received: by wggz12 with SMTP id z12so16904679wgg.0; Thu, 12 Mar 2015 07:38:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=T/OEO+HYI0QKt2AfYVuj6B/9LA6jMprWL6f5N0gJRF4=; b=ufouSQX7HYPEZHjjfuP1KcnGvltw1cdN9Ob0EJ3MDZwt13i2Ufx8yi551IMCKZVwGj B52/yUa857ZFKL0qfbR9plusWYSGgZL+64d+oyRcWyo4trYPMhull5S/fe6BldCauGlc hGxCYnctUP+UvZavAXPSsr8qqkhM9l9fU0FCWKW0IE62lc5fsKtOkZVZEnPPjDGDhp/J IHTmRSnkeu/wJg2aP5tlAH7GXEpTPhc7lZ6MlA6ahtf8c06/zRWaqcVeLq3IicsXEvoR ++Gmqfec0j5JnQbpGCm2CsuGjt00topA1JF+MXTVS2T732o1eihezfdgZtPM6OHU9NO9 iJjw== X-Received: by 10.180.80.199 with SMTP id t7mr14409305wix.52.1426171099201; Thu, 12 Mar 2015 07:38:19 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id n1sm29674184wib.11.2015.03.12.07.38.17 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 12 Mar 2015 07:38:17 -0700 (PDT) Date: Thu, 12 Mar 2015 15:38:15 +0100 From: Mateusz Guzik To: Don Lewis Subject: Re: file system change notifications Message-ID: <20150312143814.GA9153@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Don Lewis , oliver.pinter@hardenedbsd.org, int0dster@gmail.com, freebsd-hackers@FreeBSD.org, shawn.webb@hardenedbsd.org References: <20150311224831.GB18699@dft-labs.eu> <201503112318.t2BNIboU092815@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <201503112318.t2BNIboU092815@gw.catspoiler.org> User-Agent: Mutt/1.5.21 (2010-09-15) 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: Thu, 12 Mar 2015 14:38:22 -0000 On Wed, Mar 11, 2015 at 04:18:37PM -0700, Don Lewis wrote: > 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. > Just refing is quite insufficient and may not work at all. Due to hardlinks files can have more than one name. So preferably we would stop tossing vnodes around and create an intermediate object which would keep name component and a pointer to an inode. And that's what we would keep in struct file. Then a namecache would just be a hash of such objects. That's quite a lot of work though and unfortunately is likely too complicated for gsoc. -- Mateusz Guzik