JorgeB

It wouldn't show up on the motherboard bios, only on the HBA bios.

There's a hardware problem somewhere, even SMART can't be read correctly: ATA_READ_LOG_EXT (addr=0x03:0x00, page=0, n=1) failed: scsi error medium or hardware error (serious) Read SMART Extended Comprehensive Error Log failed Read SMART Error Log failed: scsi error medium or hardware error (serious) ATA_READ_LOG_EXT (addr=0x07:0x00, page=0, n=1) failed: scsi error medium or hardware error (serious) Read SMART Extended Self-test Log failed Read SMART Self-test Log failed: scsi error medium or hardware error (serious) Read SMART Selective Self-test Log failed: scsi error medium or hardware error (serious) Are you sure the tape is working correctly? Do you have a molex to STA adapter? If yes use that.

There were read errors on disk4 early on the rebuild, so rebuilt disk will be mostly corrupt, this looks like one of the typical SASLP problems, but since disk4 dropped offline there's no SMART, reboot/power cycle server to see if disk4 comes back online then post SMART report, avoid starting the array for now.

Look at SMART data, if all is normal do a read test using for example the diskspeed docker to confirm speeds are normal, that should be enough, SSDs don't usually fail like disks, i.e., by developing bad sectors, though there are exceptions, they usually completely fail after a reboot/power cycle, and you can't test for that.

It can't be the OS. Those would be the next things to try.

Yep, max SATA cable length is 1m total, though if it was working before kind of strange now having issue with all disks, it could still be a cable gone bad. Yes, but only between two SAS devices, e.g. between an HBA and a SAS expander, then 1 meter to SATA disks.

The easiest way to troubleshoot this would be to connect one of the disks directly to the HBA on the server, if it works the enclosure it's likely as enclosure problem, if it still doesn't connect to the onboard SATA controller, if it works the HBA/cables is likely the problem.

Please continue discussion on the existing thread, I already replied there.

The disk are connected, the problem is that they are not being initialized correctly and then Unraid has issues identifying them: Feb 4 20:12:51 Tower emhttpd: device /dev/sdd problem getting id Feb 4 20:12:51 Tower emhttpd: device /dev/sdb problem getting id Feb 4 20:12:51 Tower emhttpd: device /dev/sdc problem getting id What kind of enclosure are you using, does it have an expander or controller or is it SAS direct connect?

Stress testing an SSD with preclear is kind of pointless IHMO.

It's still unnecessary, you can use blkdiscard to completely wipe an SSD in a couple of seconds tops. blkdiscard /dev/sdX

No.

2TB disk has a single CRC error, that's not a disk problem, connection issue, but a single error is nothing to worry about just acknowledge current SMART attributes by clicking on the thumbs down. 1TB has a few reallocated sectors, likely also nothing to worry about for now, especially if they are old, acknowledge and keep an eye on it.

Serial number https://wiki.unraid.net/Replacing_a_Data_Drive

It's fine assuming it was a single device cache and there's no "all data on device device will be deleted at array start" or similar warning in front of it.

LSI has a BIOS flashed, if that's not appearing during boot you likely have "Option ROM" or similar disabled in the board bios for that slot.

There are some btrfs recovery options here.

https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=781601

Most likely a controller compatibility or cable issue, hence why I suggested using a different controller, see how it behaves there, UDMA CRC errors are a connection issue, not a device problem.

Not the array itself, what you can have is a big raid cache pool and work mainly there, that's what I do for one of my servers.

Problems with the cache device: Feb 5 11:21:11 Tower kernel: sd 13:0:2:0: Power-on or device reset occurred Feb 5 11:21:11 Tower kernel: mpt2sas_cm0: log_info(0x31120303): originator(PL), code(0x12), sub_code(0x0303) ### [PREVIOUS LINE REPEATED 5 TIMES] ### Feb 5 11:21:11 Tower kernel: sd 13:0:2:0: [sdf] tag#175 UNKNOWN(0x2003) Result: hostbyte=0x0b driverbyte=0x00 Feb 5 11:21:11 Tower kernel: sd 13:0:2:0: [sdf] tag#175 CDB: opcode=0x2a 2a 00 00 00 b7 c0 00 00 40 00 Feb 5 11:21:11 Tower kernel: print_req_error: I/O error, dev sdf, sector 47040 Feb 5 11:21:11 Tower kernel: BTRFS error (device sdf1): bdev /dev/sdf1 errs: wr 3, rd 0, flush 0, corrupt 0, gen 0 Feb 5 11:21:11 Tower kernel: BTRFS error (device sdf1): bdev /dev/sdf1 errs: wr 4, rd 0, flush 0, corrupt 0, gen 0 Feb 5 11:21:11 Tower kernel: mpt2sas_cm0: log_info(0x31120303): originator(PL), code(0x12), sub_code(0x0303) ### [PREVIOUS LINE REPEATED 1 TIMES] ### Feb 5 11:21:12 Tower kernel: sd 13:0:2:0: Power-on or device reset occurred Feb 5 11:21:12 Tower kernel: mpt2sas_cm0: log_info(0x31120303): originator(PL), code(0x12), sub_code(0x0303) ### [PREVIOUS LINE REPEATED 7 TIMES] ### Feb 5 11:21:13 Tower kernel: mpt2sas_cm0: log_info(0x31111000): originator(PL), code(0x11), sub_code(0x1000) ### [PREVIOUS LINE REPEATED 2 TIMES] ### Feb 5 11:21:13 Tower kernel: sd 13:0:2:0: [sdf] tag#184 UNKNOWN(0x2003) Result: hostbyte=0x0b driverbyte=0x00 Feb 5 11:21:13 Tower kernel: sd 13:0:2:0: [sdf] tag#184 CDB: opcode=0x2a 2a 00 00 29 86 40 00 00 20 00 Feb 5 11:21:13 Tower kernel: print_req_error: I/O error, dev sdf, sector 2721344 Try it on a different controller.

Don't know, never used it, try uninstalling it and see.

You can check if there's a different doing the test on a disk share, user shares are known to add some overhead, some performance degradation is expected. Enable disk shares (Settings -> Global Share settings) then repeat the test on \\tower\disk1 or \\tower\cache E.g. this is me doing the same transfer to an user share vs disk share:

Config folder.

Ahh, saw that but never imagined that would cause problems.