5 Nov
2010
5 Nov
'10
1 p.m.
Dave McGuire wrote:
Hmm, that's good to know. I'm hoping to get all my stuff moved here toward the
start of next year, so maybe I can find a spare system and have a mess around
with that then...
cheers
Jules
On 11/5/10 2:00 PM, Jules Richardson wrote:
I think the Adaptec was one of the most sane boards out there - IIRC it stores
the drive geometry on block zero of the drive at format time, then at power-on
fetches that block back and initialises itself with the loaded geometry. I
can't remember if it just hides the first block from the user, or hides the
whole track.
I think the board responds to Inquiry, too (although it just returns "ACB
4000" rather than anything to do with the geometry of the attached drives)
I've not played with the Emulex boards - I think the only ones I have are tape
bridges rather than disk.
The Xebec and Omti boards seemed reliable, but their SCSI implementations were
a little lacking (one of them I think had the option of a user-supplied ROM
with the expected disk geometry encoded into it, but it still wasn't "SCSI
enough" to work with a modern system)
It's a bit more murky than that (albeit a
related issue) because a lot
of the bridge boards expect a vendor-specific command to tell them the
drive geometry of the attached drive, and there's no opportunity for the
system drivers to inject the necessary command.
MFM- or ESDI-to-SCSI bridge boards (Adaptec ACB-4000, Emulex MD21 if
memory serves) are weird to begin with, but I've not had any trouble
using dd to image drives through them. (the drives they were formatted
and used with) I did have a
look at adding such a facility to Linux a few years ago -
kind of "at init, consult list and throw these params at device xxx via
vendor command yyy" - but looking at the spaghetti that is the Linux
kernel source is probably what gave me so many grey hairs ;-)
NetBSD has a SCSI "quirks table" in the kernel that can be used for
this purpose. (and a driver structure that isn't spaghetti)