On Sat, 12 Sep 2009, Eric Schrock wrote:

> Also, were you ever able to get this disk behind a SAS transport (X4540,
> J4400, J4500, etc)?  It would be interesting to see how hardware SATL
> deals with this invalid data.  Output from 'smartctl -d sat' and
> 'smartctl -d scsi' on such a system would show both the ATA data and the
> translated SCSI data.  My guess is that it just gives up at the first
> invalid version record, something we should probably be doing.

Phil Steinbachs gave you some data from an X25-E in a J4400 attached to an
X4240 via an LSI 1068E based HBA, as well as one in one of the X4240's SAS
slots connected to the internal Adaptec RAID controller:




Your last email on the subject was:


in which you said:

"The primary thing is that this drive is completely busted - it's reporting
totally invalid data in response to the ATA READ EXT LOG command for log
0x07 (Extended SMART self-test log).  The spec defines that byte 0 must be
0x1 and that byte 1 is reserved."

Phil might still be in a position to run smartctl on the drives if you're
still interested in the data.

I guess this is why you're now saying the drive is returning invalid data,
I had forgotten the details, that was almost three months ago.

In any case, I agree with you that the firmware is buggy; however I
disagree with you as to the outcome of that bug. The drive is not returning
random garbage, it has *one* byte wrong. Other than that all of the data
seems ok, at least to my inexpert eyes. smartctl under Linux issues a
warning about that invalid byte and reports everything else ok. Solaris on
an x4500 evidentally barfs over that invalid byte and returns garbage.

Overall, I think the Linux approach seems more useful. Be strict in what
you generate, and lenient in what you accept ;), or something like that. As
I already said, it would be really really nice if the Solaris driver could
be fixed to be a little more forgiving and deal better with the drive, but
I've got no expectation that it should be done. But it could be :).

Thanks again for your help. I apologize if I've been a bit antagonistic, I
tend to go "dog with a bone" when I start debating something.

Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  hen...@csupomona.edu
California State Polytechnic University  |  Pomona CA 91768
zfs-discuss mailing list

Reply via email to