Re: Goodbye HFS.FST (crashed HD again)

[dempson@actrix.gen.nz (David Empson)]

John Bowling <johnlb@primenet.com> wrote:

> I'm running a 520M on my gs, with 2 128K HFS partitions.  I haven't had
> any problem.  When I feel that I need to optimize, I copy the data to
> other partitions, erase the partition, and copy back.  I will usually use
> the Orca shell compress utility to alphabetize the directories while it's
> on a ProDOS partition (so the listing does not have to be alphabetized
> every time by HFS -- one of the reasons it's slower than ProDOS).

HFS physically stores its directories in a B*-tree structure, which
inherently sorts the names, and is a very efficent way of doing so.  The
lack of speed of HFS is not likely to be anything to do with this.

Sorting the filenames first just means that they are entered into the
tree in ascending order, which may be a little quicker than random
order, but I doubt you could measure the difference.

One reason that HFS is slow on the IIgs may be that all of the
multi-byte directory fields are in the wrong order (high byte first), so
the IIgs has to reverse them to get the correct values.  (I don't know
how significant this is.)

The IIgs HFS implementation seems to be doing some kind of calculation
incredibly slowly - whenever I copy a large file to an HFS partition, it
spends ages thinking about it, then quickly writes all the data
(substantially faster than ProDOS, but the initial delay is enough to
make ProDOS faster overall).

HFS also seems to be very slow at copying large numbers of small files.

Someone claimed that the HFS FST is also writing data in reverse order
for multi-block transfers.  This would have a significant speed penalty,
as most drivers and devices are optimised for writes in ascending order.

I haven't verified this behaviour (it would need a hook at the device
driver level to monitor the I/O calls), and it doesn't seem to agree
with the observed timing of HFS writes.

I suspect that the FST is a "bare minimum" implementation, and no
attempt has been made to optimise its disk accesses.

Anyone done a disassembly of it?

-- 
David Empson
dempson@actrix.gen.nz
Snail Mail: P.O. Box 27-103, Wellington, New Zealand