JorgeB

Forgot to mention, size issue could be unrelated, but difficult to analyze the current log due to spam, post new diags with rc3 to see if it's better.

Unraid driver is crashing, this sometimes happens with some hardware/kernel combinations, you can try updating to v6.10-rc3 to see if it helps.

Please post the diagnostics.

Changed Status to Solved

Fixed on v6.10-rc3

Changed Status to Solved

Fixed on rc3

Should be, but might require forcing a reboot.

As long as the disk is really OK you can do the new config and re-sync parity.

Was it stable before it that release?

It's not RAM cache, it's for large transfers, much large than installed RAM.

Unless there was nothing important on that disk, or all data there will be gone.

OK, I can see disk7 is now enable but due to log spam from the previous issues can't see the latest lines, reboot and post new diags after array start.

Follow the instructions above carefully.

You didn't do the new config, both disks are still invalid.

You didn't do the procedure correctly, or those are old diags, both disks are still invalid.

Don't format, post new diags after array start.

Many users can do that, including myself, can transfer at about 800MB/s to some of my pools.

Unraid can't emulate two disks with single parity, this is a scenario that should not happen, i.e., disabling one disk during the rebuild of another with single parity, disk7 look OK, though there are a lot of CRC errors, if these are recent you should replace the SATA cable, then you can force enable disk7 to try and rebuild disk5, assuming parity is still valid, to do that: -Tools -> New Config -> Retain current configuration: All -> Apply -Check all assignments and assign any missing disk(s) if needed -IMPORTANT - Check both "parity is already valid" and "maintenance mode" and start the array (note that the GUI will still show that data on parity disk(s) will be overwritten, this is normal as it doesn't account for the checkbox, but it won't be as long as it's checked) -Stop array -Unassign disk5 -Start array (in normal mode now), ideally the emulated disk will now mount and contents look correct, if it doesn't you should run a filesystem check on the emulated disk -If the emulated disk mounts and contents look correct stop the array -Re-assign disk5 and start array to begin.

Likely from the syslog server, check settings or disable if not needed, and delete the files.

Please don't double post, continue discussion here:

If they are near capacity no good to test, since speed will be <100MB/s. Problem might not be the NVMe device, but it also doesn't sound like an SMB problem, unless it's a source problem, that 's why it would be good to test with another device, single unsigned fast HDD (empty) or SSD would do.

And the disk is empty or close to empty and turbo write is enable? If yes post diags during a transfer.

Should be, or at least close enough, depending on the SSDs and raid mode used.

You can with pre-clear plugin/docker, disk must be unassigned and any data there will be deleted.