Alfred Ganz wrote:
> Christian, Doug,
> This is really for Doug, but I have trouble sending to him because
> of a spam avoidance problem.
> Doug wrote:
> > Doug: Looks like the same issue you reported recently for a WD drive
> > with SAT support.
> > Which USB enclosure?
> The USB enclosure that I reported the problem recently with
> is a 250GB WD "My Passport" which a SCSI INQUIRY reports
> as "WD 2500BEV External".
> The unit reports compliance with SPC-2:
> # sg_inq /dev/sg2
> standard INQUIRY:
> PQual=0 Device_type=0 RMB=0 version=0x04 [SPC-2]
> which makes this patch pending for lk 2.6.29:
> I am not sure this is the case, a careful review of the patch seems to
> indicate that the patch also addresses the SPC-2 case, but in a more
> convoluted way. Note that the very first sat,12 or sat,16 command will
> also set the US_FL_SANE_SENSE flag, as will the first sense response
> of type 70h - 73h. Agreed, this is an ugly solution to this mess, and
> the very first smartctl -H command may still fail, but subsequent ones
> should then succeeed.
Interesting, I didn't look past the failed "SPC-2" guard.
However my observation is that the claimed compliance
field in a SCSI response is not something to be taken
seriously when ATA, and especially USB, are involved.
In the case of my "WD Passport" external disk what it returns
beyond by byte 57 in its SCSI INQUIRY response violates
SCSI-2, SPC, SPC-2, SPC-3 and SPC-4. It has a model
information beyond byte 57 ... wrong ... it should have
version descriptors in SPC-2. So much for claiming SPC-2
The "WD Passport" obviously supports the SAT ATA
pass-through commands but does not format its INQUIRY
"T10 Vendor Identification" field according to the SAT
(or draft SAT-2) standard. It should contain "ATA "
but has "WD ". Red card! This means we need
to supply a '-d sat' argument to override the SMT
assumption that it has a "real" SCSI disk.
Now if it had implemented version descriptors
properly (discussed in previous paragraph) then we
might see a compliance claim for SAT and then we
could (but don't) assume a SCSI OS interface to
So I have reason not to trust the external disk (actually
the USB to ATA chip) and the Linux USB mass storage driver.
Do I need to find out which one is the source of my
Life is too short to list all the ways that these devices
break SCSI standards. My goal is not to count the
violations but make things work in smartmontools.
The Rob Elliott T10 proposal (url in previous post) should
indicate that the 18 byte sense buffer truncation is not a
smartmontools/Linux only problem.
That said when I place the same "My Passport" external
disk on XP SP3 and make allowance for the fact that
SAT will not be automatically recognised, for example:
$ smartctl.exe -a -d sat PD1
then it works. So there is a need for '-T permissive'
option in linux (SMT 5.38, lk 2.6.27) but not in Windows
XP SP3. My Windows 2000 laptop has died but I'm pretty sure
that I have noted 18 byte sense buffer truncation there.
Just another point in passing: Western Digital (WD) haven't
made true SCSI (SPI, SAS, FC) disks in a long time (over
10 years). So since "WD " is a registered T10 vendor
identification, then as soon as a disk responds to a
SCSI INQUIRY with that, we might safely assume that the SAT
interface is in play. If it is not (e.g. if WD started
producing SAS disks) then we would find that out after the
first SCSI ATA PASS-THROUGH command failed with "illegal
request; invalid command operation code".
P.S. Alfred Ganz has problems reading my attachments
and I can't even send emails to him:
"Diagnostic-Code: smtp; 550 5.7.1
<alfred-ganz@...>... Sender address