[RFC LVM2] (0/6) Stacking LVs

[RFC LVM2] (0/6) Stacking LVs

[Jun'ichi Nomura]

Hi,

I'm working on to extend LVM2 to allow an LV with both striped
and mirrored. (e.g. RAID10, RAID0+1)

I think the current direction toward such combination is
stacking LVs internally.
Attached patches allow such stacking by letting lvcreate/lvconvert
to take tagged LVs as source of the extent allocation.
So you can make striped LV on mirrored LVs, mirrored LV on striped LVs,
mirrored mirror log, etc.

The patches are still rough-edge.
I would like to hear comments if this approach is acceptable or not.
Especially, I'm curious about:
  - How much flexibility should the LVM2 allow for stacking?
    Current patch allows basically any combination of
    linear/striped/mirror.
  - Do we explicitly mark the LVs which can be used for stacking?
    Current version implicitly uses LVs if they are specified by
    tag in lvcreate/lvconvert/lvextend command line.
    However, I wonder explicit marking (e.g. lvchange --allocatable y)
    might be safer and allows cleaner implementation.
  - Should we introduce a new structure about free space management?
    Current version uses 'struct physical_volume' as such structure.

The patch set contains 6 patches:
  1) Adding 'const' to the accessor functions of struct physical volume
  2) Adding 'pv_dev_name()' to access the device name of PV
  3) Splitting the allocation/initialization part from _pv_create
  4) Modifying struct lv_segment_area so that AREA_LV segment can
     have a pointer to pv_segment
  5) Allowing striped-LV segment merging
  6) Allowing allocation from tagged LVs

>From 1) to 3) are cosmetic changes.
4) changes the layout of struct lv_segment_area and accessor macros.
5) becomes necessary if we have striped LV over mirrorred LVs
and extend the striped LV.
These are preparation patches and should not affect the current LVM2
functionality.

6) is the core part of the feature.
Attaching struct physical_volume to struct logical_volume when
the LV is used as an allocation source for other LV.

The other things we need may:
  - enhancements to the allocation logic
  - snapshot
      * Currently, snapshot implementation is in strange state.
          o If you do 'lvcreate -s -n lv1 lv0',
            in on-disk metadata, 'lv0' is the origin and
            'lv1' is the cow area. 'snapshotX' is the snapshot.
            While in device-mapper, 'lv1' is the snapshot
            and 'lv1-cow' is the cow.
          o If you resize 'lv1', it resizes the cow area.
            If you change 'lv1' to read-only, it changes the snapshot
            read-only.
        So, what if we would like to add mirror to the snapshot,
        for example?

Thanks,
-- 
Jun'ichi Nomura, NEC Corporation of America

[RFC LVM2] (1/6) Add 'const' to PV accessor functions

[Jun'ichi Nomura]

Accessor functions for PV will not modify the given PV.
So we can add 'const' to it.

Thanks,
-- 
Jun'ichi Nomura, NEC Corporation of America

-------------- next part --------------
A non-text attachment was scrubbed...
Name: lvm2-add-const-to-pv-accessors.patch
Type: text/x-patch
Size: 3289 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/lvm-devel/attachments/20071011/d30fc1d0/attachment.bin>

[RFC LVM2] (2/6) Add pv_dev_name() to access PV device name

[Jun'ichi Nomura]

In the patch "(6/6) Allow allocation from LV",
PV may be attached to LV.
In that case, the LV's name should be used as the PV's device name.

This patch adds pv_dev_name(), which decides whether dev_name(pv->dev)
or LV name should be used, and convert others to use it.

Thanks,
-- 
Jun'ichi Nomura, NEC Corporation of America
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lvm2-pv_dev_name.patch
Type: text/x-patch
Size: 25823 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/lvm-devel/attachments/20071011/f7a3c43d/attachment.bin>

[RFC LVM2] (3/6) Add _pv_allocate() (split from _pv_create)

[Jun'ichi Nomura]

In the patch "(6/6) Allow allocation from LV",
'struct physical_volume' will be allocated from function
other than _pv_create().

This patch splits the allocation/initialization part from
_pv_create().

Thanks,
-- 
Jun'ichi Nomura, NEC Corporation of America
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lvm2-separate-pv_alloc.patch
Type: text/x-patch
Size: 2078 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/lvm-devel/attachments/20071011/0afbb97b/attachment.bin>

[RFC LVM2] (4/6) Add 'pvseg' to AREA_LV lv_segment_area

[Jun'ichi Nomura]

Currently, struct lv_segment_area has a union member and
switches by its type (AREA_PV or AREA_LV).

As a preparation for the patch "(6/6) Allow allocation from LV",
where AREA_LV segment may have pv_segment, this patch changes
struct lv_segment_area.

Thanks,
-- 
Jun'ichi Nomura, NEC Corporation of America
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lvm2-use-pvseg-for-AREA_LV.patch
Type: text/x-patch
Size: 1821 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/lvm-devel/attachments/20071011/851c7091/attachment.bin>

[RFC LVM2] (5/6) Allow merging AREA_LV striped segments

[Jun'ichi Nomura]

Currently, 'striped' segment can only be merged if the segment
is allocated from PV (AREA_PV).

This patch extends the mergeable check to cope with AREA_LV case.

Thanks,
-- 
Jun'ichi Nomura, NEC Corporation of America
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lvm2-merge-striped-lv-seg.patch
Type: text/x-patch
Size: 1182 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/lvm-devel/attachments/20071011/9f6082ce/attachment.bin>

[RFC LVM2] (6/6) Allow allocation from LV

[Jun'ichi Nomura]

This patch allows allocation from LV.

Example 1: striped LV on mirrored LV

# lvcreate -l4 -m1 --corelog testvg
  Logical volume "lvol0" created
# lvcreate -l4 -m1 --corelog testvg
  Logical volume "lvol1" created
# lvchange --addtag m testvg/lvol0 testvg/lvol1
  Logical volume "lvol0" changed
  Logical volume "lvol1" changed
# lvcreate -i2 -l2 testvg @m
  Using default stripesize 64.00 KB
  Logical volume "lvol2" created
# lvextend -l+2 testvg/lvol2 @m
  Using stripesize of last segment 64.00 KB
  Extending logical volume lvol2 to 16.00 MB
  Logical volume lvol2 successfully resized
# lvs -a -o name,attr,devices
  LV               Attr   Devices                            
  [lvol0]          mwi-ao lvol0_mimage_0(0),lvol0_mimage_1(0)
  [lvol0_mimage_0] iwi-ao /dev/mapper/d1(0)                  
  [lvol0_mimage_1] iwi-ao /dev/mapper/d2(0)                  
  [lvol1]          mwi-ao lvol1_mimage_0(0),lvol1_mimage_1(0)
  [lvol1_mimage_0] iwi-ao /dev/mapper/d3(0)                  
  [lvol1_mimage_1] iwi-ao /dev/mapper/d4(0)                  
  lvol2            -wi-a- lvol0(0),lvol1(0)        
# dmsetup ls --tree
testvg-lvol2 (253:15)
 |-testvg-lvol1 (253:14)
 |  |-testvg-lvol1_mimage_1 (253:13)
 |  |  `-d4 (253:4)
 |  |     `- (7:0)
 |  `-testvg-lvol1_mimage_0 (253:12)
 |     `-d3 (253:3)
 |        `- (7:0)
 `-testvg-lvol0 (253:11)
    |-testvg-lvol0_mimage_1 (253:10)
    |  `-d2 (253:2)
    |     `- (7:0)
    `-testvg-lvol0_mimage_0 (253:9)
       `-d1 (253:1)
          `- (7:0)

Example 2: mirrored mirror log

# lvcreate -m1 --corelog -l1 --addtag m testvg
  Logical volume "lvol0" created
# lvcreate -m1 -l1 --corelog testvg
  Logical volume "lvol1" created
# lvconvert --mirrorlog disk testvg/lvol1 @m
  Logical volume lvol1 converted.
# lvs -a -o name,attr,devices
  LV               Attr   Devices                            
  [lvol0]          mwi-ao lvol0_mimage_0(0),lvol0_mimage_1(0)
  [lvol0_mimage_0] iwi-ao /dev/mapper/d1(0)                  
  [lvol0_mimage_1] iwi-ao /dev/mapper/d2(0)                  
  lvol1            mwi-a- lvol1_mimage_0(0),lvol1_mimage_1(0)
  [lvol1_mimage_0] iwi-ao /dev/mapper/d3(0)                  
  [lvol1_mimage_1] iwi-ao /dev/mapper/d4(0)                  
  [lvol1_mlog]     lwi-ao lvol0(0)                      
# dmsetup ls --tree
testvg-lvol1 (253:14)
 |-testvg-lvol1_mimage_1 (253:13)
 |  `-d4 (253:4)
 |     `- (7:0)
 |-testvg-lvol1_mimage_0 (253:12)
 |  `-d3 (253:3)
 |     `- (7:0)
 `-testvg-lvol1_mlog (253:15)
    `-testvg-lvol0 (253:11)
       |-testvg-lvol0_mimage_1 (253:10)
       |  `-d2 (253:2)
       |     `- (7:0)
       `-testvg-lvol0_mimage_0 (253:9)
          `-d1 (253:1)
             `- (7:0)

Thanks,
-- 
Jun'ichi Nomura, NEC Corporation of America
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lvm2-allocate-from-lv.patch
Type: text/x-patch
Size: 11167 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/lvm-devel/attachments/20071011/2b71ee7f/attachment.bin>