(Created page with "= Support installation to some types of degraded RAID volumes = == Summary == Historically, anaconda's position on degraded RAID volumes has been the same as that of hard di...") |
(review doc) |
||
| Line 25: | Line 25: | ||
* What degraded RAID types should be supported? | * What degraded RAID types should be supported? | ||
* Is this a kickstart-only feature or also available in the UI? | * Is this a kickstart-only feature or also available in the UI? | ||
* What impact does this have on the | * What impact does this have on the bootloader installation? | ||
== Benefit to Fedora == | == Benefit to Fedora == | ||
* Supports easy revert to previous installation while retaining RAID mirror | * Supports easy revert to the previous installation while retaining RAID mirror | ||
* Common system administrator use case supported directly | * Common system administrator use case supported directly | ||
Revision as of 00:22, 8 August 2018
Support installation to some types of degraded RAID volumes
Summary
Historically, anaconda's position on degraded RAID volumes has been the same as that of hard disks throwing seek errors: the device is not suitable for use. In some cases, this is legitimate. For example, supporting installation to a degraded RAID-5 array poses a significant risk that could leave the system unbootable. Anaconda does not make design decisions that can leave a system in an unbootable state, which is why we have always taken the position of not supporting installs to degraded RAID volumes.
Older releases of anaconda were slightly less enforcing of this policy than more recent releases, and each time another way in which one can install to a degraded RAID volume is removed, another bug is opened asking for it back. We go back to the original reason that degraded RAID volumes are not suitable for use.
But this does not apply to all types of RAID devices, as explained below.
Owner
Name: David Cantrell
Current status
- Targeted release: TBD
- Last updated: 2012-09-13
- Percentage of completion: 0%
Detailed Description
The legitimate use case explained to me is the one of a simple two disk RAID mirror. When performing an upgrade to a new version of the operating system, the administrator breaks the mirror and performs the installation to only one disk in the array. The administrator now has two bootable volumes, one containing the new operating system and one containing the old. Once the new installation is determined to be acceptable, the administrator will reassemble the RAID volume and resync. Anaconda will not provide any capability to do that, it is entirely up to the administrator post-install.
Unanswered questions:
- What degraded RAID types should be supported?
- Is this a kickstart-only feature or also available in the UI?
- What impact does this have on the bootloader installation?
Benefit to Fedora
- Supports easy revert to the previous installation while retaining RAID mirror
- Common system administrator use case supported directly
Scope
Only valid RAID types as determined in the design. Systems must also meet other criteria for anaconda to recognize and allow installation to the degraded RAID. These criteria will be determined in the design (e.g., a common /boot or not?).
Changes are required in anaconda, _possibly_ dracut as well.
Test Plan
User Experience
Users should not see a change during installation. Depending on the implementation details, the device should become available and anaconda will note that the device belongs to a RAID array but it is currently degraded. The installation would proceed like a regular installation.