Date: Thu, 12 Mar 2015 15:38:15 +0100 From: Mateusz Guzik <mjguzik@gmail.com> To: Don Lewis <truckman@FreeBSD.org> Cc: freebsd-hackers@FreeBSD.org, int0dster@gmail.com, oliver.pinter@hardenedbsd.org, shawn.webb@hardenedbsd.org Subject: Re: file system change notifications Message-ID: <20150312143814.GA9153@dft-labs.eu> In-Reply-To: <201503112318.t2BNIboU092815@gw.catspoiler.org> References: <20150311224831.GB18699@dft-labs.eu> <201503112318.t2BNIboU092815@gw.catspoiler.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <mjguzik gmail.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150312143814.GA9153>