JorgeB

You might need to force a reboot, also lots of ATA errors from disk1, start by replacing cables. Aug 2 13:12:38 Tower kernel: ata2.00: exception Emask 0x50 SAct 0x7e000 SErr 0x4090800 action 0xe frozen Aug 2 13:12:38 Tower kernel: ata2.00: irq_stat 0x00400040, connection status changed Aug 2 13:12:38 Tower kernel: ata2: SError: { HostInt PHYRdyChg 10B8B DevExch } Aug 2 13:12:38 Tower kernel: ata2.00: failed command: READ FPDMA QUEUED Aug 2 13:12:38 Tower kernel: ata2.00: cmd 60/40:68:40:e2:83/05:00:06:00:00/40 tag 13 ncq dma 688128 in Aug 2 13:12:38 Tower kernel: res 40/00:08:a0:f5:3a/00:00:3a:00:00/40 Emask 0x50 (ATA bus error) Aug 2 13:12:38 Tower kernel: ata2.00: status: { DRDY } Aug 2 13:12:38 Tower kernel: ata2.00: failed command: READ FPDMA QUEUED Aug 2 13:12:38 Tower kernel: ata2.00: cmd 60/40:70:80:e7:83/05:00:06:00:00/40 tag 14 ncq dma 688128 in Aug 2 13:12:38 Tower kernel: res 40/00:08:a0:f5:3a/00:00:3a:00:00/40 Emask 0x50 (ATA bus error) Aug 2 13:12:38 Tower kernel: ata2.00: status: { DRDY } Aug 2 13:12:38 Tower kernel: ata2.00: failed command: READ FPDMA QUEUED Aug 2 13:12:38 Tower kernel: ata2.00: cmd 60/40:78:c0:ec:83/05:00:06:00:00/40 tag 15 ncq dma 688128 in Aug 2 13:12:38 Tower kernel: res 40/00:08:a0:f5:3a/00:00:3a:00:00/40 Emask 0x50 (ATA bus error) Aug 2 13:12:38 Tower kernel: ata2.00: status: { DRDY } Aug 2 13:12:38 Tower kernel: ata2.00: failed command: READ FPDMA QUEUED Aug 2 13:12:38 Tower kernel: ata2.00: cmd 60/40:80:00:f2:83/05:00:06:00:00/40 tag 16 ncq dma 688128 in Aug 2 13:12:38 Tower kernel: res 40/00:08:a0:f5:3a/00:00:3a:00:00/40 Emask 0x50 (ATA bus error) Aug 2 13:12:38 Tower kernel: ata2.00: status: { DRDY } Aug 2 13:12:38 Tower kernel: ata2.00: failed command: READ FPDMA QUEUED

Just to add that although the no spin down issue I was having was because of the IPMI plugin, the crazy temps are not, it's not a big deal and it only happens with some make/model disks, so not sure it is a bug, but if I click on one of those disks while it's spun down it starts showing those temps, they then return to normal once the disks cycles, I assume it's smartctl causing that. A few minutes later: 6 appears to be related to the cache slot number, this device is on slot 36, 55 is the temp of the only active cache device, an NVMe device.

Those errors are from an unassigned NTFS device, note the the errors might persist until you reboot even the device was already removed/disconnected.

Benvindo! É verdade, nós estamos tão habituados ao sotaque brasileiro na TV e música que é muito fácil para nós, embora por vezes aparece um termo mais técnico que não é tão fácil, recentemente um brasileiro queria um "gabinete", teve de me explicar que era uma caixa para o PC.

Never seen a 520byte SATA drive, I guess it's possible, but that's mostly used on SAS devices.

You can use then on any x16 slot, usually x8 physical slots are on server boards only.

If it's a very recent board there's a good chance v6.8 doesn't have the NIC driver, you can try v6.9-beta25.

No driver for your NIC on v6.8, it should work with 6.9-beta25.

Please post the diagnostics: Tools -> Diagnostics

You can boot and flash it with a DOS flash drive. You won't known until you try, any corrupt data will generate an i/o error during normal copy, everything copied without error you can assume it's good.

New beta fixes this issue, but this was mostly when using btrfs, how many GBs is it writing per day?

That one will work.

Correct. You're correct, with a SAS expander the cable from the HBA to the expander can be up to 10m long, though you should use one as small as possible, then from the expander to the SATA devices up to 1m.

No, but still good to have them to look at all the hardware, looking at the earlier syslog the cache dropped offline, then reconnected with a different letter, h200 is not the best option for SSDs since trim won't work, if you can use a SATA port instead, if you don't have one swap/replace cables, if it keeps happening best bet is to try a different model SSD.

They should work without issues.

Most likely the disks, you can compare the diskspeed curve with actual parity check curve using the dynamic stats plugin, like mentioned it can never be faster than the slowest disk, but if slower than that then there could be other issues.

Please post the diagnostics: Tools -> Diagnostics

Yes if it is a correcting check.

They are supported, but they tend to have more issues with Linux in general, not just Unraid, though like mentioned and AFAIK these controller issues mostly happened with v6.8, everyone that update to v6.9 reported no more errors, due to newer Linux kernel, also you should update the bios, since it's not the latest.

Cache filesystem is corrupt, you'll need to backup and reformat, corruption could be the result of an unclean shutdown or some controller/device write cache issue, also good idea to update the LSI firmware.

or wait for a newer Unraid release, with a newer kernel, not much more you can do, other than getting a different board.

You have 3 different disk sizes, parity check can never be faster than the slowest disk at any point, and disks are much slower as they get to the inner cylinders, so it will slow down 3 times, especially noticeable as it gets near the end of the 3TB disks, then 4TB and finally 8TB. Also you have some disks that max out at around 150MB, even on the outer cylinders, like the 4TB Reds, so 130MB/s is not bad, it should be more than that in the beginning but there will be points that it will be much slower, you can get an idea by running the diskspeed docker. Hardware wise your fine, just make sure the HBA is on one of the top 2 slots, the x8 CPU slots, can't see that in the diags.

Are you replacing or removing? To remove just unassign them and start the array, to replace you could have done it one at a time, without moving any data and maintaining the pool online.

Yep, and after re-assigning them all check "parity is already valid" next to the array start button to avoid a parity sync.

Yes, but you still need to do a new config.