SCSI emulator

Ethan Dicks ethan.dicks at gmail.com
Fri Nov 5 12:43:27 CDT 2010


On 11/5/10, Alexandre Souza - Listas <pu1bzz.listas at gmail.com> wrote:
>>   Preserving/snapshotting the contents of a SCSI drive is as simple as
>> hooking it to a UNIX box and running a "dd" command.
>
>     It preserves any strange formatting? I realize I have ABSOLUTELY NO IDEA
> of the low level workings of SCSI devices...

As I mentioned in my recent reply to this thread, most of the time
(nearly all of the time for stuff we on this list are likely to be
working with these days), there is no strange formatting that's
relevant.  Long ago, we used to worry about what cylinder filesystems
started on and optimizing things for head switching vs track stepping,
but embedded SCSI (and IDE) drives hid so many of those details (and
in many cases interposed a large on-board RAM cache) from the host
that the art of tuning filesystems by position.  The blocks themselves
are nearly always formatted to 512 bytes per block (though in the
earliest days, 256 bytes per block was not unknown), and the blocks
can be just read out sequentially starting with 0000000 (which is
something 'dd' is exceptionally good at).  Another thing that changed
was handling bad blocks on the disk - now, it's all hidden behind the
scenes so that your OS "sees" a field of good blocks (previously, it
wasn't unusual to have the OS-level driver participate in the sparing
mechanism for using unallocated blocks/tracks to replace bad ones, or
at least have a way to ignore bad spots - DOS floppies are a good
example of that).

Drives with analog cables to distinct read/write electronics are a
different matter, but that's exactly what went away when the world
turned to embedded-controller drives.  You have a I/O-bus-like
interface directly to the drive (digital data bus of 8 or 16 or more
bits, handshaking, virtual I/O registers to read/write, a packet-like
command structure, etc) that is from the view of the driver
essentially identical to talking to an older-style controller card
with detached drives.

That's why 'dd' handles so many cases - you are just slurping
sequential blocks from the media - you don't have to worry about head
and track details, about vectoring off for bad blocks - a "perfect"
disk image (until things start to go bad, then they go really bad,
really fast).

Hopefully this helps illuminate the arrangement some.

-ethan



More information about the cctech mailing list