Re: Goodbye HFS.FST (crashed HD again)

[nathan@visi.com (Nathan Mates)]

In article <5184id$89k@nnrp1.news.primenet.com>,
John Bowling <johnlb@primenet.com> wrote:
>I have noticed a speed increase in getting a directory listing on an HFS
>drive after assuring that files are placed on the drive in alpha order.
>This shows up when doing a listing in the Orca shell as well as in a
>desktop program which calls standard file selection routines.
>If a B tree is used, it should make no difference where things are at
>when the tree is traversed.  The difference is more noticable with more
>files in the directory, which would lead to an assumption of some form
>of sort routine being used.

   What's likely happening is what I described before: with a B-Tree,
you are not guaranteed locality of entries on the disk. Due to the
structures, your catalog can be spewed all over the disk, much the
same way regular files can be fragmented. Since the individual parts
are smaller, you have a greater chance of being fragmented. Also, as
directories are accessed far more often than regular files, they are a
lot more sensitive to fragmentation speed hits than the average file.

   ProDOS directory blocks have a LOT more entries per disk block, so
they're much less likely to see this problem if they're fragmented.

   A good HFS disk defragger _should_ have the option of putting all
directory blocks together (including the extents, overflows, etc) so
that even if lots of blocks are accessed, it's either in your HD's
cache, or the head doesn't have to move too far.

   Given that the GS doesn't have a HFS debugger, worrying about a
defragger is something for much later.

Nathan Mates

--
<*> Nathan Mates http://www.visi.com/~nathan/      <*>
# What are the facts? Again and again and again-- what are the _facts_?
# Shun wishful thinking, avoid opinion, care not what the neighbors
# think-- what are the facts, and to how many decimal places?  -R.A. Heinlein