Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 02 Sep 1998 18:48:21 +0000
From:      Mike Smith <mike@smith.net.au>
To:        Terry Lambert <tlambert@primenet.com>
Cc:        cmascott@world.std.com (Carl Mascott), hackers@FreeBSD.ORG
Subject:   Re: Reading/writing /usr/ports is VERY slow 
Message-ID:  <199809021848.SAA01527@dingo.cdrom.com>
In-Reply-To: Your message of "Thu, 03 Sep 1998 01:12:26 GMT." <199809030112.SAA02792@usr07.primenet.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
> > However,
> > if a cg proximity criterion were added to the new-cg-chooser,
> > then the size of a cg would become a factor, although I don't
> > know how important a factor.
> 
> Very important.  It would result in FFS finally adding "support"
> for fragmenting the bejesus out of a disk drive.
> 
> This would be a *very* bad thing.

Could you explain how the proposed change would do this?  It's no worse
than the current case if there is one cg with substantially fewer
directories than any other.  In fact, you could simplify the code
somewhat just by lying about the number of directories in the cg
referenced by the rotor.

> > Hopefully someone who knows the history of FFS development
> > will chime in at this point.  It would be nice to know if
> > any other directory placement policies were ever tried and
> > rejected.
> 
> The original "free reserve" values were set to 10% for a reason; it
> was a compromise between people who wanted to use every byte, and
> the actual 15% value required for a "perfect hash".

The change I proposed honours the reserve.  Now I *know* you didn't 
look at it. 8)

> In effect, when the FS picks a block (or, more correctly, a cluster),
> it is hashing the filespace onto the disk.

Unfortunately, in the case of directories this results in them being 
scattered all over the disk.  If you're creating a pile of them all at 
once in a hierarchy, the net result is very poor locality of reference.

Associating locality and time of creation is not a wonderful algorithm, 
I freely admit.  However, I think that it has some merit over the 
current approach (forcibly minimise locality under some circumstances).

If you have the stuff set up to test, I'd really be interested to see 
if the clustering I proposed demonstrated any effects.

-- 
\\  Sometimes you're ahead,       \\  Mike Smith
\\  sometimes you're behind.      \\  mike@smith.net.au
\\  The race is long, and in the  \\  msmith@freebsd.org
\\  end it's only with yourself.  \\  msmith@cdrom.com



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?199809021848.SAA01527>