JorgeB

I believe it's a bug, i.e., when a custom SMART controller is set it's not used to get the GUI temps.

You can run a SMART test, but the errors happened in multiple devices, which again suggests not a specific device problem: Mar 7 12:18:24 Tower kernel: sd 7:0:0:0: [sdb] tag#520 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x00 Mar 7 12:18:24 Tower kernel: sd 7:0:0:0: [sdb] tag#520 CDB: opcode=0x88 88 00 00 00 00 02 ba a0 f4 00 00 00 00 08 00 00 Mar 7 12:18:24 Tower kernel: print_req_error: I/O error, dev sdb, sector 11721044992 Mar 7 12:18:25 Tower kernel: sd 7:0:2:0: Power-on or device reset occurred Mar 7 12:18:25 Tower kernel: mdcmd (1379): spindown 7 Mar 7 12:18:25 Tower dhcpcd[1569]: eth0: leased 192.168.0.16 for 604800 seconds Mar 7 12:18:25 Tower avahi-daemon[7808]: Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.0.16. Mar 7 12:18:25 Tower avahi-daemon[7808]: New relevant interface eth0.IPv4 for mDNS. Mar 7 12:18:25 Tower dhcpcd[1569]: eth0: adding route to 192.168.0.0/24 Mar 7 12:18:25 Tower dhcpcd[1569]: eth0: adding default route via 192.168.0.1 Mar 7 12:18:25 Tower avahi-daemon[7808]: Registering new address record for 192.168.0.16 on eth0.IPv4. Mar 7 12:18:27 Tower ntpd[1630]: Listen normally on 19 eth0 192.168.0.16:123 Mar 7 12:18:27 Tower ntpd[1630]: new interface(s) found: waking up resolver Mar 7 12:18:31 Tower kernel: sd 7:0:2:0: [sdd] tag#514 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x00 Mar 7 12:18:31 Tower kernel: sd 7:0:2:0: [sdd] tag#514 CDB: opcode=0x88 88 00 00 00 00 02 ba a0 f4 00 00 00 00 08 00 00 Mar 7 12:18:31 Tower kernel: print_req_error: I/O error, dev sdd, sector 11721044992 Mar 7 12:18:31 Tower kernel: sd 7:0:5:0: Power-on or device reset occurred Mar 7 12:18:32 Tower kernel: mdcmd (1380): spindown 8 Mar 7 12:18:32 Tower kernel: mdcmd (1381): spindown 9 Mar 7 12:18:39 Tower kernel: sd 7:0:5:0: [sdg] tag#517 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x00 Mar 7 12:18:39 Tower kernel: sd 7:0:5:0: [sdg] tag#517 CDB: opcode=0x88 88 00 00 00 00 01 d1 bf be 00 00 00 00 08 00 00 Mar 7 12:18:39 Tower kernel: print_req_error: I/O error, dev sdg, sector 7813971456 Mar 7 12:18:39 Tower kernel: sd 7:0:3:0: Power-on or device reset occurred Mar 7 12:18:48 Tower kernel: sd 7:0:3:0: [sde] tag#520 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x00 Mar 7 12:18:48 Tower kernel: sd 7:0:3:0: [sde] tag#520 CDB: opcode=0x88 88 00 00 00 00 02 ba a0 f4 00 00 00 00 08 00 00 Mar 7 12:18:48 Tower kernel: print_req_error: I/O error, dev sde, sector 11721044992

The linked thread is the FAQ, not for support, please start a new thread on the general support forum if needed.

Yes, looks fine.

That's a strong possibility.

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

Can you try adding a different device, even a regular HDD if you don't have another SSD, just to see if there's any difference.

By typing

There are errors from the LSI HBA right from the beginning, you'll need to try a different HBA.

I still don't see any errors, or why it's failing to add, try wiping the device before adding back again, check cache2 is still sdf, and after: stop array unassign cache2 start array run: blkdiscard /dev/sdf If no errors continue: stop array re-assign cache2 start array

I don't see why on the syslog, but for some reason the second device wasn't added to the pool, it should be if you try again, just make sure cache backups are up date in case something goes wrong, then: stop array unassign cache2 start array stop array re-assign cache2 start array and hopefully it will work now.

Good to run iperf first to rule out any network issue.

LSI controllers in some cases generate a few errors when waking up from sleep and/or spinning up some devices, they look harmless.

Run an extended SMART test and if OK monitor for now, a few reallocated sectors can be OK, especially if the number remains stable.

I don't use MacOS, but if you google MAC slow SMB you'll find a lot of results, and might find something that helps.

I don't know of any other way, you'd need to rebuild the superblocks, you can try asking for help on #btrfs on IRC or the btrfs mailing list.

Cache2, is not part of the pool, please post the diagnostics: Tools -> Diagnostics

Marvell controllers are strongly discouraged, both devices (ATA9 and ATA12), are using one.

You need to update the LSI firmware to latest, 20.00.07.00, the one you're using has known issue, including generating a lot of UDMA CRC errors, which are likely the SMART warnings you're seeing.

Did you do what I asked? Those diags still have an incomplete syslog.

It's still only the same error repeated many times, reboot, wait a couple of minutes and grab new diags.

Agree, but I would like to see the syslog since boot, it's missing a lot.

Also, if using the cache device, try transferring directly to the array with turbo write enable, some SSDs are slower than people expect.

Pleas post new diags after booting in safe mode (while or after the array starts).

40MB/s is about write using default writing mode to the array, is that what you're doing? If yes see turbo write.