Date: Fri, 1 Jun 2001 10:52:40 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: Ian Dowse <iedowse@maths.tcd.ie> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: UFS large directory performance Message-ID: <200106011752.f51HqeS85237@earth.backplane.com> References: <200106011541.aa41502@salmon.maths.tcd.ie>
next in thread | previous in thread | raw e-mail | index | archive | help
: :Prompted by the recent discussion about performance with large :directories, I had a go at writing some code to improve the situation :without requiring any filesystem changes. Large directories can :usually be avoided by design, but the performance hit is very :annoying when it occurs. The namei cache may help for lookups, but :each create, rename or delete operation always involves a linear :sweep of the directory. : :The idea of this code is to maintain a throw-away in-core data :structure for large directories, allowing all operations to be :performed quickly without the need for a linear search. The :experimental (read 'may trash your system'!) proof-of-concept patch :is available at: : : http://www.maths.tcd.ie/~iedowse/FreeBSD/dirhash.diff Ian, you've outdone yourself this time. This is outstanding! What are your commit plans? It looks extremely well contained, it could be committed to -current and then -stable a few days later without any destabilizing impact at all for when the option isn't specified. I really like the way you cut down the kernel memory required by making the hash table basically an array of doff_t's. That more then makes up for the nslot estimation wasteage. The only potential problem I see here is that you could end up seriously fragmenting the malloc pool you are using to allocate the slot arrays. And, of course, the two issues you brought up in regards to regularing memory use. -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?200106011752.f51HqeS85237>