2012-03-16 17:00:05 +04:00
#!/bin/sh
2012-10-09 15:51:30 +04:00
# Copyright (C) 2011-2012 Red Hat, Inc. All rights reserved.
2011-08-11 22:24:40 +04:00
#
# This copyrighted material is made available to anyone wishing to use,
# modify, copy, or redistribute it subject to the terms and conditions
# of the GNU General Public License v.2.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software Foundation,
2016-01-21 13:49:46 +03:00
# Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
2011-08-11 22:24:40 +04:00
2015-10-27 17:10:06 +03:00
SKIP_WITH_LVMPOLLD = 1
2011-08-11 22:24:40 +04:00
2015-10-27 17:10:06 +03:00
. lib/inittest
2015-05-09 02:59:18 +03:00
RAID: Allow implicit stripe (and parity) when creating RAID LVs
There are typically 2 functions for the more advanced segment types that
deal with parameters in lvcreate.c: _get_*_params() and _check_*_params().
(Not all segment types name their functions according to this scheme.)
The former function is responsible for reading parameters before the VG
has been read. The latter is for sanity checking and possibly setting
parameters after the VG has been read.
This patch adds a _check_raid_parameters() function that will determine
if the user has specified 'stripe' or 'mirror' parameters. If not, the
proper number is computed from the list of PVs the user has supplied or
the number that are available in the VG. Now that _check_raid_parameters()
is available, we move the check for proper number of stripes from
_get_* to _check_*.
This gives the user the ability to create RAID LVs as follows:
# 5-device RAID5, 4-data, 1-parity (i.e. implicit '-i 4')
~> lvcreate --type raid5 -L 100G -n lv vg /dev/sd[abcde]1
# 5-device RAID6, 3-data, 2-parity (i.e. implicit '-i 3')
~> lvcreate --type raid6 -L 100G -n lv vg /dev/sd[abcde]1
# If 5 PVs in VG, 4-data, 1-parity RAID5
~> lvcreate --type raid5 -L 100G -n lv vg
Considerations:
This patch only affects RAID. It might also be useful to apply this to
the 'stripe' segment type. LVM RAID may include RAID0 at some point in
the future and the implicit stripes would apply there. It would be odd
to have RAID0 be able to auto-determine the stripe count while 'stripe'
could not.
The only draw-back of this patch that I can see is that there might be
less error checking. Rather than informing the user that they forgot
to supply an argument (e.g. '-i'), the value would be computed and it
may differ from what the user actually wanted. I don't see this as a
problem, because the user can check the device count after creation
and remove the LV if they have made an error.
2014-02-18 06:18:23 +04:00
lv_devices( ) {
2014-05-15 12:25:25 +04:00
test $3 -eq $( get lv_devices $1 /$2 | wc -w)
RAID: Allow implicit stripe (and parity) when creating RAID LVs
There are typically 2 functions for the more advanced segment types that
deal with parameters in lvcreate.c: _get_*_params() and _check_*_params().
(Not all segment types name their functions according to this scheme.)
The former function is responsible for reading parameters before the VG
has been read. The latter is for sanity checking and possibly setting
parameters after the VG has been read.
This patch adds a _check_raid_parameters() function that will determine
if the user has specified 'stripe' or 'mirror' parameters. If not, the
proper number is computed from the list of PVs the user has supplied or
the number that are available in the VG. Now that _check_raid_parameters()
is available, we move the check for proper number of stripes from
_get_* to _check_*.
This gives the user the ability to create RAID LVs as follows:
# 5-device RAID5, 4-data, 1-parity (i.e. implicit '-i 4')
~> lvcreate --type raid5 -L 100G -n lv vg /dev/sd[abcde]1
# 5-device RAID6, 3-data, 2-parity (i.e. implicit '-i 3')
~> lvcreate --type raid6 -L 100G -n lv vg /dev/sd[abcde]1
# If 5 PVs in VG, 4-data, 1-parity RAID5
~> lvcreate --type raid5 -L 100G -n lv vg
Considerations:
This patch only affects RAID. It might also be useful to apply this to
the 'stripe' segment type. LVM RAID may include RAID0 at some point in
the future and the implicit stripes would apply there. It would be odd
to have RAID0 be able to auto-determine the stripe count while 'stripe'
could not.
The only draw-back of this patch that I can see is that there might be
less error checking. Rather than informing the user that they forgot
to supply an argument (e.g. '-i'), the value would be computed and it
may differ from what the user actually wanted. I don't see this as a
problem, because the user can check the device count after creation
and remove the LV if they have made an error.
2014-02-18 06:18:23 +04:00
}
2011-08-11 22:24:40 +04:00
########################################################
# MAIN
########################################################
2014-05-24 00:35:05 +04:00
aux have_raid 1 3 0 || skip
2011-08-11 22:24:40 +04:00
2012-08-25 00:34:19 +04:00
aux prepare_pvs 6 20 # 6 devices for RAID10 (2-mirror,3-stripe) test
2013-05-31 23:11:51 +04:00
vgcreate -s 512k $vg $( cat DEVICES)
2011-08-11 22:24:40 +04:00
###########################################
# Create, wait for sync, remove tests
###########################################
# Create RAID1 (implicit 2-way)
lvcreate --type raid1 -l 2 -n $lv1 $vg
2012-07-24 23:20:30 +04:00
aux wait_for_sync $vg $lv1
2011-08-11 22:24:40 +04:00
lvremove -ff $vg
# Create RAID1 (explicit 2-way)
lvcreate --type raid1 -m 1 -l 2 -n $lv1 $vg
2012-07-24 23:20:30 +04:00
aux wait_for_sync $vg $lv1
2011-08-11 22:24:40 +04:00
lvremove -ff $vg
# Create RAID1 (explicit 3-way)
lvcreate --type raid1 -m 2 -l 2 -n $lv1 $vg
2012-07-24 23:20:30 +04:00
aux wait_for_sync $vg $lv1
2011-08-11 22:24:40 +04:00
lvremove -ff $vg
2013-08-10 02:09:47 +04:00
# Create RAID1 (explicit 3-way) - Set min/max recovery rate
lvcreate --type raid1 -m 2 -l 2 \
2014-05-15 12:25:25 +04:00
--minrecoveryrate 50 --maxrecoveryrate 1M \
2013-08-10 02:09:47 +04:00
-n $lv1 $vg
2013-09-16 13:15:38 +04:00
check lv_field $vg /$lv1 raid_min_recovery_rate 50
2014-05-15 12:25:25 +04:00
check lv_field $vg /$lv1 raid_max_recovery_rate 1024
2013-08-10 02:09:47 +04:00
aux wait_for_sync $vg $lv1
lvremove -ff $vg
2011-08-11 22:24:40 +04:00
# Create RAID 4/5/6 (explicit 3-stripe + parity devs)
for i in raid4 \
raid5 raid5_ls raid5_la raid5_rs raid5_ra \
raid6 raid6_zr raid6_nr raid6_nc; do
lvcreate --type $i -l 3 -i 3 -n $lv1 $vg
2012-07-24 23:20:30 +04:00
aux wait_for_sync $vg $lv1
2011-08-11 22:24:40 +04:00
lvremove -ff $vg
done
2013-08-10 02:09:47 +04:00
# Create RAID 4/5/6 (explicit 3-stripe + parity devs) - Set min/max recovery
for i in raid4 \
raid5 raid5_ls raid5_la raid5_rs raid5_ra \
raid6 raid6_zr raid6_nr raid6_nc; do
lvcreate --type $i -l 3 -i 3 \
2014-05-15 12:25:25 +04:00
--minrecoveryrate 50 --maxrecoveryrate 1M \
2013-08-10 02:09:47 +04:00
-n $lv1 $vg
2013-09-16 13:15:38 +04:00
check lv_field $vg /$lv1 raid_min_recovery_rate 50
2014-05-15 12:25:25 +04:00
check lv_field $vg /$lv1 raid_max_recovery_rate 1024
2013-08-10 02:09:47 +04:00
aux wait_for_sync $vg $lv1
lvremove -ff $vg
done
2014-02-14 07:10:28 +04:00
# Create RAID using 100%FREE
############################
2014-09-14 13:46:13 +04:00
# 6 PVs with 19m in each PV.
2014-02-14 07:10:28 +04:00
# 1 metadata LV = 1 extent = .5m
2014-09-14 13:46:13 +04:00
# 1 image = 37+38+38 extents = 56.50m = lv_size
2014-05-15 12:25:25 +04:00
lvcreate --type raid1 -m 1 -l 100%FREE -an -Zn -n raid1 $vg
2014-09-14 13:46:13 +04:00
check lv_field $vg /raid1 size "56.50m"
2014-02-14 07:10:28 +04:00
lvremove -ff $vg
# 1 metadata LV = 1 extent
2015-05-18 11:16:09 +03:00
# 1 image = 37 extents = 18.5m
# 5 images = 185 extents = 92.5m = lv_size
lvs -a $vg
2014-05-15 12:25:25 +04:00
lvcreate --type raid5 -i 5 -l 100%FREE -an -Zn -n raid5 $vg
2015-05-18 11:16:09 +03:00
check lv_field $vg /raid5 size "92.50m"
2014-02-14 07:10:28 +04:00
lvremove -ff $vg
2014-09-14 13:46:13 +04:00
# 1 image = 37+38 extents
# 2 images = 150 extents = 75.00m = lv_size
2014-05-15 12:25:25 +04:00
lvcreate --type raid5 -i 2 -l 100%FREE -an -Zn -n raid5 $vg
2014-09-14 13:46:13 +04:00
check lv_field $vg /raid5 size "75.00m"
2014-02-14 07:10:28 +04:00
lvremove -ff $vg
2014-09-14 13:46:13 +04:00
# 1 image = 37 extents
# 4 images = 148 extents = 74.00m = lv_size
2014-05-15 12:25:25 +04:00
lvcreate --type raid6 -i 4 -l 100%FREE -an -Zn -n raid6 $vg
2015-05-18 11:16:09 +03:00
check lv_field $vg /raid6 size "74.00m"
2014-02-14 07:10:28 +04:00
lvremove -ff $vg
2014-05-15 12:25:25 +04:00
###
# For following tests eat 18 of 37 extents from dev1, leaving 19
lvcreate -l 18 -an -Zn -n eat_space $vg " $dev1 "
EAT_SIZE = $( get lv_field $vg /eat_space size)
2014-02-14 07:10:28 +04:00
# Using 100% free should take the rest of dev1 and equal from dev2
# 1 meta takes 1 extent
2014-09-14 13:46:13 +04:00
# 1 image = 19 extents = 9.50m = lv_size
2014-05-15 12:25:25 +04:00
lvcreate --type raid1 -m 1 -l 100%FREE -an -Zn -n raid1 $vg " $dev1 " " $dev2 "
2014-09-14 13:46:13 +04:00
check lv_field $vg /raid1 size "9.50m"
2014-02-14 07:10:28 +04:00
# Ensure image size is the same as the RAID1 size
2014-03-28 03:39:55 +04:00
check lv_field $vg /raid1 size $( get lv_field $vg /raid1_rimage_0 size -a)
2014-02-14 07:10:28 +04:00
# Amount remaining in dev2 should equal the amount taken by 'lv' in dev1
2014-05-15 12:25:25 +04:00
check pv_field " $dev2 " pv_free " $EAT_SIZE "
lvremove -ff $vg /raid1
2014-02-14 07:10:28 +04:00
# Using 100% free should take the rest of dev1 and equal amount from the rest
# 1 meta takes 1 extent
2014-09-14 13:46:13 +04:00
# 1 image = 19 extents = 9.50m
# 5 images = 95 extents = 47.50m = lv_size
2014-05-15 12:25:25 +04:00
lvcreate --type raid5 -i 5 -l 100%FREE -an -Zn -n raid5 $vg
2014-09-14 13:46:13 +04:00
check lv_field $vg /raid5 size "47.50m"
2014-02-14 07:10:28 +04:00
# Amount remaining in dev6 should equal the amount taken by 'lv' in dev1
2014-05-15 12:25:25 +04:00
check pv_field " $dev6 " pv_free " $EAT_SIZE "
lvremove -ff $vg /raid5
2014-02-14 07:10:28 +04:00
# Using 100% free should take the rest of dev1, an equal amount
# from 2 more devs, and all extents from 3 additional devs
# 1 meta takes 1 extent
2014-09-14 13:46:13 +04:00
# 1 image = 19+39 extents
# 2 images = 114 extents = 57.00m = lv_size
2014-05-15 12:25:25 +04:00
lvcreate --type raid5 -i 2 -l 100%FREE -an -Zn -n raid5 $vg
2014-09-14 13:46:13 +04:00
check lv_field $vg /raid5 size "57.00m"
2014-05-15 12:25:25 +04:00
lvremove -ff $vg /raid5
2014-02-14 07:10:28 +04:00
# Let's do some stripe tests too
# Using 100% free should take the rest of dev1 and an equal amount from rest
2014-09-14 13:46:13 +04:00
# 1 image = 20 extents
# 6 images = 120 extents = 60.00m = lv_size
2014-05-15 12:25:25 +04:00
lvcreate -i 6 -l 100%FREE -an -Zn -n stripe $vg
2014-09-14 13:46:13 +04:00
check lv_field $vg /stripe size "60.00m"
2014-05-15 12:25:25 +04:00
lvremove -ff $vg /stripe
2014-02-14 07:10:28 +04:00
# Using 100% free should take the rest of dev1, an equal amount from
# one more dev, and all of the remaining 4
2014-09-14 13:46:13 +04:00
# 1 image = 20+38+38 extents
# 2 images = 192 extents = 96.00m = lv_size
2014-05-15 12:25:25 +04:00
lvcreate -i 2 -l 100%FREE -an -Zn -n stripe $vg
2014-09-14 13:46:13 +04:00
check lv_field $vg /stripe size "96.00m"
2014-05-15 12:25:25 +04:00
2014-02-14 07:10:28 +04:00
lvremove -ff $vg
2014-05-15 12:25:25 +04:00
# end of use of '$vg/eat_space'
###
RAID: Allow implicit stripe (and parity) when creating RAID LVs
There are typically 2 functions for the more advanced segment types that
deal with parameters in lvcreate.c: _get_*_params() and _check_*_params().
(Not all segment types name their functions according to this scheme.)
The former function is responsible for reading parameters before the VG
has been read. The latter is for sanity checking and possibly setting
parameters after the VG has been read.
This patch adds a _check_raid_parameters() function that will determine
if the user has specified 'stripe' or 'mirror' parameters. If not, the
proper number is computed from the list of PVs the user has supplied or
the number that are available in the VG. Now that _check_raid_parameters()
is available, we move the check for proper number of stripes from
_get_* to _check_*.
This gives the user the ability to create RAID LVs as follows:
# 5-device RAID5, 4-data, 1-parity (i.e. implicit '-i 4')
~> lvcreate --type raid5 -L 100G -n lv vg /dev/sd[abcde]1
# 5-device RAID6, 3-data, 2-parity (i.e. implicit '-i 3')
~> lvcreate --type raid6 -L 100G -n lv vg /dev/sd[abcde]1
# If 5 PVs in VG, 4-data, 1-parity RAID5
~> lvcreate --type raid5 -L 100G -n lv vg
Considerations:
This patch only affects RAID. It might also be useful to apply this to
the 'stripe' segment type. LVM RAID may include RAID0 at some point in
the future and the implicit stripes would apply there. It would be odd
to have RAID0 be able to auto-determine the stripe count while 'stripe'
could not.
The only draw-back of this patch that I can see is that there might be
less error checking. Rather than informing the user that they forgot
to supply an argument (e.g. '-i'), the value would be computed and it
may differ from what the user actually wanted. I don't see this as a
problem, because the user can check the device count after creation
and remove the LV if they have made an error.
2014-02-18 06:18:23 +04:00
# Create RAID (implicit stripe count based on PV count)
#######################################################
# Not enough drives
2014-03-20 02:32:25 +04:00
not lvcreate --type raid1 -l1 $vg " $dev1 "
not lvcreate --type raid5 -l2 $vg " $dev1 " " $dev2 "
not lvcreate --type raid6 -l3 $vg " $dev1 " " $dev2 " " $dev3 " " $dev4 "
RAID: Allow implicit stripe (and parity) when creating RAID LVs
There are typically 2 functions for the more advanced segment types that
deal with parameters in lvcreate.c: _get_*_params() and _check_*_params().
(Not all segment types name their functions according to this scheme.)
The former function is responsible for reading parameters before the VG
has been read. The latter is for sanity checking and possibly setting
parameters after the VG has been read.
This patch adds a _check_raid_parameters() function that will determine
if the user has specified 'stripe' or 'mirror' parameters. If not, the
proper number is computed from the list of PVs the user has supplied or
the number that are available in the VG. Now that _check_raid_parameters()
is available, we move the check for proper number of stripes from
_get_* to _check_*.
This gives the user the ability to create RAID LVs as follows:
# 5-device RAID5, 4-data, 1-parity (i.e. implicit '-i 4')
~> lvcreate --type raid5 -L 100G -n lv vg /dev/sd[abcde]1
# 5-device RAID6, 3-data, 2-parity (i.e. implicit '-i 3')
~> lvcreate --type raid6 -L 100G -n lv vg /dev/sd[abcde]1
# If 5 PVs in VG, 4-data, 1-parity RAID5
~> lvcreate --type raid5 -L 100G -n lv vg
Considerations:
This patch only affects RAID. It might also be useful to apply this to
the 'stripe' segment type. LVM RAID may include RAID0 at some point in
the future and the implicit stripes would apply there. It would be odd
to have RAID0 be able to auto-determine the stripe count while 'stripe'
could not.
The only draw-back of this patch that I can see is that there might be
less error checking. Rather than informing the user that they forgot
to supply an argument (e.g. '-i'), the value would be computed and it
may differ from what the user actually wanted. I don't see this as a
problem, because the user can check the device count after creation
and remove the LV if they have made an error.
2014-02-18 06:18:23 +04:00
# Implicit count comes from #PVs given (always 2 for mirror though)
2014-05-15 12:25:25 +04:00
lvcreate --type raid1 -l1 -an -Zn -n raid1 $vg " $dev1 " " $dev2 "
RAID: Allow implicit stripe (and parity) when creating RAID LVs
There are typically 2 functions for the more advanced segment types that
deal with parameters in lvcreate.c: _get_*_params() and _check_*_params().
(Not all segment types name their functions according to this scheme.)
The former function is responsible for reading parameters before the VG
has been read. The latter is for sanity checking and possibly setting
parameters after the VG has been read.
This patch adds a _check_raid_parameters() function that will determine
if the user has specified 'stripe' or 'mirror' parameters. If not, the
proper number is computed from the list of PVs the user has supplied or
the number that are available in the VG. Now that _check_raid_parameters()
is available, we move the check for proper number of stripes from
_get_* to _check_*.
This gives the user the ability to create RAID LVs as follows:
# 5-device RAID5, 4-data, 1-parity (i.e. implicit '-i 4')
~> lvcreate --type raid5 -L 100G -n lv vg /dev/sd[abcde]1
# 5-device RAID6, 3-data, 2-parity (i.e. implicit '-i 3')
~> lvcreate --type raid6 -L 100G -n lv vg /dev/sd[abcde]1
# If 5 PVs in VG, 4-data, 1-parity RAID5
~> lvcreate --type raid5 -L 100G -n lv vg
Considerations:
This patch only affects RAID. It might also be useful to apply this to
the 'stripe' segment type. LVM RAID may include RAID0 at some point in
the future and the implicit stripes would apply there. It would be odd
to have RAID0 be able to auto-determine the stripe count while 'stripe'
could not.
The only draw-back of this patch that I can see is that there might be
less error checking. Rather than informing the user that they forgot
to supply an argument (e.g. '-i'), the value would be computed and it
may differ from what the user actually wanted. I don't see this as a
problem, because the user can check the device count after creation
and remove the LV if they have made an error.
2014-02-18 06:18:23 +04:00
lv_devices $vg raid1 2
2014-05-15 12:25:25 +04:00
lvcreate --type raid5 -l2 -an -Zn -n raid5 $vg " $dev1 " " $dev2 " " $dev3 "
RAID: Allow implicit stripe (and parity) when creating RAID LVs
There are typically 2 functions for the more advanced segment types that
deal with parameters in lvcreate.c: _get_*_params() and _check_*_params().
(Not all segment types name their functions according to this scheme.)
The former function is responsible for reading parameters before the VG
has been read. The latter is for sanity checking and possibly setting
parameters after the VG has been read.
This patch adds a _check_raid_parameters() function that will determine
if the user has specified 'stripe' or 'mirror' parameters. If not, the
proper number is computed from the list of PVs the user has supplied or
the number that are available in the VG. Now that _check_raid_parameters()
is available, we move the check for proper number of stripes from
_get_* to _check_*.
This gives the user the ability to create RAID LVs as follows:
# 5-device RAID5, 4-data, 1-parity (i.e. implicit '-i 4')
~> lvcreate --type raid5 -L 100G -n lv vg /dev/sd[abcde]1
# 5-device RAID6, 3-data, 2-parity (i.e. implicit '-i 3')
~> lvcreate --type raid6 -L 100G -n lv vg /dev/sd[abcde]1
# If 5 PVs in VG, 4-data, 1-parity RAID5
~> lvcreate --type raid5 -L 100G -n lv vg
Considerations:
This patch only affects RAID. It might also be useful to apply this to
the 'stripe' segment type. LVM RAID may include RAID0 at some point in
the future and the implicit stripes would apply there. It would be odd
to have RAID0 be able to auto-determine the stripe count while 'stripe'
could not.
The only draw-back of this patch that I can see is that there might be
less error checking. Rather than informing the user that they forgot
to supply an argument (e.g. '-i'), the value would be computed and it
may differ from what the user actually wanted. I don't see this as a
problem, because the user can check the device count after creation
and remove the LV if they have made an error.
2014-02-18 06:18:23 +04:00
lv_devices $vg raid5 3
2014-05-15 12:25:25 +04:00
lvcreate --type raid6 -l3 -an -Zn -n raid6 $vg " $dev1 " " $dev2 " " $dev3 " " $dev4 " " $dev5 "
RAID: Allow implicit stripe (and parity) when creating RAID LVs
There are typically 2 functions for the more advanced segment types that
deal with parameters in lvcreate.c: _get_*_params() and _check_*_params().
(Not all segment types name their functions according to this scheme.)
The former function is responsible for reading parameters before the VG
has been read. The latter is for sanity checking and possibly setting
parameters after the VG has been read.
This patch adds a _check_raid_parameters() function that will determine
if the user has specified 'stripe' or 'mirror' parameters. If not, the
proper number is computed from the list of PVs the user has supplied or
the number that are available in the VG. Now that _check_raid_parameters()
is available, we move the check for proper number of stripes from
_get_* to _check_*.
This gives the user the ability to create RAID LVs as follows:
# 5-device RAID5, 4-data, 1-parity (i.e. implicit '-i 4')
~> lvcreate --type raid5 -L 100G -n lv vg /dev/sd[abcde]1
# 5-device RAID6, 3-data, 2-parity (i.e. implicit '-i 3')
~> lvcreate --type raid6 -L 100G -n lv vg /dev/sd[abcde]1
# If 5 PVs in VG, 4-data, 1-parity RAID5
~> lvcreate --type raid5 -L 100G -n lv vg
Considerations:
This patch only affects RAID. It might also be useful to apply this to
the 'stripe' segment type. LVM RAID may include RAID0 at some point in
the future and the implicit stripes would apply there. It would be odd
to have RAID0 be able to auto-determine the stripe count while 'stripe'
could not.
The only draw-back of this patch that I can see is that there might be
less error checking. Rather than informing the user that they forgot
to supply an argument (e.g. '-i'), the value would be computed and it
may differ from what the user actually wanted. I don't see this as a
problem, because the user can check the device count after creation
and remove the LV if they have made an error.
2014-02-18 06:18:23 +04:00
lv_devices $vg raid6 5
lvremove -ff $vg
# Implicit count comes from total #PVs in VG (always 2 for mirror though)
2014-05-15 12:25:25 +04:00
lvcreate --type raid1 -l1 -an -Zn -n raid1 $vg
RAID: Allow implicit stripe (and parity) when creating RAID LVs
There are typically 2 functions for the more advanced segment types that
deal with parameters in lvcreate.c: _get_*_params() and _check_*_params().
(Not all segment types name their functions according to this scheme.)
The former function is responsible for reading parameters before the VG
has been read. The latter is for sanity checking and possibly setting
parameters after the VG has been read.
This patch adds a _check_raid_parameters() function that will determine
if the user has specified 'stripe' or 'mirror' parameters. If not, the
proper number is computed from the list of PVs the user has supplied or
the number that are available in the VG. Now that _check_raid_parameters()
is available, we move the check for proper number of stripes from
_get_* to _check_*.
This gives the user the ability to create RAID LVs as follows:
# 5-device RAID5, 4-data, 1-parity (i.e. implicit '-i 4')
~> lvcreate --type raid5 -L 100G -n lv vg /dev/sd[abcde]1
# 5-device RAID6, 3-data, 2-parity (i.e. implicit '-i 3')
~> lvcreate --type raid6 -L 100G -n lv vg /dev/sd[abcde]1
# If 5 PVs in VG, 4-data, 1-parity RAID5
~> lvcreate --type raid5 -L 100G -n lv vg
Considerations:
This patch only affects RAID. It might also be useful to apply this to
the 'stripe' segment type. LVM RAID may include RAID0 at some point in
the future and the implicit stripes would apply there. It would be odd
to have RAID0 be able to auto-determine the stripe count while 'stripe'
could not.
The only draw-back of this patch that I can see is that there might be
less error checking. Rather than informing the user that they forgot
to supply an argument (e.g. '-i'), the value would be computed and it
may differ from what the user actually wanted. I don't see this as a
problem, because the user can check the device count after creation
and remove the LV if they have made an error.
2014-02-18 06:18:23 +04:00
lv_devices $vg raid1 2
2014-05-15 12:25:25 +04:00
lvcreate --type raid5 -l2 -an -Zn -n raid5 $vg
RAID: Allow implicit stripe (and parity) when creating RAID LVs
There are typically 2 functions for the more advanced segment types that
deal with parameters in lvcreate.c: _get_*_params() and _check_*_params().
(Not all segment types name their functions according to this scheme.)
The former function is responsible for reading parameters before the VG
has been read. The latter is for sanity checking and possibly setting
parameters after the VG has been read.
This patch adds a _check_raid_parameters() function that will determine
if the user has specified 'stripe' or 'mirror' parameters. If not, the
proper number is computed from the list of PVs the user has supplied or
the number that are available in the VG. Now that _check_raid_parameters()
is available, we move the check for proper number of stripes from
_get_* to _check_*.
This gives the user the ability to create RAID LVs as follows:
# 5-device RAID5, 4-data, 1-parity (i.e. implicit '-i 4')
~> lvcreate --type raid5 -L 100G -n lv vg /dev/sd[abcde]1
# 5-device RAID6, 3-data, 2-parity (i.e. implicit '-i 3')
~> lvcreate --type raid6 -L 100G -n lv vg /dev/sd[abcde]1
# If 5 PVs in VG, 4-data, 1-parity RAID5
~> lvcreate --type raid5 -L 100G -n lv vg
Considerations:
This patch only affects RAID. It might also be useful to apply this to
the 'stripe' segment type. LVM RAID may include RAID0 at some point in
the future and the implicit stripes would apply there. It would be odd
to have RAID0 be able to auto-determine the stripe count while 'stripe'
could not.
The only draw-back of this patch that I can see is that there might be
less error checking. Rather than informing the user that they forgot
to supply an argument (e.g. '-i'), the value would be computed and it
may differ from what the user actually wanted. I don't see this as a
problem, because the user can check the device count after creation
and remove the LV if they have made an error.
2014-02-18 06:18:23 +04:00
lv_devices $vg raid5 6
2014-05-15 12:25:25 +04:00
lvcreate --type raid6 -l3 -an -Zn -n raid6 $vg
RAID: Allow implicit stripe (and parity) when creating RAID LVs
There are typically 2 functions for the more advanced segment types that
deal with parameters in lvcreate.c: _get_*_params() and _check_*_params().
(Not all segment types name their functions according to this scheme.)
The former function is responsible for reading parameters before the VG
has been read. The latter is for sanity checking and possibly setting
parameters after the VG has been read.
This patch adds a _check_raid_parameters() function that will determine
if the user has specified 'stripe' or 'mirror' parameters. If not, the
proper number is computed from the list of PVs the user has supplied or
the number that are available in the VG. Now that _check_raid_parameters()
is available, we move the check for proper number of stripes from
_get_* to _check_*.
This gives the user the ability to create RAID LVs as follows:
# 5-device RAID5, 4-data, 1-parity (i.e. implicit '-i 4')
~> lvcreate --type raid5 -L 100G -n lv vg /dev/sd[abcde]1
# 5-device RAID6, 3-data, 2-parity (i.e. implicit '-i 3')
~> lvcreate --type raid6 -L 100G -n lv vg /dev/sd[abcde]1
# If 5 PVs in VG, 4-data, 1-parity RAID5
~> lvcreate --type raid5 -L 100G -n lv vg
Considerations:
This patch only affects RAID. It might also be useful to apply this to
the 'stripe' segment type. LVM RAID may include RAID0 at some point in
the future and the implicit stripes would apply there. It would be odd
to have RAID0 be able to auto-determine the stripe count while 'stripe'
could not.
The only draw-back of this patch that I can see is that there might be
less error checking. Rather than informing the user that they forgot
to supply an argument (e.g. '-i'), the value would be computed and it
may differ from what the user actually wanted. I don't see this as a
problem, because the user can check the device count after creation
and remove the LV if they have made an error.
2014-02-18 06:18:23 +04:00
lv_devices $vg raid6 6
2014-02-27 02:25:30 +04:00
vgremove -ff $vg