Re: Patch for **MAJOR** HFS.FST Bug

[sbehrens@contech.demon.co.uk (Soenke Behrens)]

>From: David Empson <David.Empson@actrix.gen.nz>
>Date: Wed, 13 Dec 1995 19:31:08 +1300
>
>In article <30cb7c6d.160930@news.demon.co.uk> you write:
>> now that HFS is stable, I'm wondering about its other short-coming: It
>> is excruciantingly slow. According to Joachim Lange (of BlueDisk
>> fame), one of the main reasons for this is that the HFS FST writes
>> blocks _backwards_ on a Multi-Block Write Request.
>
>I find that hard to believe, and it may be a red herring (see below).
>
>The HFS FST seems to actually read and write data _very_ quickly -
>must faster than ProDOS.  The catch is that it seems to take an
>excruciatingly long time to work out what/where it wants to write.
>
>This is most obvious when copying files.  When writing to an HFS disk,
>there is a long pause (longer as the file gets larger) followed
>by a rapid disk access.  With a SyQuest (or any other drive with
>clearly audible stepping) it is easy to hear the speed of the write,
>as
>the head is stepping very fast.  The actual transfer rate approached 1
>MB per second when I last timed it (on my Apple High-Speed SCSI card).

Hmm, interesting. Can someone think of a way to verify this either
way? Only thing I can come up with is to have the device driver output
the block number for read/write requests. Not really feasible if you
don't have the code for the driver, though.
On second thought ... couldn't you put a watch on the appropriate
DLevel call with GSBug and look at things? I'd try it if my GS was up
and running. That way, we could know for certain what's going on.

>> That, obviously, means you lose a lot of speed: After each written
>> block, you have to wait a revolution before the next one comes around.
>> There goes all your clever interleaving.
>
>Who uses interleaving these days?  Most modern SCSI drives use track
>caching and ignore any interleave specified when formatting.  For
>these drives, writing "backwards" would not be a problem - there may
>be a delay after writing the first sector, but by the time the disk
>had revolved again, the rest of the sectors for that track should be
>available.

Well, most SCSI drives nowadays use a 1:1 interleave. Writing
backwards would, however, still be a problem. Let me elaborate:

1) Write Request for block 10 comes in
2) Drive waits for block 10 to come under the head, writes.
3) Write Request for block 9 comes in.
4) Drive waits for block 9 to come under the head, writes.

Why this way? Remember that the RamFAST is not a SCSI initiator. There
is absolutely _no_ way that you can have Command Queuing without
Disconnect/Reconnect. In other words, the drive will not accept
another command before it has not completed the previous command
sequence.

I might be wrong on that, if you wish to prove me wrong, please go
ahead. Let's assume for the moment the drive _could_ take several
commands without having completed the first command, then you get:

1) Write Request for block 10 comes in, block 10 still way off
2) Write Request for block 9 comes in.
3) Drive waits for block 10 to come under the head, writes.
4) Drive waits for block 9 to come under the head, writes.

Why are steps 3) and 4) not exchanged, I hear you say? If they were to
be, you would need a feature called "Tagged Command Queuing" (TCQ for
short) which will "resort" commands such that they can be fulfilled
quickly, and then return status information in the right order. TCQ is
not used on the RF: You would need, again, Disconnect/Reconnect, the
driver would have to tell the drive to enable TCQ (disabled by
default), and the drive would have to support TCQ in the first place.
To give you an idea how rare TCQ still is these days: Conner drives
support it. But quite a number of Conner drives also got it wrong in
_shipping_ microcode versions, versions that shipped for quite a time.
Simply noone actually _used_ TCQ. Only when customers started enabling
TCQ on OS/2 or NT did we see the bugs in the code.

>Assuming the HFS FST does write backwards, there would be additional
>overheads because a separate SCSI WRITE command would have to be sent
>for each block.

That as well, yeah.

>In practise, I don't think this is an issue - I certainly haven't
>noticed any slow disk I/O with HFS on any of my hard drives (two
>Quantums with track caching and one SyQuest 44 of unknown behaviour).

Dunno. As I said, the information comes from Joachim, who wondered why
HFS was so painstakingly slow on his BlueDisk. The answer he came up
with was: It writes backwards. So now we have two opinions: One says
it writes backwards, one says it writes forwards. Some proof either
way would be nice.

>The real killer is the long time taken by the FST before the write.
>
>Of course, it might be taking this time to set up a huge table of
>write commands for each block....

You never know ... it might just be doing that. Or it's thinking real
hard about its B+ tree. Or both. Or both _and_ it counts electronic
sheep because it was first written for a PowerMac and has the Magical
Miracle Delay Routines in (see previous post) :).

Soenke
--
I don't know what it is he's doing, it must be art