JorgeB

No.

As you prefer, if they are mostly assigned in the correct slots you can keep them.

You'll need to do a new config, data on the cache will remain.

You'll need to rebuild them or do a new config and run a parity check, either way it will take about the same amount of time.

Pool has two data profiles, it needs to be balanced, you'll get a notification about that if they are enable.

If the BIOS is up to date not much more you can do other than trying a different brand/model device (or a different board).

Unassign the cache device, try to mount it with UD plugin and post new diags and the output of fdisk -l /dev/sdX if it fails to mount .

Yes, as long as you don't assign a data drive to a parity slot, if you now which one is parity it's a simple process, with single parity drive order doesn't matter so you can even check parity is already valid before array start, should still run a parity check after to make sure all is well.

If it all fits there you can, set all shares to cache=prefer and run the mover, files can't be in use or they won't be moved.

It can vary, but yes, under 20MB/s is normal, I get as low as 5MB/s for a few seconds/minutes with one of my SMR based arrays.

Disk1 (and parity) are SMR, they can be much slower than CMR disks.

Same, never seen that before.

It might apply if the disks were spun down, they would spin up on shutdown, and that's when the issue occurs with the 8TB Ironwolf.

I believe it's not how it works, disk is rebuilt sequentially, any writes to an already rebuilt zone should only update parity as normal, nothing would be logged.

This is a new one, don't see how parity was corrected during a disk rebuild with single parity.

Something else must have happened, recommend also seeing here for better pool monitoring.

Most likely, you can try #btrfs on IRC or the mailing list like mentioned in the FAQ.

Enable the syslog server and post that log after a crash.

Don't know if you can use it but at boot time all btrfs filesystems are scanned, e.g.: Dec 7 15:37:51 Tower11 kernel: BTRFS: device fsid 422c457c-5e12-4be7-8422-a661e00c7ffc devid 2 transid 5013 /dev/sdi1 scanned by udevd (1511) Dec 7 15:37:51 Tower11 kernel: BTRFS: device fsid ae12a64a-ab83-429e-a449-e02b0d1a3453 devid 2 transid 4813 /dev/sdf1 scanned by udevd (1512) Dec 7 15:37:51 Tower11 kernel: BTRFS: device fsid 99c55241-a0cf-4003-b66d-73512686ce4e devid 1 transid 34 /dev/sdc1 scanned by udevd (1679) Dec 7 15:37:51 Tower11 kernel: BTRFS: device fsid 422c457c-5e12-4be7-8422-a661e00c7ffc devid 1 transid 5013 /dev/sdb1 scanned by udevd (1511) Dec 7 15:37:51 Tower11 kernel: BTRFS: device fsid ae12a64a-ab83-429e-a449-e02b0d1a3453 devid 1 transid 4813 /dev/sdg1 scanned by udevd (1511) Dec 7 15:37:51 Tower11 kernel: BTRFS: device fsid 56d7a584-5bfd-4d97-94bf-9a0ddc798c65 devid 1 transid 13504 /dev/sde1 scanned by udevd (1679) Dec 7 15:37:51 Tower11 kernel: BTRFS: device fsid 99c55241-a0cf-4003-b66d-73512686ce4e devid 2 transid 34 /dev/sdh1 scanned by udevd (1512) Devices with the same fsid are from the same pool.

If it boots in safe mode it's suggests a plugin issue, remove/rename all *.plg files in the flash drive then see if boots, if yes start installing them one by one.

Yep.

It's been a while since I did that but no trick was needed, after a pool is created you just mount one of the devices with UD and the others would mount together, in the pool, not UD, with UD you just saw one device mounted, a btrfs pool can be mounted with any of the member devices. Why not use the multiple pools option in Unraid?

That's normal since the rebuild started with the new disk and filesystem was expanded, you now need to use another 10TB (or larger) drive as replacement, other than that there's no problem unless another disk fails, and with so many disks I would recommend dual parity.

https://forums.unraid.net/topic/86337-are-my-smart-reports-bad/?do=findComment&comment=800888

It's quite common to be non zero with some Seagates, and like mentioned that attribute by itself it's generally not an issue.