155 lines
5.3 KiB
Markdown
155 lines
5.3 KiB
Markdown
# Problems with the AutoYaST Storage Schema
|
|
|
|
The AutoYaST schema is far from ideal and it presents some structural problems. For that reason,
|
|
Agama offers its own storage schema following similar principles but a different approach at several
|
|
levels.
|
|
|
|
This document explains some of the problems that caused the AutoYaST schema (or an hypothetical
|
|
compatible one) to be discarded as the main schema for Agama.
|
|
|
|
## Everything Is a Drive or a Partition Section
|
|
|
|
This could seem a minor detail, but it has several implications:
|
|
|
|
* A `<type>` property is required to indicated the type of device (*RAID*, *LVM*, etc).
|
|
* Some properties could be meaningless for the selected type.
|
|
* Having a `<partitions>` section for describing logical volumes is weird.
|
|
|
|
~~~xml
|
|
<partitioning config:type="list">
|
|
<drive>
|
|
<type config:type="symbol">CT_LVM</type>
|
|
<disklabel>gpt</disklabel> <!-- It does not make sense for a volume group -->
|
|
<partitions config:type="list"> <!-- It really means logical volumes -->
|
|
<partition>
|
|
<partition_id>131</partition_id> <!-- It does not make sense for a logical volume -->
|
|
</partition>
|
|
</partitions>
|
|
</drive>
|
|
</partitioning>
|
|
~~~
|
|
|
|
## Directly Formatting Devices is Hammered
|
|
|
|
A `<partitions>` section is still needed for directly formatting a device, which shows the abuse of
|
|
the schema.
|
|
|
|
~~~xml
|
|
<partitioning config:type="list">
|
|
<drive>
|
|
<disklabel>none</disklabel>
|
|
<partitions config:type="list">
|
|
<partition>
|
|
<filesystem config:type="symbol">btrfs</filesystem>
|
|
</partition>
|
|
</partitions>
|
|
</drive>
|
|
</partitioning>
|
|
~~~
|
|
|
|
## Selecting Devices is Difficult and Limited
|
|
|
|
The AutoYaST schema allows selecting specific devices by using the `<skip_list>` property. This
|
|
forces to use inverse logic when looking for a device. For example, if you want to select a disk
|
|
bigger than 1 GiB, then you have to skip the smaller disks:
|
|
|
|
~~~xml
|
|
<partitioning config:type="list">
|
|
<drive>
|
|
<skip_list config:type="list">
|
|
<!-- skip devices that are smaller than 1GB -->
|
|
<listentry>
|
|
<skip_key>size_k</skip_key>
|
|
<skip_value>1048576</skip_value>
|
|
<skip_if_less_than config:type="boolean">true</skip_if_less_than>
|
|
</listentry>
|
|
</skip_list>
|
|
</drive>
|
|
</partitioning>
|
|
~~~
|
|
|
|
The partitions to remove are selected by means of the `<use>` property, which is very limited. It
|
|
only allows removing everything, nothing, specific partition numbers or linux partitions.
|
|
|
|
~~~xml
|
|
<partitioning config:type="list">
|
|
<drive>
|
|
<device>/dev/sdc</device>
|
|
<use>2</use> <!-- Removes the partition number 2 -->
|
|
<partitions config:type="list">
|
|
...
|
|
</partitions>
|
|
</drive>
|
|
</partitioning>
|
|
~~~
|
|
|
|
The property `<partition_nr>` is used for reusing a partition. Again, this option is very limited,
|
|
allowing selecting a partition only by its number.
|
|
|
|
~~~xml
|
|
<partitioning config:type="list">
|
|
<drive>
|
|
<device>/dev/sdc</device>
|
|
<partitions config:type="list">
|
|
<partition>
|
|
<partition_nr>1</partition_nr> <!-- Reuse the partition number 1 -->
|
|
</partition>
|
|
</partitions>
|
|
</drive>
|
|
</partitioning>
|
|
~~~
|
|
|
|
Note that you could indicate the same partition number for deleting (`<use>`) and for reusing (`<partition_nr>`).
|
|
|
|
## Devices Are Created in a Indirect Way
|
|
|
|
For creating new LVM volume groups, RAIDS, etc, it is necessary to indicate which devices to use as
|
|
logical volumes or as RAID members. In AutoYaST, the partitions have to indicate the device they are
|
|
going to be used by.
|
|
|
|
~~~xml
|
|
<partitioning config:type="list">
|
|
<drive>
|
|
<device>/dev/sda</device>
|
|
<partitions config:type="list">
|
|
<partition>
|
|
<raid_name>/dev/md/0</raid_name> <!-- Indicate what device is going to use it -->
|
|
</partition>
|
|
</partitions>
|
|
</drive>
|
|
<drive>
|
|
<device>/dev/sdb</device>
|
|
<partitions config:type="list">
|
|
<partition>
|
|
<raid_name>/dev/md/0</raid_name>
|
|
</partition>
|
|
</partitions>
|
|
</drive>
|
|
<drive>
|
|
<device>/dev/md/0</device>
|
|
</drive>
|
|
</partitioning>
|
|
~~~
|
|
|
|
It would be more natural to indicate the used devices directly in the RAID or logical volume drive.
|
|
|
|
## Actions to make space must be very explicit
|
|
|
|
There is no way to specify optional actions to be performed on the existing devices, like "resize
|
|
a given partition as much as needed to make space for the new ones" or "delete a partition only if
|
|
necessary" or "grow the existing partition to use the rest of the available space".
|
|
|
|
## MD RAIDs and LVM Volume Groups must be described exhaustively
|
|
|
|
To get a volume group on top of partitions distributed across several disks, the profile must
|
|
specify the partitions that will serve as physical volumes on each disk, including exact sizes.
|
|
That implies that, in order to get fully precise logical volumes, the creator of the profile must
|
|
have some knowledge about the overhead in size introduced by each partition and the corresponding
|
|
physical volume header and also about all the rounding introduced by the LVM logical volumes.
|
|
|
|
Something similar happens with MD RAIDs that sit on top of partitions. The sizes are specified at
|
|
partition level even if the usable size of the resulting MD RAID may not obvious.
|
|
|
|
Of course, the problem accumulates when defining an LVM volume group on top of an MD RAID that sits
|
|
on top of some partitions. All the sizes may match (including all possible overheads and rounding)
|
|
or the result will contain either wasted or surplus space.
|