JorgeB

Disk is still disable, and rebooting won't fix that, you need to rebuild, but without the diags from then we can't see what happened and why it got disable, since the disk itself looks healthy.

I have this one: https://www.amazon.com/BEYIMEI-Controller-Expansion-Non-Raid-Converter/dp/B08DFK4LZ7/ref=mp_s_a_1_1?dchild=1&keywords=asm1166&qid=1618470992&sr=8-1

If it happens again grab diags after the problem and before rebooting.

Enable this and then post that log if it happens again.

It confirms it's a network related issue.

Check filesystem on disk8.

This means those are old errors and the files have been deleted/replaced since, more info on that here.

Looks like a power/connection problem, I believe that Microserver uses a fan-out cable for the disks, that would be the first thing to check.

Check this:

Looks like it is, but to be sure we'd need to see the diagnostics.

Btrfs disks can take a few seconds to mount each, the larger the filesystem the longer it can take. P.S. there's some data corruption detected on disk3: Apr 11 08:58:58 Tower kernel: BTRFS info (device md3): bdev /dev/md3 errs: wr 0, rd 0, flush 0, corrupt 2580, gen 0 This can be old or new, if old and fixed you should clear the stats, if new run a scrub.

Try leaving the gateway blank on eth4.

You can either create a new pool and add that SSD alone or reset the current cache and assign it there also alone, to reset cache: Stop the array, if Docker/VM services are using the cache pool disable them, unassign all cache devices, start array to make Unraid "forget" current cache config, stop array, reassign old cache device (there can't be an "All existing data on this device will be OVERWRITTEN when array is Started" warning for any cache device), re-enable Docker/VMs if needed, start array.

Please post more details about your actual problem, that's not enough to get help.

It should, another possible option would be the 6 port Asmedia ASM1166.

Depends on how it was configured, it won't hurt to try, see if it mounts on it's own.

Not when using turbo write, that requires all drives to be read from (except parity and the drive being written to), so it can't be faster then the slower drive at the moment, see the screenshot below: Also note the total read/write speeds, despite write speed being only 215Mb/s controller(s) are reading @ 1.5GB/s and writing at 643Mb/s (because of dual parity), that why it's much easier to bottleneck with Unraid and turbo write compared with for example a traditional RAID5 array where for 200MB/s of write speed you just need the controller to handle 200MB/s + parity, that would only be about 260MB/s for a six device RAID5 array.

That's what I would recommend.

Currently it's moving to disk9, which is also SMR, configure the share or a test share to move data to one of the non SMR disks and see if that makes any difference.

Difficult to say for sure, Marvell controllers in general should be avoided with Unraid, though some are not so bad as others.

Only if you replace the board, you can just not use it.

Yes, it's onboard, according to latest diags LSI only has 7 disks connected, connect the one using the Marvell there also.

Are they the same 5 blocks? You're still using a Marvell controller for one disk, can you connect it to a different one?

Diags posted show first a non correcting check, then a correcting one, so errors on the 2nd check were expected.

Do a new config without disk5 and then see if it mounts with the UD plugin, if it doesn't post new diags after a mount attempt.