JorgeB

2 port Asmedia is fine, any Asmedia with more than 2 ports is using SATA port multipliers and that is no good. If 4/5 ports are enough look for a JMB585 based controller, for 8 ports look for any LSI with a SAS2008/2308/3008/3408 chipset in IT mode, e.g., 9201-8i, 9211-8i, 9207-8i, 9300-8i, 9400-8i, etc and clones, like the Dell H200/H310 and IBM M1015, these latter ones need to be crossflashed.

By no issue do you mean you get 100MB/s+ with a single stream?

There is, but it will likely require a new config and possibly rebuilding every disk.

One of the cache pool devices had many errors (also there are also a few read errors on the other one) and it's failing to remove: May 17 14:55:35 WhiteHouse kernel: BTRFS info (device sdb1): bdev (null) errs: wr 6420558, rd 28315, flush 142629, corrupt 0, gen 0 May 17 14:55:35 WhiteHouse kernel: BTRFS info (device sdb1): bdev /dev/sdb1 errs: wr 0, rd 20, flush 0, corrupt 0, gen 0 Best bet it to backup any cache data and recreate the pool, there are some recovery options here if needed, after recreation also see here for better pool monitoring.

If it's running yes.

It is, though there was a bug for pools created with v6.7.x where it wasn't.

Looks like that one is toast, btrfs restore is likely the only option, but if the pool was redundant you can try the other device, you can safely assign it after making Unraid forget current pool: Stop the array, unassign current cache device, start array to make Unraid "forget" current cache config, stop array, reassign the other cache device (there can't be an "All existing data on this device will be OVERWRITTEN when array is Started" warning for any cache device), start array. If the other device also doesn't mount see here for other recovery options.

https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=545988

That looks like an old xfs_repair bug, if you are not running latest Unraid (v6.8.3) upgrade and try again.

An LSI megaRAID controller is not the best option for Unraid, an LSI based HBA would be best, still better than the one you were using before.

It should be recoverable, run again without -n or nothing will be done, and if it asks for it use -L.

SMART looks bad and it's failing the extended SMART test, it needs to be replaced.

The disk appears to be failing, you can confirm by running an extended SMART, and WD must replace it if it's within the warranty period.

I would start with the cables and/or PSU.

Diags are after rebooting so we can't see what happened but you're using a SATA port multiplier and those are a known source of problems, not surprisingly parity is connected there.

Definitely not a know issue, problem with the Asmedia controller, it dropped both parity disks: May 16 18:05:08 Tower kernel: ata7: hard resetting link May 16 18:05:18 Tower kernel: ata8: softreset failed (1st FIS failed) May 16 18:05:18 Tower kernel: ata8: hard resetting link May 16 18:05:18 Tower kernel: ata7: softreset failed (1st FIS failed) May 16 18:05:18 Tower kernel: ata7: hard resetting link May 16 18:05:28 Tower kernel: ata8: softreset failed (1st FIS failed) May 16 18:05:28 Tower kernel: ata8: hard resetting link May 16 18:05:28 Tower kernel: ata7: softreset failed (1st FIS failed) May 16 18:05:28 Tower kernel: ata7: hard resetting link May 16 18:06:03 Tower kernel: ata8: softreset failed (1st FIS failed) May 16 18:06:03 Tower kernel: ata8: limiting SATA link speed to 3.0 Gbps May 16 18:06:03 Tower kernel: ata8: hard resetting link May 16 18:06:03 Tower kernel: ata7: softreset failed (1st FIS failed) May 16 18:06:03 Tower kernel: ata7: limiting SATA link speed to 3.0 Gbps May 16 18:06:03 Tower kernel: ata7: hard resetting link May 16 18:06:08 Tower kernel: ata8: softreset failed (1st FIS failed) May 16 18:06:08 Tower kernel: ata8: reset failed, giving up May 16 18:06:08 Tower kernel: ata8.00: disabled ... May 16 18:06:08 Tower kernel: ata7: softreset failed (1st FIS failed) May 16 18:06:08 Tower kernel: ata7: reset failed, giving up May 16 18:06:08 Tower kernel: ata7.00: disabled May 16 18:06:08 Tower kernel: ata7: EH complete AFAIK there are no issues with Asmedia controllers and v6.8.3, if there were I would expect many users with problems since it's a very commonly used controller, might be a power issue, do both disks share a power splitter or similar? Or, since the controller is onboard and an older revision it might also be a specific problem with that board/revision.

What happened to the other one? In the meantime try this, on the console type: mkdir /x mount -o ro,nologreplay /dev/sdb1 /x If it doesn't mount post the error on the syslog

Some split level examples here: https://forums.lime-technology.com/topic/59589-solved-v635-advice-please-on-shares-settings/?do=findComment&comment=584558

You'll likely need to restart the server, segfault appears to be NFS related, so disable if not in use.

Clearly the network is the problem, try a different switch, cable, NIC, source PC, etc until you find the problem.

That suggests a hardware problem, difficult for us to diagnose, I would start with a different PSU.

No, but depending on the firmware in use you might need to do a new config (or even rebuild every disk there), and that is harder with a disabled disk, so I would suggest connecting that disk directly to the main server on the newer LSI and rebuild it, then worry about upgrading the old LSI.

Revert the change you did to the VM and see if it starts, if it does try again using the onboard sound and if it crashes that's the problem, then post the diagnostics.

If all 3 disks are exact copies and parity is valid yes, also disks need to be same capacity, can't be larger, then you'll need to do a new config and use the invalid slot command, if you get 3 drives working let us know and I'll post the instructions.

Disk is on a controller that only supports 2.2TB max, and it appears that because of that Unraid doesn't consider it a valid partition, best bet is to connect that disk to a controller that supports the full disk capacity, but you'll need to rebuild it again.