HFS Intentionally Slow?

[neiderma@eden.rutgers.edu (Kid)]

Here's a message I pulled from a GEnie message base archive.  Perhaps
someone from Apple, Inc. (or a knowledgeable from outside Apple)
can comment on the below?
                         ______________________________
 
 (I think now I know why we don't like the HFS file system translator!
 It's just because he doesn't like IIGS users.)
 
 I still can't believe that it's true, but I think will have to.
 
 The HFS FST does weird things when _writing_ to a (disk?) volume:
 
 - it constantly issuses redundant status calls to the GS/OS driver while
 updating the data structures on the volume.
 
 - it's a piece of software written in a high-level language (this is
 the old story of assembly language speed)
 
 - while doing the mass data transfer, it _exclusively_ issuses SINGLE BLOCK
 (SINGLE!!!) write requests to GS/OS.
 
 - while doing the mass data transfer, it writes blocks in REVERSE
 (REVERSE!!!) order, eg.  blocks 200...300 are transferred in the order 300,
 299, 298, 297, ......, 200. No chance for a driver to speedup things.
 
 If you have a little insight in what's going on if the HFS FST does its
 work, you may figure out that almost _EVERYTHING_ has been done by the
 programmer to let the FST work as _slowly_ as possible. I only can assume
 that this has been done intentionally! Thank you, whoever may have written
 this piece of software.
 
 Joachim
 
 (if somebody is interested in doing some snOOping, I'm willing to upload an
 experimental BlueDisk driver. If you have enough skills working with a
 GS/OS driver and GSBug you can verify what I have told you right now)