Bug 2083410
| Summary: | storage role raid_level "striped" is not supported | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | Rich Megginson <rmeggins> | |
| Component: | rhel-system-roles | Assignee: | Rich Megginson <rmeggins> | |
| Status: | CLOSED ERRATA | QA Contact: | Jakub Haruda <jharuda> | |
| Severity: | unspecified | Docs Contact: | Michal Stubna <mstubna> | |
| Priority: | unspecified | |||
| Version: | 9.0 | CC: | briasmit, gfialova, guazhang, jharuda, nhosoi, pkettman, spetrosi, vtrefny | |
| Target Milestone: | rc | Keywords: | Triaged, ZStream | |
| Target Release: | 9.1 | Flags: | pkettman:
needinfo+
pm-rhel: mirror+ |
|
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | role:storage | |||
| Fixed In Version: | rhel-system-roles-1.19.2-1.el9 | Doc Type: | Bug Fix | |
| Doc Text: |
.The `storage` RHEL System Role now correctly supports striped and raid0 levels for LVM volumes
The `storage` RHEL System Role previously incorrectly reported RAID levels `striped` and `raid0` as not supported for LVM volumes. This is now fixed and the role can now correctly create LVM volumes of all RAID levels supported by LVM: `raid0`, `raid1`, `raid4`, `raid5`, `raid6`, `raid10`, `striped` and `mirror`.
|
Story Points: | --- | |
| Clone Of: | ||||
| : | 2083426 2098223 (view as bug list) | Environment: | ||
| Last Closed: | 2022-11-15 10:23:47 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 2083426, 2098223 | |||
|
Description
Rich Megginson
2022-05-09 23:30:26 UTC
The 'striped' level is in fact an alias for 'raid0' in blivet, but it is only there because the lvm tools use that as a level descriptor (and is therefore not supported for md raid). My recommendation is to fix the role docs by removing 'striped'. I think 'striped' is supported in blivet, but only for lvm raid, and I don't think there is any value in passing that inconsistency on to the role's users. (In reply to David Lehman from comment #1) > The 'striped' level is in fact an alias for 'raid0' in blivet, but it is > only there because the lvm tools use that as a level descriptor (and is > therefore not supported for md raid). My recommendation is to fix the role > docs by removing 'striped'. I think 'striped' is supported in blivet, but > only for lvm raid, and I don't think there is any value in passing that > inconsistency on to the role's users. According to Vojtech: https://github.com/linux-system-roles/storage/pull/271#issuecomment-1122031499 LVM supports only 'striped' for raid0 (and 'mirror' for raid1). This is what the docs currently say: https://github.com/linux-system-roles/storage/#raid_level "raid_level When used with type: lvm it manages a volume group with a mdraid array of given level on it. Input disks are in this case used as RAID members. Accepted values are: linear, striped, raid0, raid1, raid4, raid5, raid6, raid10" Can you use raid_level without `type: lvm`? I guess we will have different lists of values depending on if the type is lvm or not? "raid_level When used with type: lvm it manages a volume group with a mdraid array of given level on it. Input disks are in this case used as RAID members. Accepted values are: linear, striped, mirror, raid4, raid5, raid6, raid10. Wither other types (what other types?) the accepted values are: raid0, raid1, raid4, raid5, raid6, raid10. " or something like that? I'm not really sure what to put here. Looks like my comment on GitHub made it more confusing, sorry. LVM supports both striped/mirror and raid0/raid1. striped and mirror are legacy types and I'm not sure how different is striped from raid0 internally, but LVM still recognizes these as two different types of LVs and allows converting between them (same applies to mirror and raid1). But raid0 and raid1 should be preferred when creating a new LV and I agree with Dave that we should remove striped this from the documentation to make it less complicated for users. The problem is that blivet doesn't support creating "raid0" LVs, but that's an internal issue which needs to be fixed in blivet. So is this all we need to do? diff --git a/README.md b/README.md index 04a895d..3565c8e 100644 --- a/README.md +++ b/README.md @@ -53,7 +53,7 @@ device node basename (like `sda` or `mpathb`), /dev/disk/ symlink ##### `raid_level` When used with `type: lvm` it manages a volume group with a mdraid array of given level on it. Input `disks` are in this case used as RAID members. -Accepted values are: `linear`, `striped`, `raid0`, `raid1`, `raid4`, `raid5`, `raid6`, `raid10` +Accepted values are: `linear`, `raid0`, `raid1`, `raid4`, `raid5`, `raid6`, `raid10` ##### `volumes` This is a list of volumes that belong to the current pool. It follows the @@ -135,7 +135,7 @@ Specifies RAID level. LVM RAID can be created as well. "Regular" RAID volume requires type to be `raid`. LVM RAID needs that volume has `storage_pools` parent with type `lvm`, `raid_disks` need to be specified as well. -Accepted values are: `linear` (N/A for LVM RAID), `striped`, `raid0`, `raid1`, `raid4`, `raid5`, `raid6`, `raid10` +Accepted values are: `linear` (N/A for LVM RAID), `raid0`, `raid1`, `raid4`, `raid5`, `raid6`, `raid10` ? rhel-system-roles-1.19.0-1.el9.noarch 5.14.0-105.el9.x86_64 test pass with tests_create_raid_pool_then_remove.yml Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (rhel-system-roles bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2022:8117 |