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

[toddpw@chop.ugcs.caltech.edu (Todd P. Whitesel)]

sbehrens@contech.demon.co.uk (Soenke Behrens) 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.

You're missing something; there's no requirement that the RamFAST send the
commands straight through. It could easily merge them -- which it certainly
does for single-block forward writes, because that's what P8 needs. Whether
it does this for backwards writes or not I don't know. (Maybe Jawaid does)

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

Agreed.

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

I think it is probably some idiocy in how it scans the B+ tree.

Fortunately there's a really easy way to find out where it's spending all
its time. Film at 11.

Todd Whitesel
toddpw @ ugcs.caltech.edu