New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Question about disk layout limitations #2023
Comments
The layout code was designed to handle the following setup (no picture as nice as yours):
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 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. |
Independent of the disk layout complexity (i.e. the dependencies Currently ReaR does not support
|
#2087 (comment) |
Stale issue message |
My question was sufficiently answered. |
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
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
That image shows an example of a higher stack of storage objects
where one kind of storage object (partitions) appear on different levels:
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.
The text was updated successfully, but these errors were encountered: