JorgeB

Formatting is never part of a rebuild, there's a big warning about it, not clear what you mean about the unassigned device, it would not be formatted by the GUI, if you mount it is it also empty?

Many are. Depends on the hardware and write mode, with turbo write, fast disks and no bottlenecks you can get 200MB/s+.

Attachment isn't working.

Looks more like a connection/power issue, replace/swap both cables and try again.

That looks like a disk problem, not a cable/connection problem, you can confirm by running an extended SMART test.

Just setting the fs to auto and formatting disks doesn't require parity sync, but a non correcting parity check won't hurt to make sure all is good.

This is the problem, usable should show close to 32GB, look for a BIOS update.

Rsync is a good option.

Please use the existing docker support thread:

Not seeing any pool related hardware issues in the syslog posted, but there are indications that one of the devices dropped offline before this boot, you should run a scrub and make sure all errors are corrected, then see here for better pool monitoring then post new diags if there are new errors (before rebooting).

Aug 13 18:20:28 tower1 kernel: macvlan_broadcast+0x10e/0x13c [macvlan] Aug 13 18:20:28 tower1 kernel: macvlan_process_broadcast+0xf8/0x143 [macvlan] Macvlan call traces are usually the result of having dockers with a custom IP address, upgrading to v6.10 might fix it, or more info below. https://forums.unraid.net/topic/70529-650-call-traces-when-assigning-ip-address-to-docker-containers/ See also here: https://forums.unraid.net/bug-reports/stable-releases/690691-kernel-panic-due-to-netfilter-nf_nat_setup_info-docker-static-ip-macvlan-r1356/

It should work with any of the recommended LSI HBAs, as long as used in a standard PCIe slot.

Please attach any files directly to the forum.

Jul 25 17:08:43 Tower kernel: macvlan_broadcast+0x10e/0x13c [macvlan] Jul 25 17:08:43 Tower kernel: macvlan_process_broadcast+0xf8/0x143 [macvlan] Macvlan call traces are usually the result of having dockers with a custom IP address, upgrading to v6.10 might fix it, or more info below: https://forums.unraid.net/topic/70529-650-call-traces-when-assigning-ip-address-to-docker-containers/ See also here: https://forums.unraid.net/bug-reports/stable-releases/690691-kernel-panic-due-to-netfilter-nf_nat_setup_info-docker-static-ip-macvlan-r1356/

You can see them in the syslog, see if they go way after the cables swap: Aug 14 07:53:02 Tower kernel: ata2.00: status: { DRDY } Aug 14 07:53:02 Tower kernel: ata2.00: failed command: WRITE FPDMA QUEUED Aug 14 07:53:02 Tower kernel: ata2.00: cmd 61/40:b0:e0:aa:bb/05:00:2c:00:00/40 tag 22 ncq dma 688128 out Aug 14 07:53:02 Tower kernel: res 40/00:a0:60:a0:bb/00:00:2c:00:00/40 Emask 0x50 (ATA bus error) Aug 14 07:53:02 Tower kernel: ata2.00: status: { DRDY } Aug 14 07:53:02 Tower kernel: ata2: hard resetting link Aug 14 07:53:12 Tower kernel: ata2: softreset failed (1st FIS failed) Aug 14 07:53:12 Tower kernel: ata2: hard resetting link Aug 14 07:53:14 Tower kernel: ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310) Aug 14 07:53:14 Tower kernel: ata2.00: configured for UDMA/133 Aug 14 07:53:14 Tower kernel: ata2: EH complete Aug 14 07:54:07 Tower kernel: ata16.00: exception Emask 0x10 SAct 0xf8000 SErr 0x190002 action 0xe frozen Aug 14 07:54:07 Tower kernel: ata16.00: irq_stat 0x80400000, PHY RDY changed Aug 14 07:54:07 Tower kernel: ata16: SError: { RecovComm PHYRdyChg 10B8B Dispar } Aug 14 07:54:07 Tower kernel: ata16.00: failed command: WRITE FPDMA QUEUED Aug 14 07:54:07 Tower kernel: ata16.00: cmd 61/40:78:50:88:91/05:00:2d:00:00/40 tag 15 ncq dma 688128 out Aug 14 07:54:07 Tower kernel: res 40/00:78:50:88:91/00:00:2d:00:00/40 Emask 0x10 (ATA bus error) Aug 14 07:54:07 Tower kernel: ata16.00: status: { DRDY } Aug 14 07:54:07 Tower kernel: ata16.00: failed command: WRITE FPDMA QUEUED Aug 14 07:54:07 Tower kernel: ata16.00: cmd 61/48:80:90:8d:91/01:00:2d:00:00/40 tag 16 ncq dma 167936 out Aug 14 07:54:07 Tower kernel: res 40/00:78:50:88:91/00:00:2d:00:00/40 Emask 0x10 (ATA bus error) Aug 14 07:54:07 Tower kernel: ata16.00: status: { DRDY } Aug 14 07:54:07 Tower kernel: ata16.00: failed command: WRITE FPDMA QUEUED Aug 14 07:54:07 Tower kernel: ata16.00: cmd 61/88:88:d8:8e:91/04:00:2d:00:00/40 tag 17 ncq dma 593920 out Aug 14 07:54:07 Tower kernel: res 40/00:78:50:88:91/00:00:2d:00:00/40 Emask 0x10 (ATA bus error) Aug 14 07:54:07 Tower kernel: ata16.00: status: { DRDY } Aug 14 07:54:07 Tower kernel: ata16.00: failed command: WRITE FPDMA QUEUED Aug 14 07:54:07 Tower kernel: ata16.00: cmd 61/40:90:60:93:91/05:00:2d:00:00/40 tag 18 ncq dma 688128 out Aug 14 07:54:07 Tower kernel: res 40/00:78:50:88:91/00:00:2d:00:00/40 Emask 0x10 (ATA bus error) Aug 14 07:54:07 Tower kernel: ata16.00: status: { DRDY } Aug 14 07:54:07 Tower kernel: ata16.00: failed command: WRITE FPDMA QUEUED Aug 14 07:54:07 Tower kernel: ata16.00: cmd 61/a0:98:a0:98:91/02:00:2d:00:00/40 tag 19 ncq dma 344064 out Aug 14 07:54:07 Tower kernel: res 40/00:78:50:88:91/00:00:2d:00:00/40 Emask 0x10 (ATA bus error) Currently ATA2 is parity, ATA16 is parity2.

If the expander suports SATA2 (earlier firmwares can only link @ 1.5gbps with SATA devices) you'll have around 1100MB/s usable for to all the devices with a single link.

Constant ATA errors on both parity disks, replace/swap cables, including power and try again.

You can only user a smaller drive after a new config, and for that parity needs to be re-synced and any data on a removed disk copied manually to other(s) before or after doing it.

Reboot in safe mode, try again and post new diags if it still fails.

Same thing, though this time the crash to a little longer after the errors: Aug 13 17:54:39 Tower kernel: nvme nvme0: frozen state error detected, reset controller Aug 13 17:54:39 Tower kernel: blk_update_request: I/O error, dev nvme0n1, sector 1528760504 op 0x0:(READ) flags 0x80700 phys_seg 17 prio class 0 Aug 13 17:54:39 Tower kernel: blk_update_request: I/O error, dev nvme0n1, sector 1528760760 op 0x0:(READ) flags 0x80700 phys_seg 18 prio class 0 Aug 13 17:54:40 Tower kernel: pcieport 0000:00:01.0: AER: Root Port link has been reset Aug 13 17:54:40 Tower kernel: pcieport 0000:00:01.0: AER: device recovery successful Aug 13 18:23:29 Tower kernel: microcode: microcode updated early to revision 0x71a, date = 2020-03-24 Still, this suggest it could be related, try removing the NVMe device or using a a different one if available (or it in a different slot).

If that's the problem deleting/renaming vfio-pci.cfg on the flash drive (config folder) will fix it.

Dupe:

That is it, if the pool is named "cache".