And if the drive is IDE, and the USB or Firewire is providing an IDE
interface, why doesn't it work?
There is a hint on this page. It basically has to do with how
"transparent" the bridge chip is, within the enclosure, and
whether the protocols being used, have extensions to allow
the S.M.A.R.T command to pass. The bridge basically only
has to support "read" and "write", to be considered a success.
The SCSI command set is frequently used to talk to non-ATA
storage devices, and so both the hardware devices and SCSI
command interface, need to have the same commands as exist on
an ATA device.
*******
http://smartmontools.sourceforge.net/smartmontools_scsi.html
SCSI disks
What is a SCSI disk? A SCSI disk is a storage device that "talks" the
SCSI command set. An ATA disk is a storage device that "talks" the ATA
command set. That seems pretty clear. However by the time an operating
system sees the device the situation can be more complicated.
The ATA command set is used over native ATA transports which are parallel
ATA (PATA) up to 133 MB/sec and serial ATA (SATA) up to 1.5 Gbps
(approximately 150 MB/sec). In the past when ATA disks needed to use some
other transport (e.g. USB and IEEE1394) the SCSI command set was sent
over the foreign transport. So in this case the operating system sees
a device "talking" the SCSI command set but the device is really an ATA
disk. Many current disk external enclosures contains ATA disks yet seen
from the operating systems view point are USB mass storage devices talking
the SCSI command set.
The SCSI command set is used over various transports: the SCSI Parallel
Interface (SPI), Fibre Channel (FCP), Serial Attached SCSI (SAS), IEEE1394
(SBP) and USB (mass storage). Many of these transports can convey multiple
command sets (i.e. not just the SCSI command set). The forthcoming SAS
transport is interesting as it can convey both the SCSI and ATA command
sets. There is also the case of a RAID made up of ATA disks which
communicates to host operating system with the SCSI command set (e.g.
3ware RAID controller).
So what does all this mean for smartmontools? In most cases the answer
is not good news. Devices such as USB external disk enclosures translate
incoming (from the host) SCSI commands to their ATA equivalents and
process responses as required. This translation is limited typically to
a small number of SCSI commands (e.g. READ and WRITE) but not those
commands needed by smartmontools. The author does not know of any
SCSI_over_USB devices that support Smartmontools. The 3ware RAID (6000,
7000 and 8000 series Escalade) controllers are supported on several
operating systems with special code. [1]
SMART
SMART never attained the status of "standard" and its original documents
have been withdrawn. Its catchy name lives on, especially on vendors'
web sites and obviously in the name of this toolset. Luckily the good
ideas in SMART have been incorporated into the ATA and SCSI standards
albeit in slightly different forms.
Initially SMART began on SCSI disks as vendor specific extensions.
Gradually the SMART functionality has moved into the standards (often
by other names) and vendors are improving their standards' compliance.
[In the vendors' defence some of the "standards" are drafts and are yet
to be ratified.] Some SCSI disk vendors have product manuals (available
on the net) that cover the parts of the SCSI command set that their disk
supports. Some of these manuals fill in details that are left deliberately
vague in the the standards. [2]
SCSI standards (found at
www.t10.org ) only make one footnote reference
to the term SMART. Instead the awkward term "Informational Exceptions"
is used. For SCSI tapes the term "TapeAlert" is used.
*******
Paul
