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

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

Hi,

posted on David Empson's behalf.

Soenke

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:
> Hi,
> 
> 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 would have posted this, but my host's news server's disk is full at
the moment... AGAIN!  You are welcome to post this on my behalf.]

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).

Copying to a ProDOS disk is regular but slow (about 600 KB per second
on average with a large file).

> 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.

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.

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).

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....

-- 
David Empson
dempson@actrix.gen.nz
Snail mail: P.O. Box 27-103, Wellington, New Zealand
--
I don't know what it is he's doing, it must be art