Bug 1335861 - Add basic support to LVM for raid0 using the md-based dm-raid kernel target.
Summary: Add basic support to LVM for raid0 using the md-based dm-raid kernel target.
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: LVM and device-mapper
Classification: Community
Component: lvm2
Version: 2.02.153
Hardware: All
OS: Linux
high
medium
Target Milestone: RHEL 7
: 2016-05
Assignee: Alasdair Kergon
QA Contact: cluster-qe@redhat.com
URL:
Whiteboard:
Depends On:
Blocks: 1191594 1390358
TreeView+ depends on / blocked
 
Reported: 2016-05-13 12:14 UTC by Alasdair Kergon
Modified: 2023-06-29 01:34 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-02-12 19:24:42 UTC
Embargoed:
agk: lvm-technical-solution+
rule-engine: lvm-test-coverage?


Attachments (Terms of Use)

Description Alasdair Kergon 2016-05-13 12:14:01 UTC
Allow the creation and activation of striped volumes using --type raid0.

Extend LVM metadata to store raid0 volumes.

No raid metadata areas are created.

Such LVs may only contain one segment so the number of stripes cannot vary along their length.

Kernel target must be version 1.7 or higher.

Must not break any existing functionality.

Proposed segment metadata:

    segment1 {
            start_extent = 0
            extent_count = 4

            type = "raid0"
            stripe_count = 2
            stripe_size = 128

            raid0_lvs = [
                    "lvol0_rimage_0",
                    "lvol0_rimage_1"
            ]
    }

Comment 1 Heinz Mauelshagen 2016-05-13 12:50:06 UTC
I don't like introducing special lvm2 metadata syntax to
cope with "raid0". Let's use the "raids = ..." one throughout
and avoid adding new syntax when it is not needed:

   segment1 {
           start_extent = 0
           extent_count = 32       # 32 Megabytes

           type = "raid0"
           stripe_count = 2
           stripe_size = 64

           raids = [
                 "-", "lvol0_rimage_0",
                 "-", "lvol0_rimage_1"
           ]
    }

"raid0_meta" will fit into this populating "-" with
metadata devices instead.

Comment 2 Alasdair Kergon 2016-05-13 12:58:04 UTC
Type "raid0_meta" can use the standard "raids" section, but requiring a special "-" placeholder just looks like unnecessary complexity for humans working with metadata.  It's easier for the computer to hide that than to have to explain the difference.

Comment 3 Heinz Mauelshagen 2016-05-13 13:20:06 UTC
(In reply to Alasdair Kergon from comment #2)
> Type "raid0_meta" can use the standard "raids" section, but requiring a
> special "-" placeholder just looks like unnecessary complexity for humans
> working with metadata.  It's easier for the computer to hide that than to
> have to explain the difference.

This tells humans explicitly that there are no metadata devices.

We should avoid introducing special cases wherever possible in order
to limit syntax proliferation.

Using the given "raids = ..." lvm2 metadata syntax does that and
keeps the syntax for all dm-raid mappings rather than special
casing a particular one.

Comment 4 Jonathan Earl Brassow 2016-05-13 21:10:01 UTC
(In reply to Heinz Mauelshagen from comment #3)
> (In reply to Alasdair Kergon from comment #2)
> > Type "raid0_meta" can use the standard "raids" section, but requiring a
> > special "-" placeholder just looks like unnecessary complexity for humans
> > working with metadata.  It's easier for the computer to hide that than to
> > have to explain the difference.
> 
> This tells humans explicitly that there are no metadata devices.
> 
> We should avoid introducing special cases wherever possible in order
> to limit syntax proliferation.
> 
> Using the given "raids = ..." lvm2 metadata syntax does that and
> keeps the syntax for all dm-raid mappings rather than special
> casing a particular one.

Agreed.  Stick with the current RAID metadata format.  RAID0 is part of the same family.

Out of curiosity, would it be smart to use s/"-"/"NoMetaLV"/ instead?

Comment 5 Heinz Mauelshagen 2016-05-17 13:19:40 UTC
(In reply to Jonathan Earl Brassow from comment #4)
> (In reply to Heinz Mauelshagen from comment #3)
> > (In reply to Alasdair Kergon from comment #2)
> > > Type "raid0_meta" can use the standard "raids" section, but requiring a
> > > special "-" placeholder just looks like unnecessary complexity for humans
> > > working with metadata.  It's easier for the computer to hide that than to
> > > have to explain the difference.
> > 
> > This tells humans explicitly that there are no metadata devices.
> > 
> > We should avoid introducing special cases wherever possible in order
> > to limit syntax proliferation.
> > 
> > Using the given "raids = ..." lvm2 metadata syntax does that and
> > keeps the syntax for all dm-raid mappings rather than special
> > casing a particular one.
> 
> Agreed.  Stick with the current RAID metadata format.  RAID0 is part of the
> same family.
> 
> Out of curiosity, would it be smart to use s/"-"/"NoMetaLV"/ instead?

This would enhance human readability but unnecessarily grow the lvm2
test metadata as '-' tells enough.

I'd vote for keeping the '-' as we already have it for missing metadata devices.

If we did not, we'd even have to think about distinguishing between intentionally avoided metadata devices as with 'raid0' and missing ones due to failed PVs with other raid types to be semantically expressive.

Comment 6 Heinz Mauelshagen 2016-05-17 18:34:41 UTC
Based on a discussion, "" would be preferable to "-" for the non-defined
metadata devices, which I'd still prefer over the extra raid0_lvs for this
special case Alasdair prefers.

Comment 7 David Teigland 2016-05-17 18:53:43 UTC
I think the general format is nice and clean.  The way we typically handle human readability is by adding a comment like # no metadata LV.

Comment 8 Heinz Mauelshagen 2016-05-17 18:55:39 UTC
(In reply to David Teigland from comment #7)
> I think the general format is nice and clean.  The way we typically handle
> human readability is by adding a comment like # no metadata LV.

Right, that'd make it clean as with other similarly commented items.

Comment 9 Heinz Mauelshagen 2017-04-11 22:38:58 UTC
Upstream commits
bf8d00985ada723778701530c7ea863c617dda8a
b896f7de1e6773ce6c17bf29a9123276695f4b60
686acce23fed6bd72af63201e4cc56bc5958379e
d8c2677ab92c3c3bd35ccab0d486ebce8db4fbb4


Note You need to log in before you can comment on or make changes to this bug.