JorgeB

No, unless you count using the array without parity.

First issue wasn't cable related:

This was a different issue, cache device dropped offline: May 31 08:51:16 Tower kernel: ata9: hard resetting link May 31 08:51:16 Tower kernel: ahci 0000:0a:00.0: AHCI controller unavailable! May 31 08:51:17 Tower kernel: ata9: failed to resume link (SControl FFFFFFFF) May 31 08:51:17 Tower kernel: ata9: SATA link down (SStatus FFFFFFFF SControl FFFFFFFF) May 31 08:51:17 Tower kernel: ata9.00: disabled Replace cables and try again.

You should post in the thread for the backup plugin/script you're using.

That's what I said above, you'd need to reconfigure the server.

There's uncorrectable metadata corruption on the pool, you need to backup and re-format it, there are some recovery options here if needed.

There are still some ATA errors on disk3, you should replace cables, everything else looks fine so far.

You can usually get better speeds with turbo write, at expense of all disks spinning up for writes.

2021-05-07,14:00:49,Warning,SERVERUS,kern,kernel,RIP: 0010:__nf_conntrack_confirm+0x9b/0x1e6 [nf_conntrack] 2021-05-07,14:00:49,Warning,SERVERUS,kern,kernel,Workqueue: events macvlan_process_broadcast [macvlan] Macvlan call traces are usually the result of having dockers with a custom IP address, 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/

First run a single stream iperf test to check bandwidth is normal, if yes try writing to a disk share instead of a user share to see if there's any difference.

Forgot to mention, one way to workaround this is to downgrade to v6.8.3, it will allow to add the SSD as parity, start array and you can even cancel the parity sync and finish after upgrading back to v6.9, it will accept the device if already partitioned with the old layout.

You can use a trial key but will need to reconfigure the server, including reassigning all the devices.

Since v6.9 Unraid partitions SSDs to start on sector 2048 (for 512B sector devices), HDDs partitions start on sector 64, this means partitions on an SSD are always slight smaller than a same capacity HDD, so they can't be used as parity, unless all other arrays devices are also SSDs or they are smaller capacity HDDs.

See if this applies to you: https://forums.unraid.net/bug-reports/stable-releases/690691-kernel-panic-due-to-netfilter-nf_nat_setup_info-docker-static-ip-macvlan-r1356/

Problem with the onboard SATA controller: May 29 00:03:19 Tower kernel: ahci 0000:0a:00.0: AHCI controller unavailable! This is quite common with Ryzen boards, BIOS updated or a different kernel might help.

You can just convert the pool to raid1: https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=480421

It's missing the leading slash on the last line: #!/bin/bash # Start the Management Utility /usr/local/sbin/emhttp &

Disk looks fine, replace/swap cables to rule em out and rebuild assuming the emulated disk is mounting correctly. You also have what look more like connection issues with the cache drive, but since it dropped offline there's no SMART report.

Diags are after rebooting so we can't see what happened but the disk has a lot of pending sectors, you should run an extended SMART test.

Yes, Unraid can't auto heal a write error, in part because each disk is an independent filesystem, it can still auto heal a read error (if the re-writes are successful). Yes, SMART report shows nothing of concern for now.

Fix filesystem on both: https://wiki.unraid.net/Check_Disk_Filesystems#Checking_and_fixing_drives_in_the_webGui Remove -n or nothing will be done and if it asks for it use -L

Not that I'm aware of.

No, but the megaRAID driver is not as well tested as the LSI IT driver (mpt3sas) and is much more likely to have some issues with specific models, of course it's just a suspicion, you'd need to test with an HBA to confirm.

Stop and re-start the array (or reboot), if it still mounts after that it should be fine. Yep. Not really needed IMHO, but won't hurt, except for keeping the array degraded longer than needed. Stop array, unassign that disk, start array, stop array, re-assign disk, start array to begin rebuild. No, rebuild as soon as possible.

This, CRC errors attribute doesn't reset, but as long as it doesn't keep increasing issue is solved.