From owner-freebsd-hackers Fri Jun 1 11: 6:29 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 1ACA537B422; Fri, 1 Jun 2001 11:06:26 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.3/8.11.2) id f51I6PK85431; Fri, 1 Jun 2001 11:06:25 -0700 (PDT) (envelope-from dillon) Date: Fri, 1 Jun 2001 11:06:25 -0700 (PDT) From: Matt Dillon Message-Id: <200106011806.f51I6PK85431@earth.backplane.com> To: Robert Watson Cc: Ian Dowse , freebsd-hackers@FreeBSD.ORG Subject: Re: UFS large directory performance References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :This is great -- once I finish moving back to Maryland (sometime :mid-next-week) I'd be very interested in running this code on a -CURRENT :mock-up of my Cyrus server, which regularly runs with 65,000+ file :directories. I assume this is a -CURRENT patch set? : :(Mind you, I've found that most of the perceived "large directory :suffering" people tell me about is running ls with sorting enabled :-). : :Robert N M Watson FreeBSD Core Team, TrustedBSD Project :robert@fledge.watson.org NAI Labs, Safeport Network Services I can see this really helping mail queue performance, especially when coupled with softupdates, and also helping samba (windoz likes to scan directories), and perhaps even squid to a degree. It won't beat an on-disk B+Tree, but it's about as close as you can get with UFS. And adding the free-space statistics is icing on the cake. This will also greatly reduce buffer cache lock contention on directories undergoing simultanious background I/O (aka softupdates). -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message