From owner-freebsd-fs  Thu Apr 24 04:49:23 1997
Return-Path: <owner-fs>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id EAA02464
          for fs-outgoing; Thu, 24 Apr 1997 04:49:23 -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 EAA02459
          for <fs@freebsd.org>; Thu, 24 Apr 1997 04:49:21 -0700 (PDT)
Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.5/CET-v2.1) with SMTP id LAA13640; Thu, 24 Apr 1997 11:49:14 GMT
Date: Thu, 24 Apr 1997 20:49:14 +0900 (JST)
From: Michael Hancock <michaelh@cet.co.jp>
To: Poul-Henning Kamp <phk@dk.tfs.com>
cc: fs@freebsd.org
Subject: Re: the namei cache... 
In-Reply-To: <801.861878478@critter>
Message-ID: <Pine.SV4.3.95.970424202555.13551A-100000@parkplace.cet.co.jp>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-fs@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

On Thu, 24 Apr 1997, Poul-Henning Kamp wrote:

> >With hashing you can work on the hashing algorithm.  Btw, what is the hash
> >key now?  vp+name[20]?
> 
> directory vnode v_id + the regular namei hash.

It's hard to tell how well keys are distributed.  The cn_hash component
seems like it can be improved, maybe by taking only 3 or 4 of the
characters in the name and then doing some shifts and xor's on them. 

	cnp->cn_hash = 0;
	for (cp = cnp->cn_nameptr; *cp != 0 && *cp != '/'; cp++)
		cnp->cn_hash += (unsigned char)*cp;
	cnp->cn_namelen = cp - cnp->cn_nameptr;
	if (cnp->cn_namelen > NAME_MAX) {
		error = ENAMETOOLONG;
		goto bad;
	}

Regarding the capability have you done any analysis on it's distribution?

Mike