4.8 ffs_dirpref problem

[Kirk McKusick]

	Date: Thu, 23 Oct 2003 11:08:02 -0700
	From: Ken Marx <kmarx at vicor.com>
	To: Julian Elischer <julian at vicor.com>
	CC: mckusick at mckusick.com, cburrell at vicor.com, davep at vicor.com,
		freebsd-fs at freebsd.org, gluk at ptci.ru, jpl at vicor.com,
		jrh at vicor.com, julian at vicor-nb.com, VicPE at aol.com
	Subject: Re: 4.8 ffs_dirpref problem
	X-ASK-Info: Confirmed by User

	Thanks for the reply,

	We actually *did* try -s 4096 yesterday (not quite what you
	suggested) with spotty results: Sometimes it seemed to go
	more quickly, but often not.

	Let me clarify our test: We have a 1.5gb tar file from our
	production raid that fairly represents the distribution of
	data. We hit the performance problem when we get to dirs
	with lots of small-ish files.  But, as Julian mentioned,
	we typically have many flavors of file sizes and populations.

	Admittedly, our untar'ing test isn't necessarily representitive
	of what happens in production - we were just trying to fill
	the disk and recreate the problem here. We *did* at least
	hit a noticeable problem, and we believe it's the same
	behavior that's hitting production.

	I just tried your exact suggested settings on an fs that
	was already 96% full, and still experienced the very sluggish
	behavior on exactly the same type of files/dirs.

	Our untar typically takes around 60-100 sec of system time
	when things are going ok; 300-1000+ sec when the sluggishness
	occurs.  This time tends to increase as we get closer to
	99%. Sometimes as high as 4000+ secs.

	I wasn't clear from your mail if I should newfs the entire
	fs and start over, or if I could have expected the settings
	to make a difference for any NEW data.

	I can do this latter if you think it's required. The test
	will then take several hours to run since we need at least
	85% disk usage to start seeing the problem.

	Thanks!
	k

Unfortunately, I do believe that you will need to start over from
scratch with a newfs. The problem is that by the time you are at
85% full with the old parameters, the directory structure is already
too "dense" forcing you to search far and wide for more inodes. If
you start from the beginning with a large filesperdir then your
directory structure will expand across more of the disk which
should approximate the old algorithm.

	Kirk McKusick