Could someone tell me what is wrong with this disk?

ST3000DM001-1ER166_Z501QERG-20160630-1619.txt

Could someone tell me what is wrong with this disk?

Drive looks fine.  Unfortunately, no real way to tell what happened unless you haven't restarted the server yet and can post diagnostics.

 

But, with 52 CRC errors (over 949 hours = 1 / 18 hours or 1 every 9 hours while the drive is actually running), its possible that you had a cabling issue that caused the drive to fail a write and then become disabled

 

I can post diagnostics, if there is nothing wrong with the drive how do I get it to come back online?

stop array, set the disk to be unassigned. start the array.  stop the array.  reassign the disk.  start the array.  A rebuild will commence.

attached diagnostics

tower-diagnostics-20160630-2141.zip

Never exactly seen these errors, but my best guess is still a loose / bad cable.

 

Jun 30 15:48:53 Tower kernel: sd 1:0:1:0: [sde] tag#0 CDB: opcode=0x8a 8a 00 00 00 00 00 ae cd f9 60 00 00 04 00 00 00
Jun 30 15:48:53 Tower kernel: mpt2sas_cm0: 	sas_address(0x4433221102000000), phy(2)
Jun 30 15:48:53 Tower kernel: mpt2sas_cm0: 	enclosure_logical_id(0x500605b003dbce20),slot(1)
Jun 30 15:48:53 Tower kernel: mpt2sas_cm0: 	handle(0x000a), ioc_status(success)(0x0000), smid(3)
Jun 30 15:48:53 Tower kernel: mpt2sas_cm0: 	request_len(524288), underflow(524288), resid(524288)
Jun 30 15:48:53 Tower kernel: mpt2sas_cm0: 	tag(65535), transfer_count(0), sc->result(0x00000000)
Jun 30 15:48:53 Tower kernel: mpt2sas_cm0: 	scsi_status(check condition)(0x02), scsi_state(autosense valid )(0x01)
Jun 30 15:48:53 Tower kernel: mpt2sas_cm0: 	[sense_key,asc,ascq]: [0x06,0x29,0x00], count(18)
Jun 30 15:48:53 Tower kernel: mpt2sas_cm0: log_info(0x31120303): originator(PL), code(0x12), sub_code(0x0303)
Jun 30 15:48:53 Tower kernel: sd 1:0:1:0: [sde] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x0b driverbyte=0x00
Jun 30 15:48:53 Tower kernel: sd 1:0:1:0: [sde] tag#0 CDB: opcode=0x8a 8a 00 00 00 00 00 ae cd f9 60 00 00 04 00 00 00
Jun 30 15:48:53 Tower kernel: blk_update_request: I/O error, dev sde, sector 2932734304

I REALLY dislike the mpt2sas module, at least from a troubleshooting perspective.  The developers and/or company behind it have chosen to remain cryptic and unhelpful, not even releasing error code tables, to help interpret what's happened, what's wrong.

 

In this case, I don't think this is a cable problem, although as Squid noted there *have* been cable problems in its short past.  Cable issues are random and inconsistent, and this is only too consistent.  Plus communication issues don't usually fail reads and writes, they're retried until successful or given up.  In this case, the writes are failed immediately, no timeouts, so it's not the drive failing them.  There appears to be a half second pause per logging set, but no pausing for the write failures.  As noted above, SMART looks great, so it's not the drive, it's the controller but it's decided to keep the problem a secret.

 

What's especially odd is these clusters of writes occur at the start of the mounting, before it's even complete.  Why would you want to write so much before the drive is even fully mounted?  Perhaps trying to clear journaling space?

 

For whatever reason though, the controller denied the writes, and that was fatal, with unRAID disabling the drive on the very first write failure.  Since the drive wasn't mounted, and if nothing else was written to the emulated drive, you should be able to re-enable the drive without rebuilding it.  It would still be good to do a parity check though, just in case.

I REALLY dislike the mpt2sas module, at least from a troubleshooting perspective

 

I have an IBM M1015 card, i don't think there is any other option to flash it to IT mode?\

 

For whatever reason though, the controller denied the writes, and that was fatal, with unRAID disabling the drive on the very first write failure.  Since the drive wasn't mounted, and if nothing else was written to the emulated drive, you should be able to re-enable the drive without rebuilding it.  It would still be good to do a parity check though, just in case.

 

I tried stopping the array unassigning the drive, restarting the array, stopping the array re-assigning the drive and the starting the array but i still didn't like the disk so i just performed a data rebuild on a disk i had spare and everything seems to be working now.

 

I must admit those errors are annoying me, obviously they are not consistent with other people who are using IBM M1015 cards.