From owner-freebsd-hackers Sun Apr 27 17:49:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA09098 for hackers-outgoing; Sun, 27 Apr 1997 17:49:26 -0700 (PDT) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA09093 for ; Sun, 27 Apr 1997 17:49:24 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.5/CET-v2.1) with SMTP id AAA29015; Mon, 28 Apr 1997 00:48:58 GMT Date: Mon, 28 Apr 1997 09:48:58 +0900 (JST) From: Michael Hancock To: Terry Lambert cc: bde@zeta.org.au, msmith@atrad.adelaide.edu.au, hackers@hub.freebsd.org Subject: Re: namei & hash functions In-Reply-To: <199704271855.LAA08913@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 27 Apr 1997, Terry Lambert wrote: > > He's working on another approach that simplifies keeping the name cache > > and active vnode in sync by hanging the name cache of the directory vnode. > > A lot of us are saying that operations like article list request against > > innd would suffer with this approach. > > Ugh. I do not like this. It breaks locality of reference for cache > entry flushing. I don't think it's that big a win for lookup anyway; > a hash is a hash, and the fill should be proportionate. There will > be a problem in that you can size a "whole FS hash" by knowing how > many files are in the FS, but sizing a "per directory hash" is much > more problematic. It's a per directory linked list, see the patch on the fs list. It's just experimentation, I'm finding it a good way to get more familiar with the name cache code and related issues. Mike Hancock