@Hooloovoo Welcome to the Rockstor community.
Re:
It’s a deliberate design decision. Things are a lot simpler throughout the entire design if we only ever have one btrfs ‘source’ per physical/virtual device.
No half way house I’m afraid. Our Web-UI would be rather confused by this arrangement and would likely then become completely useless. We have to entertain such limitations in order to keep the project’s complexity and testing ‘surface’ from exploding. Plus we have far more pressing issues to address prior to even entertaining this degree of flexibility. Such as was mentioned; extending our far cleaner btrfs-in-partition ‘treatment’ to the system disk. As at least then we extend more easily to cope with a likely more popular capability of multi-disk system pools. But that in itself needs a more mature upstream support.
By all means take a look at our code. But all critical path code, such as the disk/pool/share management must be accompanied by tests and all prior tests must also pass without significant modification. This is a non trivial task given we also support full disk LUKS and bcache (latter untested in 4) and quite the test heritage covering both our older legacy CentOS btrfs system disk arrangement and the far more complex (read comprehensive) openSUSE btrfs arrangement. With the latter encompassing such goodies as boot to snapshot which we currently support, within limits. Along with LUKS on bcache backed devices if need be. Hence the desire to migrate our btrfs-in-partition disk-role based approach to the system drive to simplify things so we might move towards greater flexibility in the mid to long term. But that does not include expanding to more than a single btrfs ‘source’ (partition) per device. There would also be a potential explosion in the options regarding how many disks can be removed / added etc as our entire ‘stack’ is based on this single-device/single-btrfs-source assumption. We would have to re-work our entire limits/warnings/storage distinctions to cope with this change. The scale of this change and it’s lowest level nature (at least in Rockstor’s world) would pretty much rule out any suggested change of this type if submitted without extensive proof across our entire capabilities. Include all user ‘fencing’ and some fairly hairy duplication code we have to maintain.
It is of course doable. I’m just not entertaining a change of this type for quite some time just yet I’m afraid. We must first transition to a modern Django and Python before even considering such things unfortunately. But do stick around as you are not the only one who would like to see greater flexibility, it’s just that we must approach our technical dept first. And in doing so hopefully gain all the goodies that come with that.
A good starting point, and one that may also help with recognising an element of our core design, is the following tecnical wiki entry:
You never know, you may even find a cute way to do exactly as you want here. But again I’m not keen on merging such large changes that don’t address our technical dept for quite some time unfortunately. And we have our Rockstor 4 release to finalise. But there after I will be starting a new testing release/branch with a far newer Django but this branch will be broken as per all early testing releases so there will be again, likely, a long road to the next Stable. However I’m hoping that once we have our Python 2 to 3 in-the-bag we can attract more contributors and that can only be good.
Base flexibility has a habit of exploding the number of permutations unless we can contain it. Our current single btrfs partition per device limit is our current brute-force way of containing these permutations/complexities.
Bit by bit, and thanks for you input and interest here; much appreciated.
Hope that helps, at least to identify where our focus lies currently.