[rescue] IDE SSDs? I never knew...

[Dave McGuire]

On 6/28/24 10:04, Jonathan Chapman via rescue wrote:
>> Another is that they don't talk directly to the hardware; they speak
>> some other disk interface protocol, such as SATA, out the other side.
> 
> Moreover, they are often talking to something FAT32 formatted, and storing the SCSI targets as files. They can also be CD-ROMs, Ethernet adapters, etc.
> 
> Compare to an ACARD SCSI to IDE [to SATA] bridge, where you talk to the disk 1:1 w.r.t. blocks. Those are closer to a host interface bridge, IMO. More like a HVD <-> LVD bridge than whatever you want to call the modern iterations.
> 
> I think calling something like the BlueSCSI, ZuluSCSI, SCSI2SD, etc. an "emulator" is probably not wrong.

   Most if not all SCSI hard drives have a processor on them, frequently 
an i80186 or an Hitachi SuperH.  What gets stored on the platters is 
completely opaque, and in many cases contains error control information, 
block remapping data, etc etc, i.e. a lot more than end-user data. 
There may be some form of filesystem involved, who knows?  But even that 
term has a loose definition.

   The interface to the platters is something very different from SCSI. 
Somewhere there's a dividing line between "analog" and "digital", but 
the line where it becomes "SCSI" is a good bit further in the same 
direction.  Nearly all SCSI hard drives store data in an RLL format. 
The SCSI layer is unaware of it.

   My point is, there's always stuff going on under the hood.  The 
difference here is that with a ZuluSCSI or similar, we can see what's 
under the hood.  So it's an SD card, something that we recognize as 
being also available for other applications.  Does that make the whole 
assemblage an "emulator"?  No.  It's not emulating a SCSI mass storage 
device, it IS a SCSI mass storage device.  Not an emulation, but an 
implementation.

                -Dave

-- 
Dave McGuire, AK4HZ
New Kensington, PA