From owner-freebsd-hackers Sun Apr 27 12:00:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA23482 for hackers-outgoing; Sun, 27 Apr 1997 12:00:25 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id MAA23474 for ; Sun, 27 Apr 1997 12:00:21 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA08913; Sun, 27 Apr 1997 11:55:34 -0700 From: Terry Lambert Message-Id: <199704271855.LAA08913@phaeton.artisoft.com> Subject: Re: namei & hash functions To: michaelh@cet.co.jp (Michael Hancock) Date: Sun, 27 Apr 1997 11:55:34 -0700 (MST) Cc: terry@lambert.org, bde@zeta.org.au, msmith@atrad.adelaide.edu.au, hackers@hub.freebsd.org In-Reply-To: from "Michael Hancock" at Apr 27, 97 10:42:13 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > 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. I assume that it's multiply linked? Otherwise you'd have problems on volume flush on unmount, etc.. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.