#2023 Issue closed: Question about disk layout limitations

Labels: support / question, fixed / solved / done

jsmeix opened issue at 2019-01-23 10:27:

I would like to know what the limitations of disk layout complexity are
where the disk layout can be recreated with our current layout code.

For what I mean with "disk layout complexity" have a look at the section
"Changes in the Partitioner UI to Unleash the Storage-ng Power" in
https://lizards.opensuse.org/2018/10/09/yast-sprint-64/

The image therein
image
shows an (intentional artificial) example of a complex disk layout
that can be created in newest SLES15 with the so called "storage-ng"
partitioner and the storage setup subsystem in YaST.

It contains in particular things like

  • MD RAID that consists of full disks and partitions (e.g. /dev/md1 consists of /dev/sdb and /dev/sda3)
  • MD RAID that contains partitions (e.g. /dev/md1 contains /dev/md1p1 and /dev/md1p2)
  • A disk that is directly formatted with no partitions in between (e.g. there is an ext4 filesystem directly on /dev/sdc that is mounted at /data)

That image shows an example of a higher stack of storage objects
where one kind of storage object (partitions) appear on different levels:

  • mountpoint /home is on top of
  • filesystem ext4 that is on top of
  • partition /dev/md1p1 that is on top of
  • MD RAID /dev/md1 that is on top of two parents
  • disk /dev/sdb (that has no parent) and partition /dev/sda3 that is on top of
  • disk /dev/sda (that has no parent)

Simply put, my question is if ReaR's current layout code is meant
to support arbitrary big mesh-like stacks of storage objects
('mesh-like' because a child can have more than one parent
and 'stack' because there is a hierarchical top-down structure)
or if there are currenly "built-in" limitations.

jsmeix commented at 2019-01-23 10:30:

@schlomo @gdha
I hope you could answer my question.
Perhaps you already experienced generic limitations in our current layout code?

jhoekx commented at 2019-01-23 11:15:

The layout code was designed to handle the following setup (no picture as nice as yours):

HP RAID controller
  /dev/sda
    /dev/sda1
      /boot
    /dev/sda2
      pv
        lv /
        lv ...
        drbd
          pv
            lv /data1
            lv /data2

This means that it should be able to handle arbitrary setups as long as the names of the things are unique. The dependencies between components are used to create the devices in the right order.

jsmeix commented at 2019-01-23 16:21:

@jhoekx
thank you very much for your prompt reply.

Now I will try out (as time permits) to set up such kind of
(intentional artificial) examples of complex disk layout
and see how it works with ReaR.

https://github.com/rear/rear/issues/2086 is a precondition
for efficient testing ReaR with arbitrary disk layouts.

schlomo commented at 2019-01-23 17:03:

@jsmeix IMHO ReaR should support that complexity as I don't see there any new block device types.

If this "storage-ng" introduces a new storage layer with new block devices then we would have to add support for this.

The best way to help ReaR in this context is to create an automated test case that runs for example in a qemu VM.

jsmeix commented at 2019-02-28 08:43:

Independent of the disk layout complexity (i.e. the dependencies
of parents and children in the mesh-like stack of storage objects)
there are limitations what kind of storage objects ReaR can deal with.

Currently ReaR does not support

jsmeix commented at 2019-04-05 07:23:

https://github.com/rear/rear/issues/2087#issuecomment-477551079
shows an example where the current layout code failed
to get the right depencencies between storage objects.

github-actions commented at 2020-06-28 01:33:

Stale issue message

jsmeix commented at 2020-06-29 06:08:

My question was sufficiently answered.

[Export of Github issue for rear/rear.]