From owner-freebsd-hackers  Fri Jun  8  0:44:27 2001
Delivered-To: freebsd-hackers@freebsd.org
Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.121.12])
	by hub.freebsd.org (Postfix) with ESMTP id 684E237B405
	for <freebsd-hackers@FreeBSD.ORG>; Fri,  8 Jun 2001 00:44:24 -0700 (PDT)
	(envelope-from tlambert2@mindspring.com)
Received: from mindspring.com (dialup-209.245.138.245.Dial1.SanJose1.Level3.net [209.245.138.245])
	by harrier.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id AAA19091;
	Fri, 8 Jun 2001 00:44:20 -0700 (PDT)
Message-ID: <3B208271.9F1E93B1@mindspring.com>
Date: Fri, 08 Jun 2001 00:44:49 -0700
From: Terry Lambert <tlambert2@mindspring.com>
Reply-To: tlambert2@mindspring.com
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Ian Dowse <iedowse@maths.tcd.ie>
Cc: Matt Dillon <dillon@earth.backplane.com>,
	freebsd-hackers@FreeBSD.ORG
Subject: Re: UFS large directory performance
References: <200106031747.aa54373@salmon.maths.tcd.ie>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-hackers.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-hackers>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-hackers>
X-Loop: FreeBSD.ORG

Ian Dowse wrote:
> Nice idea, but I'm not sure I see the benefit of partially reclaiming
> second-level arrays. Because it is a hash array, there isn't really
> the concept of a working set; a directory that is `in use' will
> rarely see many create/rename/delete operations on a small fixed
> set of filenames. The lookup case is already cached elsewhere. I
> think an all-or-nothing approach is likely to perform better and
> be simpler to implement. Even the lazy allocation of second-level
> arrays is unlikely to help a lot if the hash function does its job
> well.

From this perspective, it seems to me that there could be
significant benefit in getting rid of the ihash cache; but
then I've always hated the thing, since there's no way to
reassociate a vnode with valid, clean data hanging off it
with an ihash entry, when you get an ihash cache hit.

Totally off the dirpref topic, cut of the same philosophical
bent that your statement above seems to advocate...

-- Terry

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message