Date: Thu, 18 Oct 2001 20:26:00 +0100 From: Tim Bunce <Tim.Bunce@pobox.com> To: freebsd-stable@freebsd.org Subject: Re: dirpref gives massive performance boost Message-ID: <20011018202600.Q8270@dansat.data-plan.com> In-Reply-To: <200110181806.f9II6Yn92967@lurza.secnetix.de>; from olli@secnetix.de on Thu, Oct 18, 2001 at 08:06:34PM %2B0200 References: <01d101c157fb$1fab1c80$fe0c4042@inethouston.net> <200110181806.f9II6Yn92967@lurza.secnetix.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Oct 18, 2001 at 08:06:34PM +0200, Oliver Fromme wrote: > > There is nothing in particular that enables dirprefs. > It's not a flag or anything. When you're using a new > kernel with the dirprefs code, it's in effect immediately, > whether you newfs your filesystems or not. > > The point is just that the best improvement is achieved > when you empty your filesystems and restore them. > "rm -rf" will do, but newfs is simply faster. > The diprefs code changes the way directories are laid > out on the disk when you _create_ them. Therefore, it > does not improve preformance on old directories which > existed before the dirprefs code went into the kernel. > It only affects directories created with the dirprefs > code. That's why people recommend to newfs and restore > your filesystems: in order to give the dirprefs code > (in the kernel) a chance to do its work on the whole > filesystem. Thanks for the explanation Oliver. I'd like to clarify one point... Can the diprefs code have a useful effect on an individual subtree of a file system if just that tree was deleted and recreated? For example... an 'ordinary' sprawling filesystem that has one particular subtree, a few levels down, that contains thousands of directories each containing a few small data files. In that subtree the files randomly get lots of open-read-close activity. Is it likely that deleting and recreating just that subtree would have a significant performance gain (relative to the max gain a complete rebuild would yeild)? Or would it depend on the available space or level of fragmentation of the overall filesystem or some other imponderable? Tim. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011018202600.Q8270>