JorgeB

It's a dual expander model, primary ports go to one expander, secondary ports to the other, with Unraid you only need to use the primary. No, for best performance you can connect one HBA using dual link to the front backplane, Supermicro recommends using primary ports J1 and J2, but it should work with any two ports on the same expander, also the 9211 with dual link will bottleneck due to being PCIe 2.0, a PCIe 3.0 HBA like the 9207-8i or 9300-8i would be better, assuming the board/CPU supports PCIe 3.0. Not sure the seconds backplane supports dual link, you can test or post the model for that one to see if I can find any info, though with half the drives it will have the same approximate bandwidth with a single link as the front one with dual, and Unraid max array size is 30 devices, so you'll never need to use the 36 devices simultaneously.

Please post the diagnostics.

Connect the disk to the onboard SATA controller and check if it's detected in the BIOS.

It's logged as a disk problem, wait for the extended test to finish and act according to the result.

To see the cache share you need to enable disk shares, but keep in mind that you can't copy/move files from disk shares to user shares or vice versa, or risk losing data.

Mostly experience.

This just means that cache is hitting the minimum space set for that share.

SMART overall-health self-assessment is mostly meaningless, important part is that the extended test failed: SMART Extended Self-test Log Version: 1 (1 sectors) Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed: read failure 90% 41827 312950152 Disk needs to be replaced.

rsync -X copies the extended attributes, resiserfs has issues with those.

You have, it's just not mounting, Please post the diagnostics.

I checked before and the parity swap procedure completed successfully without any errors, so all should be fine.

If it's doing weird noises it's likely the disk, assuming power cable/slot was already replaced/swapped.

Check filesystem on disk3.

That turned out to be a false issue, at least so far, and it's not the problem here: Oct 19 09:50:38 Tower shutdown[16774]: shutting down for system reboot ... Oct 19 09:51:45 Tower root: Waiting on VMs to hibernate............................................................ Oct 19 09:51:45 Tower root: Domain 86349a06-14bd-3361-c257-9064d80fe376 is being shutdown Oct 19 09:51:45 Tower root: Oct 19 09:51:45 Tower root: Domain 37dc3718-c315-0f42-39de-4a1ab8e25771 is being shutdown Oct 19 09:51:45 Tower root: VM timeout is set to 60 secs, and it wasn't enough, and looks like they didn't force shutdown either since libvirt was still in use after this.

This is usually caused by having NFS enable, if possible use SMB only or try disabling hard links.

There might be, but don't know how, someone else might have a suggestion.

Looks more like a power/connection problem, I would recommended replacing/swapping cables/slot to rule those out if it happens again to the same disk, then and if the emulated disk is mounting and contents look correct you can rebuild on top using the instructions above.

Oct 19 09:53:41 Tower emhttpd: shcmd (37287): umount /mnt/cache Oct 19 09:53:41 Tower root: umount: /mnt/cache: target is busy. Something was still using cache.

Yes, same issue as linked above, see that thread for some possible workarounds.

Not the same, diags you posted are after rebooting.

Could be, you can try swapping drives and cables with the onboard SATA.

You're still having multiple ATA errors on multiple disks: Oct 18 22:09:43 Cube kernel: ata10.00: status: { DRDY } Oct 18 22:09:43 Cube kernel: ata10.00: failed command: WRITE FPDMA QUEUED Oct 18 22:09:43 Cube kernel: ata10.00: cmd 61/40:88:08:58:00/05:00:00:00:00/40 tag 17 ncq dma 688128 out Oct 18 22:09:43 Cube kernel: res 40/00:00:00:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout) Oct 18 22:09:43 Cube kernel: ata10.00: status: { DRDY } Oct 18 22:09:43 Cube kernel: ata10.00: failed command: WRITE FPDMA QUEUED Oct 18 22:09:43 Cube kernel: ata10.00: cmd 61/f8:90:48:5d:00/04:00:00:00:00/40 tag 18 ncq dma 651264 out Oct 18 22:09:43 Cube kernel: res 40/00:01:01:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) Oct 18 22:09:43 Cube kernel: ata10.00: status: { DRDY } Oct 18 22:09:43 Cube kernel: ata10: hard resetting link Oct 18 22:09:43 Cube ntpd[1794]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized Oct 18 22:09:48 Cube kernel: ata10: link is slow to respond, please be patient (ready=0) Oct 18 22:09:53 Cube kernel: ata10: COMRESET failed (errno=-16) Oct 18 22:09:53 Cube kernel: ata10: hard resetting link Oct 18 22:09:53 Cube kernel: ata10: SATA link up 6.0 Gbps (SStatus 133 SControl 310) Oct 18 22:09:53 Cube kernel: ata10.00: configured for UDMA/133 Oct 18 22:09:53 Cube kernel: ata10: EH complete Oct 18 22:10:11 Cube kernel: ata8.00: READ LOG DMA EXT failed, trying PIO Oct 18 22:10:11 Cube kernel: ata8: failed to read log page 10h (errno=-5) Oct 18 22:10:11 Cube kernel: ata8.00: exception Emask 0x1 SAct 0xc02000 SErr 0x0 action 0x0 Oct 18 22:10:11 Cube kernel: ata8.00: irq_stat 0x40000001 Oct 18 22:10:11 Cube kernel: ata8.00: failed command: READ FPDMA QUEUED Oct 18 22:10:11 Cube kernel: ata8.00: cmd 60/20:68:00:ee:4a/00:00:0a:00:00/40 tag 13 ncq dma 16384 in Oct 18 22:10:11 Cube kernel: res 51/04:b8:80:87:00/00:00:00:00:00/40 Emask These are usually a power/connection problem, and the data should come back after a reboot.

You're still getting an unclean shutdown, first thing you can do is to press array stop and see how long it takes to stop, and if it does, second thing is to post the diags saved on the flash drive after the latest unclean shutdown, they are generated automatically.

Could be a specific board issue, look for a BIOS update and/or try toggling any relevant BIOS options.

Yep, you should replace it ASAP.