JorgeB

Pools with mixed root (main) vdevs are not supported, they are also not recommended, AFAIK there are no plans to support that in the near future, you'd need to import the pool manually with zpool import, can still access the data but it won't be part of the user shares.

I missed before that you have the S3 plugin installed, the server may be going to sleep and not waking up, try removing it.

Try booting in safe mode.

Unraid doesn't support mirror together with raidz in the same pool, also that's not recommend anyway, you should have all mirrors or all raidz of the same type and with, and that's all Unraid supports.
 
Manual pool import will still work, but to get Unraid to import that pool you will need to backup, destroy and recreate it.
 
 

It does look like a flash problem, see if you can copy the /config folder.

Difficult to say now, if it's resolved I wouldn't worry much about it.

According to this all disks are mounted read/write.
 
Post the output of:
btrfs prop get /mnt/disk1  

IIRC the workaround is not longer needed.

Try switching to ipvlan (Settings -> Docker Settings -> Docker custom network type -> ipvlan (advanced view must be enabled, top right)), then reboot.

Check that this has been taken care of:
https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=819173
 

You can do it from the GUI by creating a pool, but note that currently you need at least one data device assigned to the array, it can be an old flash drive.

As mentioned raid0 with same size devices is the same, or even better since it's faster, and there's no single mode with zfs, only btrfs.

Assuming you are using the docker container look for the support thread:
 

 
 

Nov 26 05:28:52 BKHunraid kernel: ata41: COMRESET failed (errno=-16) Nov 26 05:28:52 BKHunraid kernel: ata41: limiting SATA link speed to 3.0 Gbps Nov 26 05:28:52 BKHunraid kernel: ata41: hard resetting link Nov 26 05:28:57 BKHunraid kernel: ata41: COMRESET failed (errno=-16) Nov 26 05:28:57 BKHunraid kernel: ata41: reset failed, giving up Nov 26 05:28:57 BKHunraid kernel: ata41.00: disable device Nov 26 05:28:57 BKHunraid kernel: ata41: EH complete  
One of your cache devices dropped offline, check/replace cables, since it's an MX500 also check it's on the latest firmware.

Moving data between array drives is always slow due to parity, 73MB/s is pretty good.

Looks more like a power/connection problem.

That's not the persistent syslog, but there's a clue anyway:
 
Nov 14 07:27:38 millesime kernel: macvlan_broadcast+0x10a/0x150 [macvlan] Nov 14 07:27:38 millesime kernel: ? _raw_spin_unlock+0x14/0x29 Nov 14 07:27:38 millesime kernel: macvlan_process_broadcast+0xbc/0x12f [macvlan]  
Macvlan call traces will usually end up crashing the server, switching to ipvlan should fix it (Settings -> Docker Settings -> Docker custom network type -> ipvlan (advanced view must be enabled, top right)), then reboot.
 

Looks more like a power/connection issue, replace cables (both power and SATA) for disk8 and try again.

Nov 14 11:49:42 Rannoch kernel: macvlan_broadcast+0x10a/0x150 [macvlan] Nov 14 11:49:42 Rannoch kernel: ? _raw_spin_unlock+0x14/0x29 Nov 14 11:49:42 Rannoch kernel: macvlan_process_broadcast+0xbc/0x12f [macvlan]  
Macvlan call traces will usually end up crashing the server, switching to ipvlan should fix it (Settings -> Docker Settings -> Docker custom network type -> ipvlan (advanced view must be enabled, top right)), then reboot.

Yes, you can also try to copy everything you can from those disks to new ones, any read errors those files won't be copied, so you'd just need to restore the missing data from the backups, in case that's easier.

That's very strange, if it happens again make sure to grab the diags before rebooting.

Nov 13 04:20:23 UNRAIDSRV kernel: macvlan_broadcast+0x10a/0x150 [macvlan] Nov 13 04:20:23 UNRAIDSRV kernel: ? _raw_spin_unlock+0x14/0x29 Nov 13 04:20:23 UNRAIDSRV kernel: macvlan_process_broadcast+0xbc/0x12f [macvlan] Macvlan call traces will usually end up crashing the server, switching to ipvlan should fix it (Settings -> Docker Settings -> Docker custom network type -> ipvlan (advanced view must be enabled, top right)).

Nov 20 05:02:29 Tower kernel: macvlan_broadcast+0x10a/0x150 [macvlan] Nov 20 05:02:29 Tower kernel: ? _raw_spin_unlock+0x14/0x29 Nov 20 05:02:29 Tower kernel: macvlan_process_broadcast+0xbc/0x12f [macvlan]  
Macvlan call traces will usually end up crashing the server, switching to ipvlan should fix it (Settings -> Docker Settings -> Docker custom network type -> ipvlan (advanced view must be enabled, top right)), then reboot.

Tools - New config, assign the disks and then check "parity is already valid" before array start.

Wait for the parity sync to finish, then enable turbo write and re-test.