Date: Fri, 1 Jun 2001 11:06:25 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: Robert Watson <rwatson@FreeBSD.ORG> Cc: Ian Dowse <iedowse@maths.tcd.ie>, freebsd-hackers@FreeBSD.ORG Subject: Re: UFS large directory performance Message-ID: <200106011806.f51I6PK85431@earth.backplane.com> References: <Pine.NEB.3.96L.1010601123814.65702E-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
: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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200106011806.f51I6PK85431>