@pepsov Hello there.
Re:
Indeed, but we have to limit our scope as we have very limited developer ‘resources’ however if you fancy having a look at this, as you have been doing actually:
Hopefully/possibly:
Indeed, I did do some work on supporting mdraid as there was interest in this, however we initially only had support for this in a very limited sense. Our focus is very much on having btrfs manage the disks, i.e. via the pool/pool-members type approach. However we do already have, as you see, some preliminary capabilities regarding the md raid arrangement, but such capability often brings unwelcome complexity and can end-up hinder our progress. E.g. not directly related, but when we added the capability to handle partitions as members we did this ‘properly’ only in the data drives. There is still a kind of special treatment in the system disk regarding partitions. I would very much like to normalise the data disk approach to partitions across to the system disk also. But that is a side line to this but indicative of a need to prioritise ‘stuff’.
However, if you are interested, do take a look at how we ‘handle’ both the ‘meta’ device created by mdraid as well as it’s members, as there are two parts to this issue. Recognising both the members of such multi-level constructions (so they can be labeled as such in the disk place), and their higher order creations, the md0 for example, so they can be included as potential members of pools.
But all this is in the context that if btrfs doesn’t know of a device ‘sturucture’ under it, it is necessarily undermined by that structure. I.e. in mdraid it can and will change data under btrfs unknowing of which copy is correct. Hence our focus on using only btrfs as multi-device manager.
We also, and likely will not for the foreseeable future, support such things as LVM. It’s just too complex and we need to have our focus on keeping things simple.
Take a look at the underlying code in say:
And keep in mind that almos all of that code also has extensive tests to prove their function and to guard against breakages. All code that in-turn uses that code must also be aware. Again the modifications to accomodate md were only aimed at the system drive initially, and are far from complete. But a small extension along the same lines may serve your needs and begin a similar process of enabling more compatibility. But we are likely not to support it officially as it’s just more complexity and more points of failure under the fs that threaten data integrity. But horses for courses and it may be of greater interest.
Also do take note of the following Wiki entry that should also help with what modifications would be required:
Hope that helps and the initial problem is extending the serial retrieval mechanism, which does have tests associated with it so they, in-turn, may help in further development if that is what takes your fancy. Hopefully it’s a ‘sister’ modification to what introduced our fledgling md compatibility, such as it is.