JorgeB

Please post the diagnostics: Tools -> Diagnostics

It's normal for Unraid to complain since the disks won't be using the full partition, since partitions are outside parity you should be able to re-create them by having Unraid rebuild one disk at a time, you can see if it works by stopping the array, unassigning one of the data disks, then start the array and check if the emulated disk mounts, if yes stop and re-assign it again to rebuild on top, then repeat for the other disks.

Yes, pool is identified by a single device, as long as there are no errors all pool devices should have been trimmed.

You can use the invalid slot command, but note that there will likely be some filesystem corruption since disk1 was mounted read/write without parity, also and before starting were the new drives you were adding already cleared? If not they can't be used with parity right away.

Please post the diagnostics: Tools -> Diagnostics

👍

Try this, it might catch something.

There's a hardware problem with the cache device resulting in read errors: Feb 14 17:13:20 Tower kernel: ata8.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 Feb 14 17:13:20 Tower kernel: ata8.00: failed command: READ DMA EXT Feb 14 17:13:20 Tower kernel: ata8.00: cmd 25/00:20:20:82:35/00:00:1c:00:00/e0 tag 9 dma 16384 in Feb 14 17:13:20 Tower kernel: res 51/40:00:00:00:00/00:00:00:00:00/e0 Emask 0x9 (media error) Feb 14 17:13:20 Tower kernel: ata8.00: status: { DRDY ERR } Feb 14 17:13:20 Tower kernel: ata8.00: error: { UNC } Feb 14 17:13:20 Tower kernel: ata8.00: configured for UDMA/133 Feb 14 17:13:20 Tower kernel: sd 7:0:1:0: [sdc] tag#85 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 Feb 14 17:13:20 Tower kernel: sd 7:0:1:0: [sdc] tag#85 Sense Key : 0x3 [current] Feb 14 17:13:20 Tower kernel: sd 7:0:1:0: [sdc] tag#85 ASC=0x11 ASCQ=0x4 Feb 14 17:13:20 Tower kernel: sd 7:0:1:0: [sdc] tag#85 CDB: opcode=0x28 28 00 1c 35 82 20 00 00 20 00 Feb 14 17:13:20 Tower kernel: print_req_error: I/O error, dev sdc, sector 473268768 Feb 14 17:13:20 Tower kernel: BTRFS error (device sdc1): bdev /dev/sdc1 errs: wr 0, rd 1327, flush 0, corrupt 0, gen 0 This is corrupting the filesystem, they are logged more like an actual SSD problem but try a swapping cables and controller first and see if these go away, if not you'll need to replace it, also will likely need to re-format pool to fix current corruption.

Changed Status to Closed Changed Priority to Other

No experience with that brand, but it's for 2.5" drives.

Most SSDs should work fine as array devices, trim won't work for now, also 860 QVO won't be much faster writing than spinners, reads will be much faster though.

There are Supermicro with 36 bays, but they are expensive, also good.

There's someone here that went through a lot of trouble trying to confirm that same thing, and last time I read there's was no real conclusion.

Should be fine.

Strange, since it's also failing to trim on the LSI, so not board, maybe different firmware?

See if it was a one time thing, AFAIK no recent changes for that driver.

That's one of the problems with half supported ECC, part of ECC support is reporting if errors are occurring, and AFAIK there's no sure way to known if it's actually working on those platforms.

Agree, it's the most probable explanation, please keep us updated.

I missed it earlier but there's also corruption on the cache filesystem, best way forward is to backup and reformat cache, then recreate docker image once more.

Please post current diags.

Yes.

There are no formatted devices, you need to format any assigned device first, next to array start/stop buttons.

It's most likely option to work for this case, though obviously not certain to work.

Yes, devices are tracked by serial, there could be issues when using RAID controllers that use a custom identification, which shouldn't be a problem in this case, but it is you'll get a lot of wrong disk errors and the array won't start, no harm done.

I meant both cables, also a good idea to use a different SATA port, if it still fails after that it's likely the disk despite the healthy SMART.