Archiving workstation hard drives

Jules Richardson julesrichardsonuk at
Mon Jan 22 05:22:40 CST 2007

der Mouse wrote:
>>> Last time I looked, NetBSD, at least, couldn't do anything sensible
>>> with a SCSI disk with other than 512-byte blocks.  That was quite a
>>> while ago, but I haven't heard anything on the lists to make me
>>> think the status has changed.
>> The thing that got me wondering though - surely in the PC world, SCSI
>> CDROM drives all use something like 2048-byte blocks?
> Yes.  If you have a 2048-byte-sector disk and can convince the cd
> driver to attach to it instead of the sd driver, it might work. :-)

Hmm, I'm not quite sure what you're getting at there - but I've never had any 
problems whatsoever with Linux's SCSI CDROM / DVD-ROM support. I've never 
poked deeply enough in the code though to see what's going on behind the scenes.

 From what Brad said and what I found in sd.c, it looks like disks at least 
support powers-of-2 raw sector sizes between 256 and 4096 bytes; any problems 
dealing with those drives are either down to SCSI incompatibilities (SASI 
devices and/or not-quite-complete device firmware support), incorrect setup 
(device needs some vendor-specific voodoo to work), or in trying to impose a 
filesystem on the device which is expecting a specific block size.

> The suggestion of using whatever generic SCSI facilities are available
> strikes me as a good one.  If I had the time and interest I'd hack
> something together myself to do that.

Using Linux's sg interface to throw raw SCSI commands around is easy enough; I 
wrote a userspace driver to do some data archival via a SCSI floppy controller 
not so long ago.

However, the problem is that for old devices, they often not quite 
SCSI-compliant which upsets the HBA drivers themselves; Linux chokes on 
anything that doesn't support Inquiry, for instance - which results in the 
kernel not giving you a sg device handle to work with for such a device. It 
would seem that (from Al's example) the Mac is perhaps a bit better, in that 
you can throw a command at any SCSI device on the bus whether the OS thinks 
there's one there or not.

To get oddball SCSI devices going, what's almost needed is a way of 
intercepting the kernel boot process such that the user can send a few 
vendor-specific setup commands, fake Inquiry data etc. between HBA driver load 
and subsequent kernel querying of attached devices. One the kernel thinks 
there's a valid device there it'll give you a sg handle to it and you can do 
whatever you like. As I recall that's how the Linux OMTI bridge drivers worked 
(they were before the days of sg, but allowed the board to appear as a two-LUN 
disk device to the HBA driver), but unfortunately the kernel's changed beyond 
all recognition since those patches were current.

There is of course the additional problem that a lot of vintage equipment's 
actually SASI rather than SCSI, and Linux HBA drivers probably won't cope with 
that (even if there's just the HBA and SASI device on the bus). I haven't 
tried though because it's a lost cause without some way of faking Inquiry data 
anyway :-)

What I'd really like I suppose is a user-space driver for a widget that 
provided SCSI and SASI support via a *totally* dumb HBA (i.e. polled I/O and 
twiddling of bus lines "directly") - in other words, one step less intelligent 
still than most "dumb" HBAs (which still use some sort of SCSI IC). It'd be 
slow as molasses, but speed isn't the critical factor compared to flexibility 
and ease of driving.

Unfortunately a PC parallel port doesn't quite have enough I/O lines, I 
wouldn't have a clue how to make a USB solution (ick!), and building an ISA 
card (say) would require kernel drivers (and all the complexity involved 
there). One possibility is just to use two parallel ports, but that severely 
limits the portability of the device - although I'm getting to the point where 
that's preferable to not having any solution at all.



More information about the cctalk mailing list