Scrub slowed to a crawl, then locked up system.

OK, so initiating a drive self-test via the GUI found no errors (as also verified via smatrctl -x output).

I did do some "poking around" in the BTRFS structure and noticed this:

root@RN4200B# btrfs filesystem df /data
Data, single: total=27.45TiB, used=26.11TiB
System, RAID1: total=32.00MiB, used=3.84MiB
Metadata, RAID1: total=17.00GiB, used=14.18GiB
Metadata, DUP: total=1.00GiB, used=549.25MiB
GlobalReserve, single: total=512.00MiB, used=0.00B

The metadata for the added MDADM layer is separate in DUP format, not RAID1 with the rest.  I'm not sure if that has anything to do with it, but I don't think it's good. The BTRFS wiki gives this warning:  If the metadata is not converted from the single-device default, it remains as DUP, which does not guarantee that copies of block are on separate devices. If data is not converted it does not have any redundant copies at all.

Now, since the "device" is an MDADM RAID, not a single drive, that's probably not quite so dire.  But it also doesn't seem, right.  It's been a long time since I had a volume with unequal drive sizes, and I may not have even noticed this then, so I don't know if it's normal for a vertically expanded ReadyNAS.  I do have a RAID5 of 12 drives, done by creating it in FlexRAID (with all drives 3TB at that time) and then switching to XRAID, so maybe it would be different in another case.  XRAID likes a 12-drive unit to have RAID6.

I also looked back, and I did do a balance and scrub right after I added the last of the larger drives, and that scrub only took 26 hours.  I don't know for sure if both metadata sections contained data at that point, though the balance should have caused that to be the case.

Any thoughts on whether a btrfs balance start -mconvert=raid1 would help, or how it might affect future expandability?  I did do that on my main NAS when I manually vertically expanded a volume that's in FlexRAID, but I don't have to worry there about maintaining XRAID expandability.  At the time I did that on the manual expansion, I didn't realize that the newly added layer's metadata being in DUP format was "normal".

The next step would be to start pulling drives and testing them in a PC, a long time for my backup system to be down with 8x3TB and 4x6TB drives to test or to destroy the volume and re-create, hoping whatever is causing the prbolem either goes away or shows up with a vengeance.