JorgeB

Check filesystem on disk3.

Please post the diagnostics: Tools -> Diagnostics, there could be another reason for the errors, like the LSI firmware.

UD can't mount Synology drives, IIRC they use an MD/btrfs raid combo, you'd need to transfer the data using the network, you can still mount the Synology share with UD.

They won't if you

Last extended test on disk6 was many years ago, run a new one, UDMA CRC errors are a connection issue, just acknowledge and make sure it doesn't keep increasing.

If it doesn't even post it's a hardware issue, not Unraid related.

Same answer as above.

That means the tree block is corrupt, there are some recovery option here.

It uses the new discard=async btrfs mount option.

Yes, make sure no data drive is assigned to a parity slot, and you can check "parity is already valid" if using all the previous assignments.

That is the Asmedia controller, it's separate from the Intel ports, but the Intel ports are working since it's detecting the optical drive.

And you say they show up in the BIOS? It's strange, according to the log there's no drives connected except the optical drive: Mar 1 03:02:11 Matthews kernel: ata7: SATA link down (SStatus 4 SControl 300) Mar 1 03:02:11 Matthews kernel: ata3: SATA link down (SStatus 4 SControl 300) Mar 1 03:02:11 Matthews kernel: ata2: SATA link down (SStatus 4 SControl 300) Mar 1 03:02:11 Matthews kernel: ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) Mar 1 03:02:11 Matthews kernel: ata6: SATA link down (SStatus 4 SControl 300) Mar 1 03:02:11 Matthews kernel: ata4: SATA link down (SStatus 4 SControl 300) Mar 1 03:02:11 Matthews kernel: ata9: SATA link down (SStatus 0 SControl 300) Mar 1 03:02:11 Matthews kernel: ata8: SATA link down (SStatus 4 SControl 300) Mar 1 03:02:11 Matthews kernel: ata5: SATA link down (SStatus 4 SControl 300) Mar 1 03:02:11 Matthews kernel: ata10: SATA link down (SStatus 0 SControl 300)

With v6.9 it's not needed for any cache device or pool using btrfs, still needed for xfs.

Problem with disk2 looks more like a connection/power problem, but the fact that you mention mechanical noises makes me suspect a power issue, replace cables or PSU and try the parity sync again with the same disk.

Cache filesystem is corrupt, best is to backup and re-format the pool.

Not really, unless you're using WiFi.

https://en.wikipedia.org/wiki/Shingled_magnetic_recording

Nothing obvious, parity disks are SMR though, and some units of that particular model has been known to sometimes perform inconsistently.

Disk looks fine, you can run an extended SMART test, diags might also give some more clues on the problem.

Cache filesystem is corrupt and should be recreated, there are some recovery options here.

Writes to a mirror will always have to go to both drives, and it can never be faster than the slowest drive, for reads it could use the faster device, btrfs currently doesn't do that, though it's planned for the future.

Run a single stream iperf test.

UDMA CRC is a connection problem, usually the SATA cable, replace it, note that the attribute doesn't reset, but as long as it doesn't keep increasing problem is solved.

Please post the diagnostics: Tools -> Diagnostics

If you use Windows 10 the transfer from disk to disk will be done locally, it will not use the network.