5 Nov
2010
5 Nov
'10
10:53 a.m.
At 12:43 PM 11/5/2010, you wrote:
Maybe - but I've found an awful lot of old systems
and devices that are a bit flakey when it comes to their SCSI implementations (not to
mention things which send vendor-specific commands for control and setup); personally I
think I'd rather have the transfer in "user-land" than try to seamlessly
integrate it with a modern protocol.
All you need to do is incorporate the blood sacrifice into the FPGA.
That's the way we fixed SCSI issues in the old days.
I get the impression (possibly wrong!) that something
like iSCSI (and a back-end PC making use of it) might get tripped up by some vintage
systems, but something doing the interpretation in user-space could easily be coded to
cope.
The advantage would be that there are iSCSI devices and implementations
already out there. There are downloadable VMware appliances to handle it,
which makes the contemporary end a snap.
I think there'd be a reasonably big market for a USB breakout device
of some kind. I've tried several USB to IDE/SATA gizmos on dozens of
semi-flakey drives, and WinXP tends to go into la-la land if the
USB side isn't responding the way it should (which it'll do if the
hard drive isn't responding the way it should.)
I'd pay $200-300 for a device that would show me in great detail
what's wrong, allow for a write-protect to keep Windows from writing
to it, and/or allow me some alternative methods of getting to the
drive's data. Sounds almost like some forensic recovery devices,
but with more debugging output.
Same for old SCSI, no? Somewhere in my junk piles I have a SCSI
pass-through board with an LCD display that showed a count of
blocks read/written. Why not more info?
- John