JorgeB

In that case Asrock should supply the firmware, though most likely the standard LSI firmware should also work, e.g. the one from the 9300-8i, but you should confirm with Asrock support.

Like mentioned you need the HBA model, not the chip, there's usually a sticker on the back of the HBA, e.g.:

That part can be correct by the user, just create new shares with COW on, it's what I've always done.

It doesn't, it can happen with a single device, I only have a single NVMe for cache, and v6.8 was writing 3TB per day, with the fixes in v6.9 it decreased to less than 200MB per day.

You still didn't update the HBA, older firmwares have known issues with some newer drives, you can also swap cables with another drive to rule them out.

Now do it the other way as the post above.

Make sure you're using the correct "Power Supply Idle Control", see here.

No idea why it didn't work then, you can try the other way, more steps but at least it won't damage parity any more: -stop array and take a note of all the current assignments -Utils -> New Config -> Yes I want to do this -> Apply -Back on the main page, assign all the disks as they were as well as old parity and new disk2, double check all assignments are correct -Check both "parity is already valid" and "maintenance mode" and start the array -Stop the array -Unassign disk2 -Start the array -Stop the Array -Re-assign disk2 -Start the array to begin rebuilding, disk2 will most likely be unmontable, you'll need to run a filesystem check, and probably rebuild the superblock and then use --rebuild-tree, still reiserfs can usually recover pretty well from a situation like this.

I don't use USB for array/pools, and currently is writing much less and an amount that I find acceptable, as it was before the NVMe would be at 1PB written by now.

That's not the problem for me, it's mostly a VM, but since the fixes in v6.9 beta it's writing much less, the large number of writes happened before, with v6.8 it was writing around 3TB per day.

It's in the SMART data for NVMe devices.

Looks like it was done correctly, but apparently something wasn't, make sure you're on 5.0.6 like mentioned, it appears you are since the kernel version is the same. Just did a quick test, waited for about 3 minutes after the invalid slot command and it still worked correctly. Array must be new after the new config (blue icon for all devices): Type the invalid slot command and start array:

It's always possible it is much slower with certain hardware/config, but in my test server with 30 devices there's only a small slow down, 149MB/s with v6.8.3 and 142MB/s with -beta30.

This will tell what you get for any possible device combination: https://carfax.org.uk/btrfs-usage/

Yes.

All the checks on the diags were non correct, so it will keep finding the same errors.

Don't really understand the question, but if you don't want sparse vdisk, which is usually considered an advantage, just copy the vdisk with cp and it will no longer be sparse.

Like mentioned in the link above any share set to NOCOW (default for system shares) can't be fixed since checksums are disable.

Still going strong for now.

Not if all are correct, if there are any uncorrectable errors you need to re-do the pool.

Might as well.

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

Run memtest (if not using ECC RAM or it can be disable).

After it finishes, though not much point in running a balance.