Hey, all. Long time-ish listener, first time caller.

I have a Seagate ST9146802SS SAS drive that was pulled from a RAID. No critical data on it (protected by RAID, have daily backups, etc.), but for the heck of it I'm trying to figure out what, if anything, is actually wrong with it. It's no longer under warranty and I'll probably just end up binning it, but if it has some life left in it and the "failure" mode is not fatal, then I have non-critical tasks that I can certainly put it to use on, and it would be good to know what's really going on so that I can make an informed decision.

So here's the skinny: it's a Dell OEM disk (with Dell firmware), and it was having trouble reading from a couple of contiguous LBAs. I threw a SAS controller (Dell SAS 6/i, LSI LSISAS1068E-based) in a PC with Windows on it and installed the latest SeaTools. I ran a long repair ("Fix All Long") which seemed to work: both generic short and long tests now succeed without any errors whatsoever (even with successive multiple runs of the generic long test: they all pass). It would seem that there were some spare sectors available and the firmware successfully remapped those defective LBAs to them. I should also mention that SMART status of the disk is healthy and has never deviated from that.

The "problem" is that despite the fact that it passes all generic tests and that the disk seems to be completely usable, it fails both the short and long self-tests. Windows SeaTools can only execute short DST so I booted into Linux and interacted with the disk via smartctl. Every time I run either the short DST or long DST, it fails within about 10-15 seconds with SCSI sense key 0x04 (hardware error), ASC/ASCQ 0x3E/0x03. That particular key/ASC/ASCQ combo apparently translates to "LOGICAL UNIT FAILED SELF-TEST" (http://www.t10.org/lists/asc-num.htm#ASC_3E). I'm thinking, "no sh*t, Sherlock." This doesn't really tell me anything that I don't already know. I already know *that* it is failing; *what* is failing during DST and *why* is it failing is what I want to know.

The drive shipped with firmware S206, which I believe to be particular to the Dell drives. Dell has released an update to S22F for this drive (http://www.dell.com/support/home/us/en/2684/Drivers/DriversDetails?driverId=T3G6R&fileId=3287494491), and I thought it might be worth a try to see if this corrects the problem somehow...after all, maybe the DST failure is the result of a bug leading to a false alarm (long shot, I know). The stupid Dell Windows installer refuses to run if you aren't running it from a PowerEdge server (it checks!) and I don't have a spare PowerEdge chassis that I can use to perform drive maintenance like this on, so I had to strip the 256-byte Dell header off of the included FWH file to generate a LOD file that SeaTools would be happy with, so that I could try flashing it with that. SeaTools is happy with the file, does not complain about drive model mismatch, and attempts to flash, but every flash attempt fails with SCSI sense/ASC/ASCQ 0x05/0x26/0x99.

I cannot find a sense qual/subcode of 0x99 under code 0x26 documented anywhere, but I did find language elsewhere that implied that sense key 0x05 usually means that the HBA, not the drive, disliked the command that was sent to it. I dug out a SAS 5/i to use instead but get the same results. I have no other HBAs to test with.

So the question is, is anything *actually* wrong with this drive? Is it actually failing self-test, or is it possible this is a false alarm somehow since everything checks out? Is it possible that I am seeing this weird behavior on account of the adapter I'm using and the drive itself is fine? How can I get more detail about what the DST is griping about?

Thanks so much,

-- Nathan