JorgeB

GUI SMART tests only work for SATA devices, you can still run them manually though.

If it was stable with v6.8.3 and now it's crashing with multiple versions, including v6.8.3, it suggests there's a hardware problem, but difficult to say what, you'd need to try with different RAM, board, CPU, etc.

I don't even see an attempt to start docker, I do see this: Aug 22 18:55:38 Messiah emhttpd: stale configuration Reboot and make sure you only have on browser on the GUI.

Just to add that there will be some data corruption on disk3 due to the read errors on disk2 during the rebuild, but not much you can do about that now.

It's not ideal but other than using a different board it's your best option.

Please post new diags.

There's no option to change, it's a mount option. It won't cause any issues also using the plugin.

150MB/s max with 6 disks, depends on the disks used, fast discs can do >200MB/s on the outer sectors, but 150MB/s is still a good speed, and more than enough if you have gigabit.

This is usually a board issue, you can just delete the BIOS since they are not needed for Unraid, it will boot faster.

No, it just means the syslog server is not correctly configured, check config or set it to mirror to the flash drive instead.

This will never be fixed by just changing hardware, if for now there are no more ATA errors run xfs_repair without -n on disk2, or nothing will be done, then try to re-sync parity, keep monitoring the log for ATA errors.

Swap cables/slot on disk2 and see if the problems stays with the disk or the cables/slot.

Try moving the HBA to a different PCIe slot, or see below: https://forums.unraid.net/topic/111161-pcie-errors/?do=findComment&comment=1013378

No, partiton info is outside parity. What do you mean? You never unassign the drive, just run gdisk with the array stopped, reboot and start array normally.

Main suspects would be controller or one or more of the disks, though it doesn't really look like a controller issue it would the first thing I would try since it's the easiest one to test, if using for example an LSI HBA gives the same results it's likely disk related.

Those aren't errors, it's because of the balance.

Don't understand the question, you can replace any data device with another of the same size or larger, if there's parity assigned.

Yes, each data device is a separate filesystem with Unraid, so they can sleep when not in use.

I did one many years ago:

I meant try a NIC that works with Unraid.

Yes, check "parity is already valid" before array start.

You can see the numbers for the x2 model below: https://forums.unraid.net/topic/41340-satasas-controllers-tested-real-world-max-throughput-during-parity-check/ Divide by 2 to get the x1 version usable bandwidth.

Also note that that one is PCIe x1, they also exist with PCIe x2, x1 can be a bottleneck with 6 disks.

Should be. No. It will support any current size available now and in the near feature.

Not really, just wouldn't try anything else before using a different PSU or at least replace/check all the cables/connections, after that check the syslog for errors like these, there's still a problem if they continue to appear. Aug 21 12:03:58 Tower kernel: ata3.00: status: { DRDY } Aug 21 12:03:58 Tower kernel: ata3: hard resetting link Aug 21 12:04:04 Tower kernel: ata3: link is slow to respond, please be patient (ready=0) Aug 21 12:04:08 Tower kernel: ata3: COMRESET failed (errno=-16) Aug 21 12:04:08 Tower kernel: ata3: hard resetting link Aug 21 12:04:14 Tower kernel: ata3: link is slow to respond, please be patient (ready=0) Aug 21 12:04:18 Tower kernel: ata3: COMRESET failed (errno=-16) Aug 21 12:04:18 Tower kernel: ata3: hard resetting link Aug 21 12:04:23 Tower kernel: ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Aug 21 12:04:23 Tower kernel: ata3.00: configured for UDMA/133 Aug 21 12:04:23 Tower kernel: ata3: EH complete Aug 21 12:04:46 Tower kernel: ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen Aug 21 12:04:46 Tower kernel: ata4.00: failed command: FLUSH CACHE EXT Aug 21 12:04:46 Tower kernel: ata4.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 2 Aug 21 12:04:46 Tower kernel: res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) Aug 21 12:04:46 Tower kernel: ata4.00: status: { DRDY } Aug 21 12:04:46 Tower kernel: ata4: hard resetting link Aug 21 12:04:47 Tower kernel: ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Aug 21 12:04:47 Tower kernel: ata4.00: configured for UDMA/133 Aug 21 12:04:47 Tower kernel: ata4.00: retrying FLUSH 0xea Emask 0x4 Aug 21 12:04:47 Tower kernel: ata4: EH complete Aug 21 12:05:54 Tower kernel: ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen Aug 21 12:05:54 Tower kernel: ata4.00: failed command: READ DMA EXT Aug 21 12:05:54 Tower kernel: ata4.00: cmd 25/00:40:30:86:79/00:05:1e:00:00/e0 tag 29 dma 688128 in Aug 21 12:05:54 Tower kernel: res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)