Closed phillxnet closed 5 months ago
A 'special case' element of how we currently process the root drive within scan_disks(), that significantly complicates our process, is as follows.
For current btrfs-in-partition data (non system (root=False)) drives we hold the parent drive, i.e. sdg, as canonical and it already has, by way of lsblk most of the info we require: model & serial for example. Upon processing any of its partitions we back-port to the parent block device each partition's fstype and name.
For current system btrfs-in-partition we do almost the opposite. We hold the partition ("/" mount), i.e. sda3 as canonical, and have to forward port (parent devices are listed first in lsblk) some of the info we require to this partition.
There are caveats here however:
Note that fstype, uuid info etc are held by the direct container (the partition if btrfs-in-partition), not the parent. however we still gain simplification if we treat all drives similarly.
Closing as: Fixed by #2835
In the olden days, pre:
we managed only whole disk btrfs, and special cased our system drive as it was partitioned. This is no longer necessary and represents an inconsistency that adds complexity - bringing with it a maintenance burden.
It is proposed that we leverage the work in the interim years re our data dives to apply similarly to our system drive (drives in the future). With the aim of removing legacy special treatment that was originally intended solely to present a partitioned system pool member as if it was a whole disk: the only entity we understood at that time.
I.e. our low-level internal representation from system.osi.scan_disks() for the system disk is presented below. The following are older real-system test data from when our OS pool was labelled
rockstor_rockstor
but otherwise similar. Test reference: https://github.com/rockstor/rockstor-core/blob/4d60a2c683140aaa10a8e5b201157163cc9a898b/src/rockstor/system/tests/test_osi.py#L1072-L1076Where-as the equivalent btrfs-in-partition pool member would be represented as follows:
I.e. normalise on our btrfs-in-partition internal representation and remove our now inconsistent special treatment of the system drive. So that all drives are referenced, at the scan_disk() level, by their base canonical name, not a partition reference (sda, not sda3 in above) and that the system disk, as per all data disks now, carries a
partitions
reference: which in turn would also normalise theparted=True
reference as pertaining to the canonically named "Disk" entry.We still have the potentially inconsistent
fstype=...
element: when dealing with partitioned devices, but this is consistent with our single btrfs partition per device specification/limit.The primary aim here is to simplify our scan_disks() and normalise its output across both system and data drives. This is turn should ease ongoing maintenance (scan_disks() has excessive cyclomatic complexity) and help to accommodate future enhancements such as btrfs multi-device "ROOT" pool capability. It should also help with normalising our pool management at all higher levels in the code: given the OS pool member/s will be akin to our current data pool members.
Check list of proposed approach: