2012-10-09 18:32:11 +04:00
#!/bin/sh
# Copyright (C) 2012 Red Hat, Inc. All rights reserved.
#
# 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
2012-10-09 18:32:11 +04:00
2016-02-23 01:13:42 +03:00
SKIP_WITH_LVMLOCKD = 1
2015-10-27 17:10:06 +03:00
SKIP_WITH_LVMPOLLD = 1
2015-05-18 11:14:12 +03:00
export LVM_TEST_THIN_REPAIR_CMD = ${ LVM_TEST_THIN_REPAIR_CMD -/bin/false }
2014-06-06 19:40:04 +04:00
. lib/inittest
2012-10-09 18:32:11 +04:00
2014-07-11 14:15:46 +04:00
prepare_lvs( ) {
2012-11-19 15:31:11 +04:00
lvremove -f $vg
lvcreate -L10M -n $lv1 $vg
lvcreate -L8M -n $lv2 $vg
}
2012-10-09 18:32:11 +04:00
#
# Main
#
2012-10-10 02:20:22 +04:00
aux have_thin 1 0 0 || skip
2012-10-09 18:32:11 +04:00
2012-11-27 04:01:38 +04:00
aux prepare_pvs 4 64
2012-10-09 18:32:11 +04:00
2012-11-27 04:01:38 +04:00
# build one large PV
2014-06-06 01:05:52 +04:00
vgcreate $vg1 $( head -n 3 DEVICES)
2014-10-06 13:56:09 +04:00
2013-11-16 02:47:14 +04:00
# 32bit linux kernels are fragille with device size >= 16T
# maybe uname -m [ x86_64 | i686 ]
TSIZE = 64T
aux can_use_16T || TSIZE = 15T
2015-07-04 12:41:04 +03:00
lvcreate --type snapshot -l 100%FREE -n $lv $vg1 --virtualsize $TSIZE
2013-05-27 04:03:00 +04:00
aux extend_filter_LVMTEST
2012-11-27 04:01:38 +04:00
pvcreate " $DM_DEV_DIR / $vg1 / $lv "
2014-06-06 01:05:52 +04:00
vgcreate $vg -s 64K $( tail -n+4 DEVICES) " $DM_DEV_DIR / $vg1 / $lv "
2012-10-09 18:32:11 +04:00
2014-07-11 14:15:46 +04:00
lvcreate -L1T -n $lv1 $vg
invalid lvconvert --yes -c 8M --type thin --poolmetadatasize 1G $vg /$lv1
# needs some --cachepool or --thinpool
invalid lvconvert --yes --poolmetadatasize 1G $vg /$lv1
lvremove -f $vg
2012-10-09 18:32:11 +04:00
# create mirrored LVs for data and metadata volumes
2013-08-08 00:48:31 +04:00
lvcreate -aey -L10M --type mirror -m1 --mirrorlog core -n $lv1 $vg
Mirror/Thin: Disallow thinpools on mirror logical volumes
The same corner cases that exist for snapshots on mirrors exist for
any logical volume layered on top of mirror. (One example is when
a mirror image fails and a non-repair LVM command is the first to
detect it via label reading. In this case, the LVM command will hang
and prevent the necessary LVM repair command from running.) When
a better alternative exists, it makes no sense to allow a new target
to stack on mirrors as a new feature. Since, RAID is now capable of
running EX in a cluster and thin is not active-active aware, it makes
sense to pair these two rather than mirror+thinpool.
As further background, here are some additional comments that I made
when addressing a bug related to mirror+thinpool:
(https://bugzilla.redhat.com/show_bug.cgi?id=919604#c9)
I am going to disallow thin* on top of mirror logical volumes.
Users will have to use the "raid1" segment type if they want this.
This bug has come down to a choice between:
1) Disallowing thin-LVs from being used as PVs.
2) Disallowing thinpools on top of mirrors.
The problem is that the code in dev_manager.c:device_is_usable() is unable
to tell whether there is a mirror device lower in the stack from the device
being checked. Pretty much anything layered on top of a mirror will suffer
from this problem. (Snapshots are a good example of this; and option #1
above has been chosen to deal with them. This can also be seen in
dev_manager.c:device_is_usable().) When a mirror failure occurs, the
kernel blocks all I/O to it. If there is an LVM command that comes along
to do the repair (or a different operation that requires label reading), it
would normally avoid the mirror when it sees that it is blocked. However,
if there is a snapshot or a thin-LV that is on a mirror, the above code
will not detect the mirror underneath and will issue label reading I/O.
This causes the command to hang.
Choosing #1 would mean that thin-LVs could never be used as PVs - even if
they are stacked on something other than mirrors.
Choosing #2 means that thinpools can never be placed on mirrors. This is
probably better than we think, since it is preferred that people use the
"raid1" segment type in the first place. However, RAID* cannot currently
be used in a cluster volume group - even in EX-only mode. Thus, a complete
solution for option #2 must include the ability to activate RAID logical
volumes (and perform RAID operations) in a cluster volume group. I've
already begun working on this.
2013-09-12 00:58:44 +04:00
lvcreate -aey -L10M -n $lv2 $vg
2012-11-19 15:31:11 +04:00
lvchange -an $vg /$lv1
Mirror/Thin: Disallow thinpools on mirror logical volumes
The same corner cases that exist for snapshots on mirrors exist for
any logical volume layered on top of mirror. (One example is when
a mirror image fails and a non-repair LVM command is the first to
detect it via label reading. In this case, the LVM command will hang
and prevent the necessary LVM repair command from running.) When
a better alternative exists, it makes no sense to allow a new target
to stack on mirrors as a new feature. Since, RAID is now capable of
running EX in a cluster and thin is not active-active aware, it makes
sense to pair these two rather than mirror+thinpool.
As further background, here are some additional comments that I made
when addressing a bug related to mirror+thinpool:
(https://bugzilla.redhat.com/show_bug.cgi?id=919604#c9)
I am going to disallow thin* on top of mirror logical volumes.
Users will have to use the "raid1" segment type if they want this.
This bug has come down to a choice between:
1) Disallowing thin-LVs from being used as PVs.
2) Disallowing thinpools on top of mirrors.
The problem is that the code in dev_manager.c:device_is_usable() is unable
to tell whether there is a mirror device lower in the stack from the device
being checked. Pretty much anything layered on top of a mirror will suffer
from this problem. (Snapshots are a good example of this; and option #1
above has been chosen to deal with them. This can also be seen in
dev_manager.c:device_is_usable().) When a mirror failure occurs, the
kernel blocks all I/O to it. If there is an LVM command that comes along
to do the repair (or a different operation that requires label reading), it
would normally avoid the mirror when it sees that it is blocked. However,
if there is a snapshot or a thin-LV that is on a mirror, the above code
will not detect the mirror underneath and will issue label reading I/O.
This causes the command to hang.
Choosing #1 would mean that thin-LVs could never be used as PVs - even if
they are stacked on something other than mirrors.
Choosing #2 means that thinpools can never be placed on mirrors. This is
probably better than we think, since it is preferred that people use the
"raid1" segment type in the first place. However, RAID* cannot currently
be used in a cluster volume group - even in EX-only mode. Thus, a complete
solution for option #2 must include the ability to activate RAID logical
volumes (and perform RAID operations) in a cluster volume group. I've
already begun working on this.
2013-09-12 00:58:44 +04:00
# conversion fails for mirror segment type
2014-05-20 23:11:11 +04:00
fail lvconvert --thinpool $vg /$lv1
# cannot use same LV
commands: new method for defining commands
. Define a prototype for every lvm command.
. Match every user command with one definition.
. Generate help text and man pages from them.
The new file command-lines.in defines a prototype for every
unique lvm command. A unique lvm command is a unique
combination of: command name + required option args +
required positional args. Each of these prototypes also
includes the optional option args and optional positional
args that the command will accept, a description, and a
unique string ID for the definition. Any valid command
will match one of the prototypes.
Here's an example of the lvresize command definitions from
command-lines.in, there are three unique lvresize commands:
lvresize --size SizeMB LV
OO: --alloc Alloc, --autobackup Bool, --force,
--nofsck, --nosync, --noudevsync, --reportformat String, --resizefs,
--stripes Number, --stripesize SizeKB, --poolmetadatasize SizeMB
OP: PV ...
ID: lvresize_by_size
DESC: Resize an LV by a specified size.
lvresize LV PV ...
OO: --alloc Alloc, --autobackup Bool, --force,
--nofsck, --nosync, --noudevsync,
--reportformat String, --resizefs, --stripes Number, --stripesize SizeKB
ID: lvresize_by_pv
DESC: Resize an LV by specified PV extents.
FLAGS: SECONDARY_SYNTAX
lvresize --poolmetadatasize SizeMB LV_thinpool
OO: --alloc Alloc, --autobackup Bool, --force,
--nofsck, --nosync, --noudevsync,
--reportformat String, --stripes Number, --stripesize SizeKB
OP: PV ...
ID: lvresize_pool_metadata_by_size
DESC: Resize a pool metadata SubLV by a specified size.
The three commands have separate definitions because they have
different required parameters. Required parameters are specified
on the first line of the definition. Optional options are
listed after OO, and optional positional args are listed after OP.
This data is used to generate corresponding command definition
structures for lvm in command-lines.h. usage/help output is also
auto generated, so it is always in sync with the definitions.
Every user-entered command is compared against the set of
command structures, and matched with one. An error is
reported if an entered command does not have the required
parameters for any definition. The closest match is printed
as a suggestion, and running lvresize --help will display
the usage for each possible lvresize command.
The prototype syntax used for help/man output includes
required --option and positional args on the first line,
and optional --option and positional args enclosed in [ ]
on subsequent lines.
command_name <required_opt_args> <required_pos_args>
[ <optional_opt_args> ]
[ <optional_pos_args> ]
Command definitions that are not to be advertised/suggested
have the flag SECONDARY_SYNTAX. These commands will not be
printed in the normal help output.
Man page prototypes are also generated from the same original
command definitions, and are always in sync with the code
and help text.
Very early in command execution, a matching command definition
is found. lvm then knows the operation being done, and that
the provided args conform to the definition. This will allow
lots of ad hoc checking/validation to be removed throughout
the code.
Each command definition can also be routed to a specific
function to implement it. The function is associated with
an enum value for the command definition (generated from
the ID string.) These per-command-definition implementation
functions have not yet been created, so all commands
currently fall back to the existing per-command-name
implementation functions.
Using per-command-definition functions will allow lots of
code to be removed which tries to figure out what the
command is meant to do. This is currently based on ad hoc
and complicated option analysis. When using the new
functions, what the command is doing is already known
from the associated command definition.
2016-08-12 23:52:18 +03:00
not lvconvert --yes --thinpool $vg /$lv2 --poolmetadata $vg /$lv2
Mirror/Thin: Disallow thinpools on mirror logical volumes
The same corner cases that exist for snapshots on mirrors exist for
any logical volume layered on top of mirror. (One example is when
a mirror image fails and a non-repair LVM command is the first to
detect it via label reading. In this case, the LVM command will hang
and prevent the necessary LVM repair command from running.) When
a better alternative exists, it makes no sense to allow a new target
to stack on mirrors as a new feature. Since, RAID is now capable of
running EX in a cluster and thin is not active-active aware, it makes
sense to pair these two rather than mirror+thinpool.
As further background, here are some additional comments that I made
when addressing a bug related to mirror+thinpool:
(https://bugzilla.redhat.com/show_bug.cgi?id=919604#c9)
I am going to disallow thin* on top of mirror logical volumes.
Users will have to use the "raid1" segment type if they want this.
This bug has come down to a choice between:
1) Disallowing thin-LVs from being used as PVs.
2) Disallowing thinpools on top of mirrors.
The problem is that the code in dev_manager.c:device_is_usable() is unable
to tell whether there is a mirror device lower in the stack from the device
being checked. Pretty much anything layered on top of a mirror will suffer
from this problem. (Snapshots are a good example of this; and option #1
above has been chosen to deal with them. This can also be seen in
dev_manager.c:device_is_usable().) When a mirror failure occurs, the
kernel blocks all I/O to it. If there is an LVM command that comes along
to do the repair (or a different operation that requires label reading), it
would normally avoid the mirror when it sees that it is blocked. However,
if there is a snapshot or a thin-LV that is on a mirror, the above code
will not detect the mirror underneath and will issue label reading I/O.
This causes the command to hang.
Choosing #1 would mean that thin-LVs could never be used as PVs - even if
they are stacked on something other than mirrors.
Choosing #2 means that thinpools can never be placed on mirrors. This is
probably better than we think, since it is preferred that people use the
"raid1" segment type in the first place. However, RAID* cannot currently
be used in a cluster volume group - even in EX-only mode. Thus, a complete
solution for option #2 must include the ability to activate RAID logical
volumes (and perform RAID operations) in a cluster volume group. I've
already begun working on this.
2013-09-12 00:58:44 +04:00
2014-05-20 23:11:11 +04:00
prepare_lvs
2012-11-19 15:31:11 +04:00
# conversion fails for internal volumes
# can't use --readahead with --poolmetadata
commands: new method for defining commands
. Define a prototype for every lvm command.
. Match every user command with one definition.
. Generate help text and man pages from them.
The new file command-lines.in defines a prototype for every
unique lvm command. A unique lvm command is a unique
combination of: command name + required option args +
required positional args. Each of these prototypes also
includes the optional option args and optional positional
args that the command will accept, a description, and a
unique string ID for the definition. Any valid command
will match one of the prototypes.
Here's an example of the lvresize command definitions from
command-lines.in, there are three unique lvresize commands:
lvresize --size SizeMB LV
OO: --alloc Alloc, --autobackup Bool, --force,
--nofsck, --nosync, --noudevsync, --reportformat String, --resizefs,
--stripes Number, --stripesize SizeKB, --poolmetadatasize SizeMB
OP: PV ...
ID: lvresize_by_size
DESC: Resize an LV by a specified size.
lvresize LV PV ...
OO: --alloc Alloc, --autobackup Bool, --force,
--nofsck, --nosync, --noudevsync,
--reportformat String, --resizefs, --stripes Number, --stripesize SizeKB
ID: lvresize_by_pv
DESC: Resize an LV by specified PV extents.
FLAGS: SECONDARY_SYNTAX
lvresize --poolmetadatasize SizeMB LV_thinpool
OO: --alloc Alloc, --autobackup Bool, --force,
--nofsck, --nosync, --noudevsync,
--reportformat String, --stripes Number, --stripesize SizeKB
OP: PV ...
ID: lvresize_pool_metadata_by_size
DESC: Resize a pool metadata SubLV by a specified size.
The three commands have separate definitions because they have
different required parameters. Required parameters are specified
on the first line of the definition. Optional options are
listed after OO, and optional positional args are listed after OP.
This data is used to generate corresponding command definition
structures for lvm in command-lines.h. usage/help output is also
auto generated, so it is always in sync with the definitions.
Every user-entered command is compared against the set of
command structures, and matched with one. An error is
reported if an entered command does not have the required
parameters for any definition. The closest match is printed
as a suggestion, and running lvresize --help will display
the usage for each possible lvresize command.
The prototype syntax used for help/man output includes
required --option and positional args on the first line,
and optional --option and positional args enclosed in [ ]
on subsequent lines.
command_name <required_opt_args> <required_pos_args>
[ <optional_opt_args> ]
[ <optional_pos_args> ]
Command definitions that are not to be advertised/suggested
have the flag SECONDARY_SYNTAX. These commands will not be
printed in the normal help output.
Man page prototypes are also generated from the same original
command definitions, and are always in sync with the code
and help text.
Very early in command execution, a matching command definition
is found. lvm then knows the operation being done, and that
the provided args conform to the definition. This will allow
lots of ad hoc checking/validation to be removed throughout
the code.
Each command definition can also be routed to a specific
function to implement it. The function is associated with
an enum value for the command definition (generated from
the ID string.) These per-command-definition implementation
functions have not yet been created, so all commands
currently fall back to the existing per-command-name
implementation functions.
Using per-command-definition functions will allow lots of
code to be removed which tries to figure out what the
command is meant to do. This is currently based on ad hoc
and complicated option analysis. When using the new
functions, what the command is doing is already known
from the associated command definition.
2016-08-12 23:52:18 +03:00
not lvconvert --thinpool $vg /$lv1 --poolmetadata $vg /$lv2 --readahead 512
2014-05-20 23:11:11 +04:00
lvconvert --yes --thinpool $vg /$lv1 --poolmetadata $vg /$lv2
2012-11-19 15:31:11 +04:00
prepare_lvs
2014-05-20 23:11:11 +04:00
lvconvert --yes -c 64 --stripes 2 --thinpool $vg /$lv1 --readahead 48
2012-11-19 15:31:11 +04:00
lvremove -f $vg
2014-10-06 13:56:09 +04:00
# Swaping of metadata volume
lvcreate -L1T -n $lv1 $vg
lvcreate -L32 -n $lv2 $vg
2015-05-14 11:20:24 +03:00
lvconvert --yes -c 8M --type thin-pool $vg /$lv1 2>& 1 | tee err
2014-10-06 13:56:09 +04:00
# Check tther is warning for large chunk size and zeroing enabled
grep "Pool zeroing and large" err
UUID = $( get lv_field $vg /$lv2 uuid)
# Fail is pool is active
# TODO maybe detect inactive pool and deactivate
2016-12-07 23:30:57 +03:00
fail lvconvert --swapmetadata --yes --poolmetadata $lv2 $vg /$lv1
2014-10-06 13:56:09 +04:00
lvchange -an $vg
2016-12-07 23:30:57 +03:00
lvconvert --swapmetadata --yes --poolmetadata $lv2 $vg /$lv1
2014-10-06 13:56:09 +04:00
check lv_field $vg /${ lv1 } _tmeta uuid " $UUID "
2012-11-19 15:31:11 +04:00
lvremove -f $vg
2014-10-06 13:56:09 +04:00
2012-11-19 15:31:11 +04:00
# test with bigger sizes
lvcreate -L1T -n $lv1 $vg
lvcreate -L8M -n $lv2 $vg
lvcreate -L1M -n $lv3 $vg
2012-10-09 18:32:11 +04:00
2012-11-19 15:31:11 +04:00
# chunk size is bigger then size of thin pool data
2014-05-20 23:11:11 +04:00
fail lvconvert --yes -c 1G --thinpool $vg /$lv3
2012-11-19 15:31:11 +04:00
# stripes can't be used with poolmetadata
2016-12-07 23:30:57 +03:00
not lvconvert --stripes 2 --thinpool $vg /$lv1 --poolmetadata $vg /$lv2
2012-11-19 15:31:11 +04:00
# too small metadata (<2M)
2014-05-20 23:11:11 +04:00
fail lvconvert --yes -c 64 --thinpool $vg /$lv1 --poolmetadata $vg /$lv3
2012-11-19 15:31:11 +04:00
# too small chunk size fails
2016-12-07 23:30:57 +03:00
not lvconvert -c 4 --thinpool $vg /$lv1 --poolmetadata $vg /$lv2
2012-11-19 15:31:11 +04:00
# too big chunk size fails
2016-12-07 23:30:57 +03:00
not lvconvert -c 2G --thinpool $vg /$lv1 --poolmetadata $vg /$lv2
2012-11-19 15:31:11 +04:00
# negative chunk size fails
2016-12-07 23:30:57 +03:00
not lvconvert -c -256 --thinpool $vg /$lv1 --poolmetadata $vg /$lv2
2014-10-06 13:56:09 +04:00
# non multiple of 64KiB fails
2016-12-07 23:30:57 +03:00
not lvconvert -c 88 --thinpool $vg /$lv1 --poolmetadata $vg /$lv2
2012-10-09 18:32:11 +04:00
2014-11-23 01:37:31 +03:00
# cannot use same LV for pool and convertion
2016-12-07 23:30:57 +03:00
not lvconvert --yes --thinpool $vg /$lv3 -T $vg /$lv3
2014-11-23 01:37:31 +03:00
2012-11-19 15:31:11 +04:00
# Warning about smaller then suggested
2015-05-14 11:20:24 +03:00
lvconvert --yes -c 256 --thinpool $vg /$lv1 --poolmetadata $vg /$lv2 2>& 1 | tee err
2012-11-19 15:31:11 +04:00
grep "WARNING: Chunk size is smaller" err
lvremove -f $vg
2014-10-06 13:56:09 +04:00
2012-11-19 15:31:11 +04:00
lvcreate -L1T -n $lv1 $vg
lvcreate -L32G -n $lv2 $vg
# Warning about bigger then needed
2015-05-14 11:20:24 +03:00
lvconvert --yes --thinpool $vg /$lv1 --poolmetadata $vg /$lv2 2>& 1 | tee err
2014-07-11 15:13:56 +04:00
grep "WARNING: Maximum" err
2012-11-19 15:31:11 +04:00
lvremove -f $vg
2013-11-16 02:47:14 +04:00
2014-10-06 13:56:09 +04:00
2014-06-06 01:06:45 +04:00
if test " $TSIZE " = 64T; then
2012-11-19 15:31:11 +04:00
lvcreate -L24T -n $lv1 $vg
# Warning about bigger then needed (24T data and 16G -> 128K chunk)
2015-05-14 11:20:24 +03:00
lvconvert --yes -c 64 --thinpool $vg /$lv1 2>& 1 | tee err
2016-12-07 23:30:57 +03:00
grep "too small" err
2014-10-06 13:56:09 +04:00
lvremove -f $vg
2013-11-16 02:47:14 +04:00
fi
2012-10-09 18:32:11 +04:00
2012-11-19 15:31:11 +04:00
#lvs -a -o+chunk_size,stripe_size,seg_pe_ranges
2012-10-09 18:32:11 +04:00
2014-10-06 13:56:09 +04:00
####################################
# Prohibites thin pool conversions #
####################################
lvcreate -L32 -n $lv1 $vg
lvcreate -L16 -n $lv2 $vg
lvconvert --yes --thinpool $vg /$lv1
2014-10-07 12:12:49 +04:00
not aux have_cache 1 3 0 || fail lvconvert --yes --type cache-pool $vg /$lv1
2014-10-06 13:56:09 +04:00
fail lvconvert --yes --type mirror -m1 $vg /$lv1
2014-10-07 12:12:49 +04:00
not aux have_raid 1 0 0 || fail lvconvert --yes --type raid1 -m1 $vg /$lv1
2014-10-06 13:56:09 +04:00
fail lvconvert --yes --type snapshot $vg /$lv1 $vg /$lv2
fail lvconvert --yes --type snapshot $vg /$lv2 $vg /$lv1
fail lvconvert --yes --type thin-pool $vg /$lv1
2012-10-09 18:32:11 +04:00
vgremove -ff $vg
2016-12-11 12:18:44 +03:00
vgremove -ff $vg1