shaba/lvm2
1
0
Fork 0
mirror of git://sourceware.org/git/lvm2.git synced 2024-12-22 17:35:59 +03:00
Code Releases Activity
1c60c6785c
lvm2/lib/metadata/lv_manip.c

9933 lines
291 KiB
C
Raw Normal View History

o lv_manip.c will contain the code for lv_create, lv_extend and lv_reduce.
2001-11-06 13:29:56 +03:00
/*
Update copyright notices.
2004-03-30 23:35:44 +04:00
* Copyright (C) 2001-2004 Sistina Software, Inc. All rights reserved.
lvremove: ensure no subLV is active Since component activation is going to be enabled, enusure, no subLV is active when we deactivate LV.
2018-03-03 00:07:14 +03:00
* Copyright (C) 2004-2018 Red Hat, Inc. All rights reserved.
o lv_manip.c will contain the code for lv_create, lv_extend and lv_reduce.
2001-11-06 13:29:56 +03:00
*
Update copyright notices.
2004-03-30 23:35:44 +04:00
* This file is part of LVM2.
*
* This copyrighted material is made available to anyone wishing to use,
* modify, copy, or redistribute it subject to the terms and conditions
Fix inconsistent licence notices: executables are GPLv2; libraries LGPLv2.1.
2007-08-21 00:55:30 +04:00
* of the GNU Lesser General Public License v.2.1.
Update copyright notices.
2004-03-30 23:35:44 +04:00
*
Fix inconsistent licence notices: executables are GPLv2; libraries LGPLv2.1.
2007-08-21 00:55:30 +04:00
* You should have received a copy of the GNU Lesser General Public License
Update copyright notices.
2004-03-30 23:35:44 +04:00
* along with this program; if not, write to the Free Software Foundation,
doc: change fsf address Hmm rpmlint suggest fsf is using a different address these days, so lets keep it up-to-date
2016-01-21 13:49:46 +03:00
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
o lv_manip.c will contain the code for lv_create, lv_extend and lv_reduce.
2001-11-06 13:29:56 +03:00
*/
build: Don't generate symlinks in include/ dir As we start refactoring the code to break dependencies (see doc/refactoring.txt), I want us to use full paths in the includes (eg, #include "base/data-struct/list.h"). This makes it more obvious when we're breaking abstraction boundaries, eg, including a file in metadata/ from base/
2018-05-14 12:30:20 +03:00
#include "lib/misc/lib.h"
#include "lib/metadata/metadata.h"
#include "lib/locking/locking.h"
o lv_manip.c will contain the code for lv_create, lv_extend and lv_reduce.
2001-11-06 13:29:56 +03:00
#include "pv_map.h"
build: Don't generate symlinks in include/ dir As we start refactoring the code to break dependencies (see doc/refactoring.txt), I want us to use full paths in the includes (eg, #include "base/data-struct/list.h"). This makes it more obvious when we're breaking abstraction boundaries, eg, including a file in metadata/ from base/
2018-05-14 12:30:20 +03:00
#include "lib/misc/lvm-string.h"
#include "lib/commands/toolcontext.h"
#include "lib/metadata/lv_alloc.h"
#include "lib/metadata/pv_alloc.h"
#include "lib/display/display.h"
#include "lib/metadata/segtype.h"
#include "lib/activate/activate.h"
#include "lib/datastruct/str_list.h"
#include "lib/config/defaults.h"
#include "lib/misc/lvm-exec.h"
#include "lib/mm/memlock.h"
#include "lib/locking/lvmlockd.h"
#include "lib/label/label.h"
wipe_lv: interruptible wiping Since we now block signals and wiping may take unexpectedly long time - support breaking command while wipe is in progress.
2020-10-02 20:31:05 +03:00
#include "lib/misc/lvm-signal.h"
lvresize: add new options and defaults for fs handling The new option "--fs String" for lvresize/lvreduce/lvextend controls the handling of file systems before/after resizing the LV. --resizefs is the same as --fs resize. The new option "--fsmode String" can be used to control mounting and unmounting of the fs during resizing. Possible --fs values: checksize Only applies to reducing size; does nothing for extend. Check the fs size and reduce the LV if the fs is not using the affected space, i.e. the fs does not need to be shrunk. Fail the command without reducing the fs or LV if the fs is using the affected space. resize Resize the fs using the fs-specific resize command. This may include mounting, unmounting, or running fsck. See --fsmode to control mounting behavior, and --nofsck to disable fsck. resize_fsadm Use the old method of calling fsadm to handle the fs (deprecated.) Warning: this option does not prevent lvreduce from destroying file systems that are unmounted (or mounted if prompts are skipped.) ignore Resize the LV without checking for or handling a file system. Warning: using ignore when reducing the LV size may destroy the file system. Possible --fsmode values: manage Mount or unmount the fs as needed to resize the fs, and attempt to restore the original mount state at the end. nochange Do not mount or unmount the fs. If mounting or unmounting is required to resize the fs, then do not resize the fs or the LV and fail the command. offline Unmount the fs if it is mounted, and resize the fs while it is unmounted. If mounting is required to resize the fs, then do not resize the fs or the LV and fail the command. Notes on lvreduce: When no --fs or --resizefs option is specified: . lvextend default behavior is fs ignore. . lvreduce default behavior is fs checksize (includes activating the LV.) With the exception of --fs resize_fsadm|ignore, lvreduce requires the recent libblkid fields FSLASTBLOCK and FSBLOCKSIZE. FSLASTBLOCK*FSBLOCKSIZE is the last byte used by the fs on the LV, which determines if reducing the fs is necessary.
2022-06-14 23:20:21 +03:00
#include "lib/device/filesystem.h"
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
wipe_lv: use BLKZEROOUT when possible Since BLKZEROOUT ioctl should be supposedly fastest way how to clear block device start using this ioctl for zeroing a device. Commonly we do zero typically small portion of a device (8KiB) - however since we now also started to zero metadata devices, in the case of i.e. thin-pool metadata this can go upto ~16GiB and here the performance starts to be noticable.
2020-10-02 20:32:28 +03:00
#ifdef HAVE_BLKZEROOUT
#include <sys/ioctl.h>
#include <linux/fs.h>
#endif
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
typedef enum {
PREFERRED,
USE_AREA,
NEXT_PV,
NEXT_AREA
} area_use_t;
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
/* FIXME: remove RAID_METADATA_AREA_LEN macro after defining 'raid_log_extents'*/
#define RAID_METADATA_AREA_LEN 1
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
/* FIXME These ended up getting used differently from first intended. Refactor. */
Append _TO_LVSEG to names of internal A_CONTIGUOUS and A_CLING flags. Remove some unnecesary prev_lvseg checks.
2012-05-11 22:59:01 +04:00
/* Only one of A_CONTIGUOUS_TO_LVSEG, A_CLING_TO_LVSEG, A_CLING_TO_ALLOCED may be set */
#define A_CONTIGUOUS_TO_LVSEG 0x01 /* Must be contiguous to an existing segment */
#define A_CLING_TO_LVSEG 0x02 /* Must use same disks as existing LV segment */
#define A_CLING_TO_ALLOCED 0x04 /* Must use same disks as already-allocated segment */
#define A_CLING_BY_TAGS 0x08 /* Must match tags against existing segment */
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
#define A_CAN_SPLIT 0x10
alloc: fix lvextend when stripe number varies The PREFERRED allocation mechanism requires the number of areas in the previous LV segment to match the number in the new segment being allocated. If they do not match, the code may crash. E.g. https://bugzilla.redhat.com/989347 Introduce A_AREA_COUNT_MATCHES and when not set avoid referring to the previous segment with the contiguous and cling policies.
2013-07-29 22:35:45 +04:00
#define A_AREA_COUNT_MATCHES 0x20 /* Existing lvseg has same number of areas as new segment */
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
alloc: Introduce A_POSITIONAL_FILL. Set A_POSITIONAL_FILL if the array of areas is being filled positionally (with a slot corresponding to each 'leg') rather than sequentially (with all suitable areas found, to be sorted and selected from).
2014-04-15 04:13:47 +04:00
#define A_POSITIONAL_FILL 0x40 /* Slots are positional and filled using PREFERRED */
alloc: Add A_PARTITION_BY_TAGS to avoid sharing. Add A_PARTITION_BY_TAGS set when allocated areas should not share tags with each other and allow _match_pv_tags to accept an alternative list of tags. (Not used yet.)
2015-04-10 23:57:52 +03:00
#define A_PARTITION_BY_TAGS 0x80 /* No allocated area may share any tag with any other */
alloc: Introduce A_POSITIONAL_FILL. Set A_POSITIONAL_FILL if the array of areas is being filled positionally (with a slot corresponding to each 'leg') rather than sequentially (with all suitable areas found, to be sorted and selected from).
2014-04-15 04:13:47 +04:00
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
/*
* Constant parameters during a single allocation attempt.
*/
struct alloc_parms {
alloc_policy_t alloc;
unsigned flags; /* Holds A_* */
struct lv_segment *prev_lvseg;
uint32_t extents_still_needed;
};
/*
* Holds varying state of each allocation attempt.
*/
struct alloc_state {
alloc: Access alloc_parms from alloc_state. alloc_parms is constant while allocating.
2014-04-15 04:05:34 +04:00
const struct alloc_parms *alloc_parms;
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
struct pv_area_used *areas;
uint32_t areas_size;
uint32_t log_area_count_still_needed; /* Number of areas still needing to be allocated for the log */
uint32_t allocated; /* Total number of extents allocated so far */
alloc: Fix lvextend failure when varying stripes. A segfault was reported when extending an LV with a smaller number of stripes than originally used. Under unusual circumstances, the cling detection code could successfully find a match against the excess stripe positions and think it had finished prematurely leading to an allocation being pursued with a length of zero. Rename ix_offset to num_positional_areas and move it to struct alloc_state so that _is_condition() can obtain access to it. In _is_condition(), areas_size can no longer be assumed to match the number of positional slots being filled so check this newly-exposed num_positional_areas directly instead. If the slot is outside the range we are trying to fill, just ignore the match for now. (Also note that the code still only performs cling detection against the first segment of the LV.)
2015-07-16 01:12:54 +03:00
uint32_t num_positional_areas; /* Number of parallel allocations that must be contiguous/cling */
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
};
o lv_manip.c will contain the code for lv_create, lv_extend and lv_reduce.
2001-11-06 13:29:56 +03:00
A few more cleanups for lvrename of mirrors checkin: * add struct lv_names for old/new names * replace lv->status & MIRROR checks with lv_is_visible()
2007-08-07 22:55:38 +04:00
struct lv_names {
const char *old;
const char *new;
};
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
enum {
lv_manip: add get_lv_type_name/lv_is_linear and lv_is_striped helper fns The get_lv_type_name helps with translating volume type to human readable form (can be used in reports or various messages if needed). The lv_is_linear and lv_is_striped complete the set of lv_is_* functions that identify exact volume types.
2014-07-01 12:37:01 +04:00
LV_TYPE_UNKNOWN,
report: add new 'none' lv_layout and 'history' lv_role and mark historical LVs that way Report proper values for historical LVs in lv_layout and lv_role fields. Any historical LV doesn't have any layout anymore and the role is "history". For example: $ lvs -H -o name,lv_attr,lv_layout,lv_role vg/-lvol1 LV Attr Layout Role -lvol1 ----h----- none public,history
2016-03-01 17:25:04 +03:00
LV_TYPE_NONE,
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
LV_TYPE_PUBLIC,
LV_TYPE_PRIVATE,
report: add new 'none' lv_layout and 'history' lv_role and mark historical LVs that way Report proper values for historical LVs in lv_layout and lv_role fields. Any historical LV doesn't have any layout anymore and the role is "history". For example: $ lvs -H -o name,lv_attr,lv_layout,lv_role vg/-lvol1 LV Attr Layout Role -lvol1 ----h----- none public,history
2016-03-01 17:25:04 +03:00
LV_TYPE_HISTORY,
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
LV_TYPE_LINEAR,
LV_TYPE_STRIPED,
LV_TYPE_MIRROR,
LV_TYPE_RAID,
lv_manip: add get_lv_type_name/lv_is_linear and lv_is_striped helper fns The get_lv_type_name helps with translating volume type to human readable form (can be used in reports or various messages if needed). The lv_is_linear and lv_is_striped complete the set of lv_is_* functions that identify exact volume types.
2014-07-01 12:37:01 +04:00
LV_TYPE_THIN,
LV_TYPE_CACHE,
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
LV_TYPE_SPARSE,
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
LV_TYPE_ORIGIN,
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
LV_TYPE_THINORIGIN,
LV_TYPE_MULTITHINORIGIN,
LV_TYPE_THICKORIGIN,
LV_TYPE_MULTITHICKORIGIN,
LV_TYPE_CACHEORIGIN,
LV_TYPE_EXTTHINORIGIN,
LV_TYPE_MULTIEXTTHINORIGIN,
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
LV_TYPE_SNAPSHOT,
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
LV_TYPE_THINSNAPSHOT,
LV_TYPE_THICKSNAPSHOT,
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
LV_TYPE_PVMOVE,
LV_TYPE_IMAGE,
LV_TYPE_LOG,
LV_TYPE_METADATA,
LV_TYPE_POOL,
LV_TYPE_DATA,
LV_TYPE_SPARE,
lv_manip: layout and role support for vdo segment
2018-06-29 12:18:44 +03:00
LV_TYPE_VDO,
lv_manip: add get_lv_type_name/lv_is_linear and lv_is_striped helper fns The get_lv_type_name helps with translating volume type to human readable form (can be used in reports or various messages if needed). The lv_is_linear and lv_is_striped complete the set of lv_is_* functions that identify exact volume types.
2014-07-01 12:37:01 +04:00
LV_TYPE_VIRTUAL,
raid0: Add raid0 segment type. This remains experimental and quite restrictive so should only be used for testing at this stage. (E.g. lvreduce is not supported.)
2016-05-23 18:46:38 +03:00
LV_TYPE_RAID0,
raid0: Add raid0_meta segment type.
2016-07-02 00:20:54 +03:00
LV_TYPE_RAID0_META,
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
LV_TYPE_RAID1,
LV_TYPE_RAID10,
LV_TYPE_RAID4,
LV_TYPE_RAID5,
segtypes: Further segtype macros.
2016-08-05 16:00:08 +03:00
LV_TYPE_RAID5_N,
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
LV_TYPE_RAID5_LA,
LV_TYPE_RAID5_RA,
LV_TYPE_RAID5_LS,
LV_TYPE_RAID5_RS,
LV_TYPE_RAID6,
LV_TYPE_RAID6_ZR,
LV_TYPE_RAID6_NR,
LV_TYPE_RAID6_NC,
report: identify LV hodling sanlock locks as 'private,lockd,sanlock' within lv_role report field Before this patch: $ lvs -a -o name,layout,role test/lvmlock LV Layout Role [lvmlock] linear public With this patch applied: $ lvs -a -o name,layout,role test/lvmlock LV Layout Role [lvmlock] linear private,lockd,sanlock
2015-10-08 14:44:21 +03:00
LV_TYPE_LOCKD,
writecache: display layout and role fields
2019-09-20 22:54:00 +03:00
LV_TYPE_SANLOCK,
LV_TYPE_CACHEVOL,
LV_TYPE_WRITECACHE,
Allow dm-integrity to be used for raid images dm-integrity stores checksums of the data written to an LV, and returns an error if data read from the LV does not match the previously saved checksum. When used on raid images, dm-raid will correct the error by reading the block from another image, and the device user sees no error. The integrity metadata (checksums) are stored on an internal LV allocated by lvm for each linear image. The internal LV is allocated on the same PV as the image. Create a raid LV with an integrity layer over each raid image (for raid levels 1,4,5,6,10): lvcreate --type raidN --raidintegrity y [options] Add an integrity layer to images of an existing raid LV: lvconvert --raidintegrity y LV Remove the integrity layer from images of a raid LV: lvconvert --raidintegrity n LV Settings Use --raidintegritymode journal|bitmap (journal is default) to configure the method used by dm-integrity to ensure crash consistency. Initialization When integrity is added to an LV, the kernel needs to initialize the integrity metadata/checksums for all blocks in the LV. The data corruption checking performed by dm-integrity will only operate on areas of the LV that are already initialized. The progress of integrity initialization is reported by the "syncpercent" LV reporting field (and under the Cpy%Sync lvs column.) Example: create a raid1 LV with integrity: $ lvcreate --type raid1 -m1 --raidintegrity y -n rr -L1G foo Creating integrity metadata LV rr_rimage_0_imeta with size 12.00 MiB. Logical volume "rr_rimage_0_imeta" created. Creating integrity metadata LV rr_rimage_1_imeta with size 12.00 MiB. Logical volume "rr_rimage_1_imeta" created. Logical volume "rr" created. $ lvs -a foo LV VG Attr LSize Origin Cpy%Sync rr foo rwi-a-r--- 1.00g 4.93 [rr_rimage_0] foo gwi-aor--- 1.00g [rr_rimage_0_iorig] 41.02 [rr_rimage_0_imeta] foo ewi-ao---- 12.00m [rr_rimage_0_iorig] foo -wi-ao---- 1.00g [rr_rimage_1] foo gwi-aor--- 1.00g [rr_rimage_1_iorig] 39.45 [rr_rimage_1_imeta] foo ewi-ao---- 12.00m [rr_rimage_1_iorig] foo -wi-ao---- 1.00g [rr_rmeta_0] foo ewi-aor--- 4.00m [rr_rmeta_1] foo ewi-aor--- 4.00m
2019-11-21 01:07:27 +03:00
LV_TYPE_WRITECACHEORIGIN,
LV_TYPE_INTEGRITY,
LV_TYPE_INTEGRITYORIGIN
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
};
lv_manip: add get_lv_type_name/lv_is_linear and lv_is_striped helper fns The get_lv_type_name helps with translating volume type to human readable form (can be used in reports or various messages if needed). The lv_is_linear and lv_is_striped complete the set of lv_is_* functions that identify exact volume types.
2014-07-01 12:37:01 +04:00
static const char *_lv_type_names[] = {
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
[LV_TYPE_UNKNOWN] = "unknown",
report: add new 'none' lv_layout and 'history' lv_role and mark historical LVs that way Report proper values for historical LVs in lv_layout and lv_role fields. Any historical LV doesn't have any layout anymore and the role is "history". For example: $ lvs -H -o name,lv_attr,lv_layout,lv_role vg/-lvol1 LV Attr Layout Role -lvol1 ----h----- none public,history
2016-03-01 17:25:04 +03:00
[LV_TYPE_NONE] = "none",
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
[LV_TYPE_PUBLIC] = "public",
[LV_TYPE_PRIVATE] = "private",
report: add new 'none' lv_layout and 'history' lv_role and mark historical LVs that way Report proper values for historical LVs in lv_layout and lv_role fields. Any historical LV doesn't have any layout anymore and the role is "history". For example: $ lvs -H -o name,lv_attr,lv_layout,lv_role vg/-lvol1 LV Attr Layout Role -lvol1 ----h----- none public,history
2016-03-01 17:25:04 +03:00
[LV_TYPE_HISTORY] = "history",
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
[LV_TYPE_LINEAR] = "linear",
[LV_TYPE_STRIPED] = "striped",
[LV_TYPE_MIRROR] = "mirror",
[LV_TYPE_RAID] = "raid",
[LV_TYPE_THIN] = "thin",
[LV_TYPE_CACHE] = "cache",
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
[LV_TYPE_SPARSE] = "sparse",
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
[LV_TYPE_ORIGIN] = "origin",
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
[LV_TYPE_THINORIGIN] = "thinorigin",
[LV_TYPE_MULTITHINORIGIN] = "multithinorigin",
[LV_TYPE_THICKORIGIN] = "thickorigin",
[LV_TYPE_MULTITHICKORIGIN] = "multithickorigin",
[LV_TYPE_CACHEORIGIN] = "cacheorigin",
[LV_TYPE_EXTTHINORIGIN] = "extthinorigin",
[LV_TYPE_MULTIEXTTHINORIGIN] = "multiextthinorigin",
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
[LV_TYPE_SNAPSHOT] = "snapshot",
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
[LV_TYPE_THINSNAPSHOT] = "thinsnapshot",
[LV_TYPE_THICKSNAPSHOT] = "thicksnapshot",
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
[LV_TYPE_PVMOVE] = "pvmove",
[LV_TYPE_IMAGE] = "image",
[LV_TYPE_LOG] = "log",
[LV_TYPE_METADATA] = "metadata",
[LV_TYPE_POOL] = "pool",
[LV_TYPE_DATA] = "data",
[LV_TYPE_SPARE] = "spare",
lv_manip: layout and role support for vdo segment
2018-06-29 12:18:44 +03:00
[LV_TYPE_VDO] = "vdo",
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
[LV_TYPE_VIRTUAL] = "virtual",
raid0: Add raid0 segment type. This remains experimental and quite restrictive so should only be used for testing at this stage. (E.g. lvreduce is not supported.)
2016-05-23 18:46:38 +03:00
[LV_TYPE_RAID0] = SEG_TYPE_NAME_RAID0,
raid0: Add raid0_meta segment type.
2016-07-02 00:20:54 +03:00
[LV_TYPE_RAID0_META] = SEG_TYPE_NAME_RAID0_META,
cleanup: Use segtype.h definitions of segment type names wherever possible We are not using already defined segement type names where we could. There is a lot of other places in device-mapper and LVM2 we have those hardcoded so we should better finally have a common interface in libdevmapper to avoid this.
2014-09-24 17:24:41 +04:00
[LV_TYPE_RAID1] = SEG_TYPE_NAME_RAID1,
[LV_TYPE_RAID10] = SEG_TYPE_NAME_RAID10,
[LV_TYPE_RAID4] = SEG_TYPE_NAME_RAID4,
[LV_TYPE_RAID5] = SEG_TYPE_NAME_RAID5,
segtypes: Further segtype macros.
2016-08-05 16:00:08 +03:00
[LV_TYPE_RAID5_N] = SEG_TYPE_NAME_RAID5_N,
cleanup: Use segtype.h definitions of segment type names wherever possible We are not using already defined segement type names where we could. There is a lot of other places in device-mapper and LVM2 we have those hardcoded so we should better finally have a common interface in libdevmapper to avoid this.
2014-09-24 17:24:41 +04:00
[LV_TYPE_RAID5_LA] = SEG_TYPE_NAME_RAID5_LA,
[LV_TYPE_RAID5_RA] = SEG_TYPE_NAME_RAID5_RA,
[LV_TYPE_RAID5_LS] = SEG_TYPE_NAME_RAID5_LS,
[LV_TYPE_RAID5_RS] = SEG_TYPE_NAME_RAID5_RS,
[LV_TYPE_RAID6] = SEG_TYPE_NAME_RAID6,
[LV_TYPE_RAID6_ZR] = SEG_TYPE_NAME_RAID6_ZR,
[LV_TYPE_RAID6_NR] = SEG_TYPE_NAME_RAID6_NR,
[LV_TYPE_RAID6_NC] = SEG_TYPE_NAME_RAID6_NC,
report: identify LV hodling sanlock locks as 'private,lockd,sanlock' within lv_role report field Before this patch: $ lvs -a -o name,layout,role test/lvmlock LV Layout Role [lvmlock] linear public With this patch applied: $ lvs -a -o name,layout,role test/lvmlock LV Layout Role [lvmlock] linear private,lockd,sanlock
2015-10-08 14:44:21 +03:00
[LV_TYPE_LOCKD] = "lockd",
[LV_TYPE_SANLOCK] = "sanlock",
writecache: display layout and role fields
2019-09-20 22:54:00 +03:00
[LV_TYPE_CACHEVOL] = "cachevol",
[LV_TYPE_WRITECACHE] = "writecache",
[LV_TYPE_WRITECACHEORIGIN] = "writecacheorigin",
Allow dm-integrity to be used for raid images dm-integrity stores checksums of the data written to an LV, and returns an error if data read from the LV does not match the previously saved checksum. When used on raid images, dm-raid will correct the error by reading the block from another image, and the device user sees no error. The integrity metadata (checksums) are stored on an internal LV allocated by lvm for each linear image. The internal LV is allocated on the same PV as the image. Create a raid LV with an integrity layer over each raid image (for raid levels 1,4,5,6,10): lvcreate --type raidN --raidintegrity y [options] Add an integrity layer to images of an existing raid LV: lvconvert --raidintegrity y LV Remove the integrity layer from images of a raid LV: lvconvert --raidintegrity n LV Settings Use --raidintegritymode journal|bitmap (journal is default) to configure the method used by dm-integrity to ensure crash consistency. Initialization When integrity is added to an LV, the kernel needs to initialize the integrity metadata/checksums for all blocks in the LV. The data corruption checking performed by dm-integrity will only operate on areas of the LV that are already initialized. The progress of integrity initialization is reported by the "syncpercent" LV reporting field (and under the Cpy%Sync lvs column.) Example: create a raid1 LV with integrity: $ lvcreate --type raid1 -m1 --raidintegrity y -n rr -L1G foo Creating integrity metadata LV rr_rimage_0_imeta with size 12.00 MiB. Logical volume "rr_rimage_0_imeta" created. Creating integrity metadata LV rr_rimage_1_imeta with size 12.00 MiB. Logical volume "rr_rimage_1_imeta" created. Logical volume "rr" created. $ lvs -a foo LV VG Attr LSize Origin Cpy%Sync rr foo rwi-a-r--- 1.00g 4.93 [rr_rimage_0] foo gwi-aor--- 1.00g [rr_rimage_0_iorig] 41.02 [rr_rimage_0_imeta] foo ewi-ao---- 12.00m [rr_rimage_0_iorig] foo -wi-ao---- 1.00g [rr_rimage_1] foo gwi-aor--- 1.00g [rr_rimage_1_iorig] 39.45 [rr_rimage_1_imeta] foo ewi-ao---- 12.00m [rr_rimage_1_iorig] foo -wi-ao---- 1.00g [rr_rmeta_0] foo ewi-aor--- 4.00m [rr_rmeta_1] foo ewi-aor--- 4.00m
2019-11-21 01:07:27 +03:00
[LV_TYPE_INTEGRITY] = "integrity",
[LV_TYPE_INTEGRITYORIGIN] = "integrityorigin",
lv_manip: add get_lv_type_name/lv_is_linear and lv_is_striped helper fns The get_lv_type_name helps with translating volume type to human readable form (can be used in reports or various messages if needed). The lv_is_linear and lv_is_striped complete the set of lv_is_* functions that identify exact volume types.
2014-07-01 12:37:01 +04:00
};
refactor: rename 'lv_type' field to 'lv_role' The 'lv_type' field name was a bit misleading. Better one is 'lv_role' since this fields describes what's the actual use of the LV currently - its 'role'.
2014-08-25 11:07:03 +04:00
static int _lv_layout_and_role_mirror(struct dm_pool *mem,
const struct logical_volume *lv,
struct dm_list *layout,
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
struct dm_list *role,
int *public_lv)
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
{
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
int top_level = 0;
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
/* non-top-level LVs */
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
if (lv_is_mirror_image(lv)) {
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
if (!str_list_add_no_dup_check(mem, role, _lv_type_names[LV_TYPE_MIRROR]) ||
!str_list_add_no_dup_check(mem, role, _lv_type_names[LV_TYPE_IMAGE]))
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
goto_bad;
} else if (lv_is_mirror_log(lv)) {
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
if (!str_list_add_no_dup_check(mem, role, _lv_type_names[LV_TYPE_MIRROR]) ||
!str_list_add_no_dup_check(mem, role, _lv_type_names[LV_TYPE_LOG]))
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
goto_bad;
report: also display "mirror" keyword in lv_layout for mirrored mirror log and "cache" keyword in lv_layout for cached cache pool $ lvs -a -o name,vg_name,attr,layout,type LV VG Attr Layout Type lvol0 vg mwi-a-m--- mirror mirror [lvol0_mimage_0] vg iwi-aom--- linear image,mirror [lvol0_mimage_1] vg iwi-aom--- linear image,mirror [lvol0_mlog] vg mwi-aom--- mirror log,mirror [lvol0_mlog_mimage_0] vg iwi-aom--- linear image,mirror [lvol0_mlog_mimage_1] vg iwi-aom--- linear image,mirror (lvol0_mlog properly displayed as "mirror" layout for mirrored mirror log) $ lvs -a -o name,vg_name,attr,layout,type LV VG Attr Layout Type lvol0 vg Cwi---C--- cache,pool cache,pool [lvol0_cdata] vg Cwi------- linear cache,data,pool [lvol0_cmeta] vg ewi------- linear cache,metadata,pool [lvol1_pmspare] vg ewi------- linear metadata,pool,spare lvol2 vg Cwi---C--- cache,pool cache,pool [lvol2_cdata] vg Cwi---C--- cache cache,data,pool [lvol2_cdata_corig] vg owi---C--- linear cache,origin [lvol2_cmeta] vg ewi------- linear cache,metadata,pool (lvol2_cdata properly displayed as cached cache pool data)
2014-08-19 15:58:32 +04:00
if (lv_is_mirrored(lv) &&
!str_list_add_no_dup_check(mem, layout, _lv_type_names[LV_TYPE_MIRROR]))
goto_bad;
cleanup: Use lv_is_ macros. Use lv_is_* macros throughout the code base, introducing lv_is_pvmove, lv_is_locked, lv_is_converting and lv_is_merging. lv_is_mirror_type no longer includes pvmove.
2014-09-16 00:33:53 +04:00
} else if (lv_is_pvmove(lv)) {
refactor: rename 'lv_type' field to 'lv_role' The 'lv_type' field name was a bit misleading. Better one is 'lv_role' since this fields describes what's the actual use of the LV currently - its 'role'.
2014-08-25 11:07:03 +04:00
if (!str_list_add_no_dup_check(mem, role, _lv_type_names[LV_TYPE_PVMOVE]) ||
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
!str_list_add_no_dup_check(mem, layout, _lv_type_names[LV_TYPE_MIRROR]))
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
goto_bad;
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
} else
top_level = 1;
lv_manip: add get_lv_type_name/lv_is_linear and lv_is_striped helper fns The get_lv_type_name helps with translating volume type to human readable form (can be used in reports or various messages if needed). The lv_is_linear and lv_is_striped complete the set of lv_is_* functions that identify exact volume types.
2014-07-01 12:37:01 +04:00
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
if (!top_level) {
*public_lv = 0;
return 1;
lv_manip: add get_lv_type_name/lv_is_linear and lv_is_striped helper fns The get_lv_type_name helps with translating volume type to human readable form (can be used in reports or various messages if needed). The lv_is_linear and lv_is_striped complete the set of lv_is_* functions that identify exact volume types.
2014-07-01 12:37:01 +04:00
}
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
/* top-level LVs */
if (!str_list_add_no_dup_check(mem, layout, _lv_type_names[LV_TYPE_MIRROR]))
goto_bad;
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
return 1;
bad:
return 0;
lv_manip: add get_lv_type_name/lv_is_linear and lv_is_striped helper fns The get_lv_type_name helps with translating volume type to human readable form (can be used in reports or various messages if needed). The lv_is_linear and lv_is_striped complete the set of lv_is_* functions that identify exact volume types.
2014-07-01 12:37:01 +04:00
}
refactor: rename 'lv_type' field to 'lv_role' The 'lv_type' field name was a bit misleading. Better one is 'lv_role' since this fields describes what's the actual use of the LV currently - its 'role'.
2014-08-25 11:07:03 +04:00
static int _lv_layout_and_role_raid(struct dm_pool *mem,
const struct logical_volume *lv,
struct dm_list *layout,
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
struct dm_list *role,
int *public_lv)
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
{
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
int top_level = 0;
segtypes: Add and use new segtype macros. Includes fixing an inverted raid10 segtype check in _raid_add_target_line.
2015-09-24 16:59:07 +03:00
const struct segment_type *segtype;
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
/* non-top-level LVs */
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
if (lv_is_raid_image(lv)) {
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
if (!str_list_add_no_dup_check(mem, role, _lv_type_names[LV_TYPE_RAID]) ||
!str_list_add_no_dup_check(mem, role, _lv_type_names[LV_TYPE_IMAGE]))
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
goto_bad;
} else if (lv_is_raid_metadata(lv)) {
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
if (!str_list_add_no_dup_check(mem, role, _lv_type_names[LV_TYPE_RAID]) ||
!str_list_add_no_dup_check(mem, role, _lv_type_names[LV_TYPE_METADATA]))
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
goto_bad;
mirrors: Fix checks for mirror/raid/pvmove LVs. Try to enforce consistent macro usage along these lines: lv_is_mirror - mirror that uses the original dm-raid1 implementation (segment type "mirror") lv_is_mirror_type - also includes internal mirror image and log LVs lv_is_raid - raid volume that uses the new dm-raid implementation (segment type "raid") lv_is_raid_type - also includes internal raid image / log / metadata LVs lv_is_mirrored - LV is mirrored using either kernel implementation (excludes non-mirror modes like raid5 etc.) lv_is_pvmove - internal pvmove volume
2014-09-16 03:13:46 +04:00
} else if (lv_is_pvmove(lv)) {
if (!str_list_add_no_dup_check(mem, role, _lv_type_names[LV_TYPE_PVMOVE]) ||
!str_list_add_no_dup_check(mem, layout, _lv_type_names[LV_TYPE_RAID]))
goto_bad;
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
} else
top_level = 1;
if (!top_level) {
*public_lv = 0;
return 1;
}
/* top-level LVs */
if (!str_list_add_no_dup_check(mem, layout, _lv_type_names[LV_TYPE_RAID]))
goto_bad;
segtypes: Add and use new segtype macros. Includes fixing an inverted raid10 segtype check in _raid_add_target_line.
2015-09-24 16:59:07 +03:00
segtype = first_seg(lv)->segtype;
cleanup: assign seg_name once
2015-09-04 10:42:45 +03:00
raid0: Add raid0 segment type. This remains experimental and quite restrictive so should only be used for testing at this stage. (E.g. lvreduce is not supported.)
2016-05-23 18:46:38 +03:00
if (segtype_is_raid0(segtype)) {
if (!str_list_add_no_dup_check(mem, layout, _lv_type_names[LV_TYPE_RAID0]))
goto_bad;
} else if (segtype_is_raid1(segtype)) {
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
if (!str_list_add_no_dup_check(mem, layout, _lv_type_names[LV_TYPE_RAID1]))
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
goto_bad;
segtypes: Add and use new segtype macros. Includes fixing an inverted raid10 segtype check in _raid_add_target_line.
2015-09-24 16:59:07 +03:00
} else if (segtype_is_raid10(segtype)) {
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
if (!str_list_add_no_dup_check(mem, layout, _lv_type_names[LV_TYPE_RAID10]))
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
goto_bad;
segtypes: Add and use new segtype macros. Includes fixing an inverted raid10 segtype check in _raid_add_target_line.
2015-09-24 16:59:07 +03:00
} else if (segtype_is_raid4(segtype)) {
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
if (!str_list_add_no_dup_check(mem, layout, _lv_type_names[LV_TYPE_RAID4]))
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
goto_bad;
segtypes: Add and use new segtype macros. Includes fixing an inverted raid10 segtype check in _raid_add_target_line.
2015-09-24 16:59:07 +03:00
} else if (segtype_is_any_raid5(segtype)) {
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
if (!str_list_add_no_dup_check(mem, layout, _lv_type_names[LV_TYPE_RAID5]))
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
goto_bad;
segtypes: Add and use new segtype macros. Includes fixing an inverted raid10 segtype check in _raid_add_target_line.
2015-09-24 16:59:07 +03:00
if (segtype_is_raid5_la(segtype)) {
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
if (!str_list_add_no_dup_check(mem, layout, _lv_type_names[LV_TYPE_RAID5_LA]))
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
goto_bad;
segtypes: Add and use new segtype macros. Includes fixing an inverted raid10 segtype check in _raid_add_target_line.
2015-09-24 16:59:07 +03:00
} else if (segtype_is_raid5_ra(segtype)) {
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
if (!str_list_add_no_dup_check(mem, layout, _lv_type_names[LV_TYPE_RAID5_RA]))
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
goto_bad;
segtypes: Add and use new segtype macros. Includes fixing an inverted raid10 segtype check in _raid_add_target_line.
2015-09-24 16:59:07 +03:00
} else if (segtype_is_raid5_ls(segtype)) {
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
if (!str_list_add_no_dup_check(mem, layout, _lv_type_names[LV_TYPE_RAID5_LS]))
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
goto_bad;
segtypes: Add and use new segtype macros. Includes fixing an inverted raid10 segtype check in _raid_add_target_line.
2015-09-24 16:59:07 +03:00
} else if (segtype_is_raid5_rs(segtype)) {
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
if (!str_list_add_no_dup_check(mem, layout, _lv_type_names[LV_TYPE_RAID5_RS]))
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
goto_bad;
}
segtypes: Add and use new segtype macros. Includes fixing an inverted raid10 segtype check in _raid_add_target_line.
2015-09-24 16:59:07 +03:00
} else if (segtype_is_any_raid6(segtype)) {
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
if (!str_list_add_no_dup_check(mem, layout, _lv_type_names[LV_TYPE_RAID6]))
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
goto_bad;
segtypes: Add and use new segtype macros. Includes fixing an inverted raid10 segtype check in _raid_add_target_line.
2015-09-24 16:59:07 +03:00
if (segtype_is_raid6_zr(segtype)) {
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
if (!str_list_add_no_dup_check(mem, layout, _lv_type_names[LV_TYPE_RAID6_ZR]))
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
goto_bad;
segtypes: Add and use new segtype macros. Includes fixing an inverted raid10 segtype check in _raid_add_target_line.
2015-09-24 16:59:07 +03:00
} else if (segtype_is_raid6_nr(segtype)) {
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
if (!str_list_add_no_dup_check(mem, layout, _lv_type_names[LV_TYPE_RAID6_NR]))
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
goto_bad;
segtypes: Add and use new segtype macros. Includes fixing an inverted raid10 segtype check in _raid_add_target_line.
2015-09-24 16:59:07 +03:00
} else if (segtype_is_raid6_nc(segtype)) {
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
if (!str_list_add_no_dup_check(mem, layout, _lv_type_names[LV_TYPE_RAID6_NC]))
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
goto_bad;
}
}
return 1;
bad:
return 0;
lv_manip: add get_lv_type_name/lv_is_linear and lv_is_striped helper fns The get_lv_type_name helps with translating volume type to human readable form (can be used in reports or various messages if needed). The lv_is_linear and lv_is_striped complete the set of lv_is_* functions that identify exact volume types.
2014-07-01 12:37:01 +04:00
}
refactor: rename 'lv_type' field to 'lv_role' The 'lv_type' field name was a bit misleading. Better one is 'lv_role' since this fields describes what's the actual use of the LV currently - its 'role'.
2014-08-25 11:07:03 +04:00
static int _lv_layout_and_role_thin(struct dm_pool *mem,
const struct logical_volume *lv,
struct dm_list *layout,
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
struct dm_list *role,
int *public_lv)
lv_manip: add get_lv_type_name/lv_is_linear and lv_is_striped helper fns The get_lv_type_name helps with translating volume type to human readable form (can be used in reports or various messages if needed). The lv_is_linear and lv_is_striped complete the set of lv_is_* functions that identify exact volume types.
2014-07-01 12:37:01 +04:00
{
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
int top_level = 0;
cleanup: gcc warning metadata/lv_manip.c:269: warning: declaration of "snapshot_count" shadows a global declaration There's existing function called "snapshot_count" so rename the variable to "snap_count".
2014-08-15 17:32:04 +04:00
unsigned snap_count;
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
/* non-top-level LVs */
if (lv_is_thin_pool_metadata(lv)) {
refactor: rename 'lv_type' field to 'lv_role' The 'lv_type' field name was a bit misleading. Better one is 'lv_role' since this fields describes what's the actual use of the LV currently - its 'role'.
2014-08-25 11:07:03 +04:00
if (!str_list_add_no_dup_check(mem, role, _lv_type_names[LV_TYPE_THIN]) ||
!str_list_add_no_dup_check(mem, role, _lv_type_names[LV_TYPE_POOL]) ||
!str_list_add_no_dup_check(mem, role, _lv_type_names[LV_TYPE_METADATA]))
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
goto_bad;
} else if (lv_is_thin_pool_data(lv)) {
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
if (!str_list_add_no_dup_check(mem, role, _lv_type_names[LV_TYPE_THIN]) ||
!str_list_add_no_dup_check(mem, role, _lv_type_names[LV_TYPE_POOL]) ||
refactor: rename 'lv_type' field to 'lv_role' The 'lv_type' field name was a bit misleading. Better one is 'lv_role' since this fields describes what's the actual use of the LV currently - its 'role'.
2014-08-25 11:07:03 +04:00
!str_list_add_no_dup_check(mem, role, _lv_type_names[LV_TYPE_DATA]))
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
goto_bad;
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
} else
top_level = 1;
if (!top_level) {
*public_lv = 0;
return 1;
}
/* top-level LVs */
if (lv_is_thin_volume(lv)) {
if (!str_list_add_no_dup_check(mem, layout, _lv_type_names[LV_TYPE_THIN]) ||
!str_list_add_no_dup_check(mem, layout, _lv_type_names[LV_TYPE_SPARSE]))
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
goto_bad;
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
if (lv_is_thin_origin(lv, &snap_count)) {
if (!str_list_add(mem, role, _lv_type_names[LV_TYPE_ORIGIN]) ||
!str_list_add_no_dup_check(mem, role, _lv_type_names[LV_TYPE_THINORIGIN]))
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
goto_bad;
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
if (snap_count > 1 &&
!str_list_add_no_dup_check(mem, role, _lv_type_names[LV_TYPE_MULTITHINORIGIN]))
goto_bad;
}
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
if (lv_is_thin_snapshot(lv))
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
if (!str_list_add(mem, role, _lv_type_names[LV_TYPE_SNAPSHOT]) ||
!str_list_add_no_dup_check(mem, role, _lv_type_names[LV_TYPE_THINSNAPSHOT]))
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
goto_bad;
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
} else if (lv_is_thin_pool(lv)) {
if (!str_list_add_no_dup_check(mem, layout, _lv_type_names[LV_TYPE_THIN]) ||
!str_list_add_no_dup_check(mem, layout, _lv_type_names[LV_TYPE_POOL]))
goto_bad;
*public_lv = 0;
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
}
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
if (lv_is_external_origin(lv)) {
if (!str_list_add(mem, role, _lv_type_names[LV_TYPE_ORIGIN]) ||
!str_list_add_no_dup_check(mem, role, _lv_type_names[LV_TYPE_EXTTHINORIGIN]))
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
goto_bad;
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
if (lv->external_count > 1 &&
!str_list_add_no_dup_check(mem, role, _lv_type_names[LV_TYPE_MULTIEXTTHINORIGIN]))
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
goto_bad;
}
return 1;
bad:
return 0;
lv_manip: add get_lv_type_name/lv_is_linear and lv_is_striped helper fns The get_lv_type_name helps with translating volume type to human readable form (can be used in reports or various messages if needed). The lv_is_linear and lv_is_striped complete the set of lv_is_* functions that identify exact volume types.
2014-07-01 12:37:01 +04:00
}
refactor: rename 'lv_type' field to 'lv_role' The 'lv_type' field name was a bit misleading. Better one is 'lv_role' since this fields describes what's the actual use of the LV currently - its 'role'.
2014-08-25 11:07:03 +04:00
static int _lv_layout_and_role_cache(struct dm_pool *mem,
const struct logical_volume *lv,
struct dm_list *layout,
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
struct dm_list *role,
int *public_lv)
lv_manip: add get_lv_type_name/lv_is_linear and lv_is_striped helper fns The get_lv_type_name helps with translating volume type to human readable form (can be used in reports or various messages if needed). The lv_is_linear and lv_is_striped complete the set of lv_is_* functions that identify exact volume types.
2014-07-01 12:37:01 +04:00
{
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
int top_level = 0;
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
/* non-top-level LVs */
if (lv_is_cache_pool_metadata(lv)) {
refactor: rename 'lv_type' field to 'lv_role' The 'lv_type' field name was a bit misleading. Better one is 'lv_role' since this fields describes what's the actual use of the LV currently - its 'role'.
2014-08-25 11:07:03 +04:00
if (!str_list_add_no_dup_check(mem, role, _lv_type_names[LV_TYPE_CACHE]) ||
!str_list_add_no_dup_check(mem, role, _lv_type_names[LV_TYPE_POOL]) ||
!str_list_add_no_dup_check(mem, role, _lv_type_names[LV_TYPE_METADATA]))
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
goto_bad;
} else if (lv_is_cache_pool_data(lv)) {
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
if (!str_list_add_no_dup_check(mem, role, _lv_type_names[LV_TYPE_CACHE]) ||
!str_list_add_no_dup_check(mem, role, _lv_type_names[LV_TYPE_POOL]) ||
refactor: rename 'lv_type' field to 'lv_role' The 'lv_type' field name was a bit misleading. Better one is 'lv_role' since this fields describes what's the actual use of the LV currently - its 'role'.
2014-08-25 11:07:03 +04:00
!str_list_add_no_dup_check(mem, role, _lv_type_names[LV_TYPE_DATA]))
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
goto_bad;
report: also display "mirror" keyword in lv_layout for mirrored mirror log and "cache" keyword in lv_layout for cached cache pool $ lvs -a -o name,vg_name,attr,layout,type LV VG Attr Layout Type lvol0 vg mwi-a-m--- mirror mirror [lvol0_mimage_0] vg iwi-aom--- linear image,mirror [lvol0_mimage_1] vg iwi-aom--- linear image,mirror [lvol0_mlog] vg mwi-aom--- mirror log,mirror [lvol0_mlog_mimage_0] vg iwi-aom--- linear image,mirror [lvol0_mlog_mimage_1] vg iwi-aom--- linear image,mirror (lvol0_mlog properly displayed as "mirror" layout for mirrored mirror log) $ lvs -a -o name,vg_name,attr,layout,type LV VG Attr Layout Type lvol0 vg Cwi---C--- cache,pool cache,pool [lvol0_cdata] vg Cwi------- linear cache,data,pool [lvol0_cmeta] vg ewi------- linear cache,metadata,pool [lvol1_pmspare] vg ewi------- linear metadata,pool,spare lvol2 vg Cwi---C--- cache,pool cache,pool [lvol2_cdata] vg Cwi---C--- cache cache,data,pool [lvol2_cdata_corig] vg owi---C--- linear cache,origin [lvol2_cmeta] vg ewi------- linear cache,metadata,pool (lvol2_cdata properly displayed as cached cache pool data)
2014-08-19 15:58:32 +04:00
if (lv_is_cache(lv) &&
!str_list_add_no_dup_check(mem, layout, _lv_type_names[LV_TYPE_CACHE]))
goto_bad;
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
} else if (lv_is_cache_origin(lv)) {
if (!str_list_add(mem, role, _lv_type_names[LV_TYPE_CACHE]) ||
!str_list_add(mem, role, _lv_type_names[LV_TYPE_ORIGIN]) ||
!str_list_add_no_dup_check(mem, role, _lv_type_names[LV_TYPE_CACHEORIGIN]))
goto_bad;
if (lv_is_cache(lv) &&
!str_list_add_no_dup_check(mem, layout, _lv_type_names[LV_TYPE_CACHE]))
goto_bad;
writecache: display layout and role fields
2019-09-20 22:54:00 +03:00
} else if (lv_is_writecache_origin(lv)) {
if (!str_list_add(mem, role, _lv_type_names[LV_TYPE_WRITECACHE]) ||
!str_list_add(mem, role, _lv_type_names[LV_TYPE_ORIGIN]) ||
!str_list_add_no_dup_check(mem, role, _lv_type_names[LV_TYPE_WRITECACHEORIGIN]))
goto_bad;
if (lv_is_writecache(lv) &&
!str_list_add_no_dup_check(mem, layout, _lv_type_names[LV_TYPE_WRITECACHE]))
goto_bad;
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
} else
top_level = 1;
if (!top_level) {
*public_lv = 0;
return 1;
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
}
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
/* top-level LVs */
if (lv_is_cache(lv) &&
!str_list_add_no_dup_check(mem, layout, _lv_type_names[LV_TYPE_CACHE]))
goto_bad;
writecache: display layout and role fields
2019-09-20 22:54:00 +03:00
else if (lv_is_writecache(lv) &&
!str_list_add_no_dup_check(mem, layout, _lv_type_names[LV_TYPE_WRITECACHE]))
goto_bad;
else if (lv_is_writecache_cachevol(lv)) {
if (!str_list_add_no_dup_check(mem, layout, _lv_type_names[LV_TYPE_WRITECACHE]) ||
!str_list_add_no_dup_check(mem, layout, _lv_type_names[LV_TYPE_CACHEVOL]))
goto_bad;
*public_lv = 0;
} else if (lv_is_cache_vol(lv)) {
if (!str_list_add_no_dup_check(mem, layout, _lv_type_names[LV_TYPE_CACHE]) ||
!str_list_add_no_dup_check(mem, layout, _lv_type_names[LV_TYPE_CACHEVOL]))
goto_bad;
*public_lv = 0;
} else if (lv_is_cache_pool(lv)) {
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
if (!str_list_add_no_dup_check(mem, layout, _lv_type_names[LV_TYPE_CACHE]) ||
!str_list_add_no_dup_check(mem, layout, _lv_type_names[LV_TYPE_POOL]))
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
goto_bad;
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
*public_lv = 0;
}
return 1;
bad:
return 0;
}
Allow dm-integrity to be used for raid images dm-integrity stores checksums of the data written to an LV, and returns an error if data read from the LV does not match the previously saved checksum. When used on raid images, dm-raid will correct the error by reading the block from another image, and the device user sees no error. The integrity metadata (checksums) are stored on an internal LV allocated by lvm for each linear image. The internal LV is allocated on the same PV as the image. Create a raid LV with an integrity layer over each raid image (for raid levels 1,4,5,6,10): lvcreate --type raidN --raidintegrity y [options] Add an integrity layer to images of an existing raid LV: lvconvert --raidintegrity y LV Remove the integrity layer from images of a raid LV: lvconvert --raidintegrity n LV Settings Use --raidintegritymode journal|bitmap (journal is default) to configure the method used by dm-integrity to ensure crash consistency. Initialization When integrity is added to an LV, the kernel needs to initialize the integrity metadata/checksums for all blocks in the LV. The data corruption checking performed by dm-integrity will only operate on areas of the LV that are already initialized. The progress of integrity initialization is reported by the "syncpercent" LV reporting field (and under the Cpy%Sync lvs column.) Example: create a raid1 LV with integrity: $ lvcreate --type raid1 -m1 --raidintegrity y -n rr -L1G foo Creating integrity metadata LV rr_rimage_0_imeta with size 12.00 MiB. Logical volume "rr_rimage_0_imeta" created. Creating integrity metadata LV rr_rimage_1_imeta with size 12.00 MiB. Logical volume "rr_rimage_1_imeta" created. Logical volume "rr" created. $ lvs -a foo LV VG Attr LSize Origin Cpy%Sync rr foo rwi-a-r--- 1.00g 4.93 [rr_rimage_0] foo gwi-aor--- 1.00g [rr_rimage_0_iorig] 41.02 [rr_rimage_0_imeta] foo ewi-ao---- 12.00m [rr_rimage_0_iorig] foo -wi-ao---- 1.00g [rr_rimage_1] foo gwi-aor--- 1.00g [rr_rimage_1_iorig] 39.45 [rr_rimage_1_imeta] foo ewi-ao---- 12.00m [rr_rimage_1_iorig] foo -wi-ao---- 1.00g [rr_rmeta_0] foo ewi-aor--- 4.00m [rr_rmeta_1] foo ewi-aor--- 4.00m
2019-11-21 01:07:27 +03:00
static int _lv_layout_and_role_integrity(struct dm_pool *mem,
const struct logical_volume *lv,
struct dm_list *layout,
struct dm_list *role,
int *public_lv)
{
int top_level = 0;
/* non-top-level LVs */
if (lv_is_integrity_metadata(lv)) {
if (!str_list_add_no_dup_check(mem, role, _lv_type_names[LV_TYPE_INTEGRITY]) ||
!str_list_add_no_dup_check(mem, role, _lv_type_names[LV_TYPE_METADATA]))
goto_bad;
} else if (lv_is_integrity_origin(lv)) {
if (!str_list_add_no_dup_check(mem, role, _lv_type_names[LV_TYPE_INTEGRITY]) ||
!str_list_add_no_dup_check(mem, role, _lv_type_names[LV_TYPE_ORIGIN]) ||
!str_list_add_no_dup_check(mem, role, _lv_type_names[LV_TYPE_INTEGRITYORIGIN]))
goto_bad;
} else
top_level = 1;
if (!top_level) {
*public_lv = 0;
return 1;
}
/* top-level LVs */
if (lv_is_integrity(lv)) {
if (!str_list_add_no_dup_check(mem, layout, _lv_type_names[LV_TYPE_INTEGRITY]))
goto_bad;
}
return 1;
bad:
return 0;
}
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
static int _lv_layout_and_role_thick_origin_snapshot(struct dm_pool *mem,
const struct logical_volume *lv,
struct dm_list *layout,
struct dm_list *role,
int *public_lv)
{
if (lv_is_origin(lv)) {
if (!str_list_add(mem, role, _lv_type_names[LV_TYPE_ORIGIN]) ||
!str_list_add_no_dup_check(mem, role, _lv_type_names[LV_TYPE_THICKORIGIN]))
goto_bad;
/*
* Thin volumes are also marked with virtual flag, but we don't show "virtual"
* layout for thin LVs as they have their own keyword for layout - "thin"!
* So rule thin LVs out here!
*/
if (lv_is_virtual(lv) && !lv_is_thin_volume(lv)) {
if (!str_list_add_no_dup_check(mem, layout, _lv_type_names[LV_TYPE_VIRTUAL]))
goto_bad;
*public_lv = 0;
}
if (lv->origin_count > 1 &&
!str_list_add_no_dup_check(mem, role, _lv_type_names[LV_TYPE_MULTITHICKORIGIN]))
goto_bad;
} else if (lv_is_cow(lv)) {
if (!str_list_add(mem, role, _lv_type_names[LV_TYPE_SNAPSHOT]) ||
!str_list_add_no_dup_check(mem, role, _lv_type_names[LV_TYPE_THICKSNAPSHOT]))
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
goto_bad;
}
return 1;
bad:
return 0;
}
lv_manip: layout and role support for vdo segment
2018-06-29 12:18:44 +03:00
static int _lv_layout_and_role_vdo(struct dm_pool *mem,
const struct logical_volume *lv,
struct dm_list *layout,
struct dm_list *role,
int *public_lv)
{
int top_level = 0;
/* non-top-level LVs */
if (lv_is_vdo_pool(lv)) {
if (!str_list_add_no_dup_check(mem, layout, _lv_type_names[LV_TYPE_VDO]) ||
!str_list_add_no_dup_check(mem, layout, _lv_type_names[LV_TYPE_POOL]))
goto_bad;
} else if (lv_is_vdo_pool_data(lv)) {
if (!str_list_add_no_dup_check(mem, role, _lv_type_names[LV_TYPE_VDO]) ||
!str_list_add_no_dup_check(mem, role, _lv_type_names[LV_TYPE_POOL]) ||
!str_list_add_no_dup_check(mem, role, _lv_type_names[LV_TYPE_DATA]))
goto_bad;
} else
top_level = 1;
if (!top_level) {
*public_lv = 0;
return 1;
}
/* top-level LVs */
if (lv_is_vdo(lv)) {
if (!str_list_add_no_dup_check(mem, layout, _lv_type_names[LV_TYPE_VDO]) ||
!str_list_add_no_dup_check(mem, layout, _lv_type_names[LV_TYPE_SPARSE]))
goto_bad;
}
return 1;
bad:
return 0;
}
refactor: rename 'lv_type' field to 'lv_role' The 'lv_type' field name was a bit misleading. Better one is 'lv_role' since this fields describes what's the actual use of the LV currently - its 'role'.
2014-08-25 11:07:03 +04:00
int lv_layout_and_role(struct dm_pool *mem, const struct logical_volume *lv,
struct dm_list **layout, struct dm_list **role) {
cleanup: drop unused value assign Dop unused value assignments. Unknown is detected via other combination (!linear && !striped). Also change the log_error() message into a warning, since the function is not really returning error, but still keep the INTERNAL_ERROR. Ret value is always set later.
2015-02-19 16:03:45 +03:00
int linear, striped;
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
struct lv_segment *seg;
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
int public_lv = 1;
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
refactor: rename 'lv_type' field to 'lv_role' The 'lv_type' field name was a bit misleading. Better one is 'lv_role' since this fields describes what's the actual use of the LV currently - its 'role'.
2014-08-25 11:07:03 +04:00
*layout = *role = NULL;
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
if (!(*layout = str_list_create(mem))) {
log_error("LV layout list allocation failed");
cleanup: simplify error path code Mempool needs to free only with first alllocated element, everything allocated afterwards is released as well.
2015-02-19 16:06:17 +03:00
return 0;
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
}
refactor: rename 'lv_type' field to 'lv_role' The 'lv_type' field name was a bit misleading. Better one is 'lv_role' since this fields describes what's the actual use of the LV currently - its 'role'.
2014-08-25 11:07:03 +04:00
if (!(*role = str_list_create(mem))) {
log_error("LV role list allocation failed");
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
goto bad;
}
report: add new 'none' lv_layout and 'history' lv_role and mark historical LVs that way Report proper values for historical LVs in lv_layout and lv_role fields. Any historical LV doesn't have any layout anymore and the role is "history". For example: $ lvs -H -o name,lv_attr,lv_layout,lv_role vg/-lvol1 LV Attr Layout Role -lvol1 ----h----- none public,history
2016-03-01 17:25:04 +03:00
if (lv_is_historical(lv)) {
if (!str_list_add_no_dup_check(mem, *layout, _lv_type_names[LV_TYPE_NONE]) ||
!str_list_add_no_dup_check(mem, *role, _lv_type_names[LV_TYPE_HISTORY]))
goto_bad;
}
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
/* Mirrors and related */
mirrors: Fix checks for mirror/raid/pvmove LVs. Try to enforce consistent macro usage along these lines: lv_is_mirror - mirror that uses the original dm-raid1 implementation (segment type "mirror") lv_is_mirror_type - also includes internal mirror image and log LVs lv_is_raid - raid volume that uses the new dm-raid implementation (segment type "raid") lv_is_raid_type - also includes internal raid image / log / metadata LVs lv_is_mirrored - LV is mirrored using either kernel implementation (excludes non-mirror modes like raid5 etc.) lv_is_pvmove - internal pvmove volume
2014-09-16 03:13:46 +04:00
if ((lv_is_mirror_type(lv) || lv_is_pvmove(lv)) &&
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
!_lv_layout_and_role_mirror(mem, lv, *layout, *role, &public_lv))
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
goto_bad;
/* RAIDs and related */
if (lv_is_raid_type(lv) &&
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
!_lv_layout_and_role_raid(mem, lv, *layout, *role, &public_lv))
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
goto_bad;
/* Thins and related */
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
if ((lv_is_thin_type(lv) || lv_is_external_origin(lv)) &&
!_lv_layout_and_role_thin(mem, lv, *layout, *role, &public_lv))
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
goto_bad;
/* Caches and related */
writecache: display layout and role fields
2019-09-20 22:54:00 +03:00
if ((lv_is_cache_type(lv) || lv_is_cache_origin(lv) || lv_is_writecache(lv) || lv_is_writecache_origin(lv)) &&
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
!_lv_layout_and_role_cache(mem, lv, *layout, *role, &public_lv))
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
goto_bad;
Allow dm-integrity to be used for raid images dm-integrity stores checksums of the data written to an LV, and returns an error if data read from the LV does not match the previously saved checksum. When used on raid images, dm-raid will correct the error by reading the block from another image, and the device user sees no error. The integrity metadata (checksums) are stored on an internal LV allocated by lvm for each linear image. The internal LV is allocated on the same PV as the image. Create a raid LV with an integrity layer over each raid image (for raid levels 1,4,5,6,10): lvcreate --type raidN --raidintegrity y [options] Add an integrity layer to images of an existing raid LV: lvconvert --raidintegrity y LV Remove the integrity layer from images of a raid LV: lvconvert --raidintegrity n LV Settings Use --raidintegritymode journal|bitmap (journal is default) to configure the method used by dm-integrity to ensure crash consistency. Initialization When integrity is added to an LV, the kernel needs to initialize the integrity metadata/checksums for all blocks in the LV. The data corruption checking performed by dm-integrity will only operate on areas of the LV that are already initialized. The progress of integrity initialization is reported by the "syncpercent" LV reporting field (and under the Cpy%Sync lvs column.) Example: create a raid1 LV with integrity: $ lvcreate --type raid1 -m1 --raidintegrity y -n rr -L1G foo Creating integrity metadata LV rr_rimage_0_imeta with size 12.00 MiB. Logical volume "rr_rimage_0_imeta" created. Creating integrity metadata LV rr_rimage_1_imeta with size 12.00 MiB. Logical volume "rr_rimage_1_imeta" created. Logical volume "rr" created. $ lvs -a foo LV VG Attr LSize Origin Cpy%Sync rr foo rwi-a-r--- 1.00g 4.93 [rr_rimage_0] foo gwi-aor--- 1.00g [rr_rimage_0_iorig] 41.02 [rr_rimage_0_imeta] foo ewi-ao---- 12.00m [rr_rimage_0_iorig] foo -wi-ao---- 1.00g [rr_rimage_1] foo gwi-aor--- 1.00g [rr_rimage_1_iorig] 39.45 [rr_rimage_1_imeta] foo ewi-ao---- 12.00m [rr_rimage_1_iorig] foo -wi-ao---- 1.00g [rr_rmeta_0] foo ewi-aor--- 4.00m [rr_rmeta_1] foo ewi-aor--- 4.00m
2019-11-21 01:07:27 +03:00
/* Integrity related */
if ((lv_is_integrity(lv) || lv_is_integrity_origin(lv) || lv_is_integrity_metadata(lv)) &&
!_lv_layout_and_role_integrity(mem, lv, *layout, *role, &public_lv))
goto_bad;
lv_manip: layout and role support for vdo segment
2018-06-29 12:18:44 +03:00
/* VDO and related */
if (lv_is_vdo_type(lv) &&
!_lv_layout_and_role_vdo(mem, lv, *layout, *role, &public_lv))
goto_bad;
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
/* Pool-specific */
if (lv_is_pool_metadata_spare(lv)) {
if (!str_list_add_no_dup_check(mem, *role, _lv_type_names[LV_TYPE_POOL]) ||
!str_list_add_no_dup_check(mem, *role, _lv_type_names[LV_TYPE_SPARE]))
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
goto_bad;
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
public_lv = 0;
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
}
/* Old-style origins/snapshots, virtual origins */
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
if (!_lv_layout_and_role_thick_origin_snapshot(mem, lv, *layout, *role, &public_lv))
goto_bad;
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
report: identify LV hodling sanlock locks as 'private,lockd,sanlock' within lv_role report field Before this patch: $ lvs -a -o name,layout,role test/lvmlock LV Layout Role [lvmlock] linear public With this patch applied: $ lvs -a -o name,layout,role test/lvmlock LV Layout Role [lvmlock] linear private,lockd,sanlock
2015-10-08 14:44:21 +03:00
if (lv_is_lockd_sanlock_lv(lv)) {
if (!str_list_add_no_dup_check(mem, *role, _lv_type_names[LV_TYPE_LOCKD]) ||
!str_list_add_no_dup_check(mem, *role, _lv_type_names[LV_TYPE_SANLOCK]))
goto_bad;
public_lv = 0;
}
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
/*
* If layout not yet determined, it must be either
* linear or striped or mixture of these two.
*/
if (dm_list_empty(*layout)) {
cleanup: drop unused value assign Dop unused value assignments. Unknown is detected via other combination (!linear && !striped). Also change the log_error() message into a warning, since the function is not really returning error, but still keep the INTERNAL_ERROR. Ret value is always set later.
2015-02-19 16:03:45 +03:00
linear = striped = 0;
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
dm_list_iterate_items(seg, &lv->segments) {
if (seg_is_linear(seg))
linear = 1;
else if (seg_is_striped(seg))
striped = 1;
else {
/*
* This should not happen but if it does
* we'll see that there's "unknown" layout
* present. This means we forgot to detect
refactor: rename 'lv_type' field to 'lv_role' The 'lv_type' field name was a bit misleading. Better one is 'lv_role' since this fields describes what's the actual use of the LV currently - its 'role'.
2014-08-25 11:07:03 +04:00
* the role above and we need add proper
* detection for such role!
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
*/
cleanup: drop unused value assign Dop unused value assignments. Unknown is detected via other combination (!linear && !striped). Also change the log_error() message into a warning, since the function is not really returning error, but still keep the INTERNAL_ERROR. Ret value is always set later.
2015-02-19 16:03:45 +03:00
log_warn(INTERNAL_ERROR "WARNING: Failed to properly detect "
"layout and role for LV %s/%s.",
lv->vg->name, lv->name);
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
}
}
if (linear &&
!str_list_add_no_dup_check(mem, *layout, _lv_type_names[LV_TYPE_LINEAR]))
goto_bad;
if (striped &&
!str_list_add_no_dup_check(mem, *layout, _lv_type_names[LV_TYPE_STRIPED]))
goto_bad;
if (!linear && !striped &&
!str_list_add_no_dup_check(mem, *layout, _lv_type_names[LV_TYPE_UNKNOWN]))
goto_bad;
}
cleanup: consolidate lv_layout and lv_role reporting This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
2014-08-25 12:02:32 +04:00
/* finally, add either 'public' or 'private' role to the LV */
if (public_lv) {
if (!str_list_add_h_no_dup_check(mem, *role, _lv_type_names[LV_TYPE_PUBLIC]))
goto_bad;
} else {
if (!str_list_add_h_no_dup_check(mem, *role, _lv_type_names[LV_TYPE_PRIVATE]))
goto_bad;
}
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
return 1;
bad:
cleanup: simplify error path code Mempool needs to free only with first alllocated element, everything allocated afterwards is released as well.
2015-02-19 16:06:17 +03:00
dm_pool_free(mem, *layout);
Add lv_layout_and_type fn, lv_layout and lv_type reporting fields. The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
2014-08-13 12:03:45 +04:00
return 0;
lv_manip: add get_lv_type_name/lv_is_linear and lv_is_striped helper fns The get_lv_type_name helps with translating volume type to human readable form (can be used in reports or various messages if needed). The lv_is_linear and lv_is_striped complete the set of lv_is_* functions that identify exact volume types.
2014-07-01 12:37:01 +04:00
}
Misc: Make get_pv_list_for_lv() available to more than just RAID The function 'get_pv_list_for_lv' will assemble all the PVs that are used by the specified LV. It uses 'for_each_sub_lv' to traverse all of the sub-lvs which may compose it.
2013-08-23 17:40:13 +04:00
struct dm_list_and_mempool {
struct dm_list *list;
struct dm_pool *mem;
};
lv_manip: drop cmd pointer from for_each_sub_lv Drop unused passed cmd pointer from function. TODO: We have two similar functions (though not identical) lv_manip.c: for_each_sub_lv() metadata.c: _lv_each_dependency() They seem to not always match - we should probably convert to use only a single function.
2014-03-27 13:35:07 +04:00
static int _get_pv_list_for_lv(struct logical_volume *lv, void *data)
Misc: Make get_pv_list_for_lv() available to more than just RAID The function 'get_pv_list_for_lv' will assemble all the PVs that are used by the specified LV. It uses 'for_each_sub_lv' to traverse all of the sub-lvs which may compose it.
2013-08-23 17:40:13 +04:00
{
int dup_found;
uint32_t s;
struct pv_list *pvl;
struct lv_segment *seg;
struct dm_list *pvs = ((struct dm_list_and_mempool *)data)->list;
struct dm_pool *mem = ((struct dm_list_and_mempool *)data)->mem;
dm_list_iterate_items(seg, &lv->segments) {
for (s = 0; s < seg->area_count; s++) {
dup_found = 0;
if (seg_type(seg, s) != AREA_PV)
continue;
/* do not add duplicates */
dm_list_iterate_items(pvl, pvs)
if (pvl->pv == seg_pv(seg, s))
dup_found = 1;
if (dup_found)
continue;
if (!(pvl = dm_pool_zalloc(mem, sizeof(*pvl)))) {
log_error("Failed to allocate memory");
return 0;
}
pvl->pv = seg_pv(seg, s);
log_debug_metadata(" %s/%s uses %s", lv->vg->name,
lv->name, pv_dev_name(pvl->pv));
dm_list_add(pvs, &pvl->list);
}
}
return 1;
}
/*
* get_pv_list_for_lv
* @mem - mempool to allocate the list from.
* @lv
* @pvs - The list to add pv_list items to.
*
* 'pvs' is filled with 'pv_list' items for PVs that compose the LV.
* If the 'pvs' list already has items in it, duplicates will not be
* added. So, it is safe to repeatedly call this function for different
* LVs and build up a list of PVs for them all.
*
* Memory to create the list is obtained from the mempool provided.
*
* Returns: 1 on success, 0 on error
*/
int get_pv_list_for_lv(struct dm_pool *mem,
struct logical_volume *lv, struct dm_list *pvs)
{
struct dm_list_and_mempool context = { pvs, mem };
log_debug_metadata("Generating list of PVs that %s/%s uses:",
lv->vg->name, lv->name);
lv_manip: drop cmd pointer from for_each_sub_lv Drop unused passed cmd pointer from function. TODO: We have two similar functions (though not identical) lv_manip.c: for_each_sub_lv() metadata.c: _lv_each_dependency() They seem to not always match - we should probably convert to use only a single function.
2014-03-27 13:35:07 +04:00
if (!_get_pv_list_for_lv(lv, &context))
Misc: Make get_pv_list_for_lv() available to more than just RAID The function 'get_pv_list_for_lv' will assemble all the PVs that are used by the specified LV. It uses 'for_each_sub_lv' to traverse all of the sub-lvs which may compose it.
2013-08-23 17:40:13 +04:00
return_0;
lv_manip: drop cmd pointer from for_each_sub_lv Drop unused passed cmd pointer from function. TODO: We have two similar functions (though not identical) lv_manip.c: for_each_sub_lv() metadata.c: _lv_each_dependency() They seem to not always match - we should probably convert to use only a single function.
2014-03-27 13:35:07 +04:00
return for_each_sub_lv(lv, &_get_pv_list_for_lv, &context);
Misc: Make get_pv_list_for_lv() available to more than just RAID The function 'get_pv_list_for_lv' will assemble all the PVs that are used by the specified LV. It uses 'for_each_sub_lv' to traverse all of the sub-lvs which may compose it.
2013-08-23 17:40:13 +04:00
}
clean-up: Rename lvm.conf setting 'mirror_region_size' to 'raid_region_size' We have been using 'mirror_region_size' in lvm.conf as the default region size for RAID logical volumes as well as mirror logical volumes. Since, "raid" is more inclusive and representative than "mirror", I have changed the name of this setting. We must still check for the old setting and warn the user if we are overriding it with the new setting if both happen to be present.
2013-02-21 00:40:17 +04:00
/*
* get_default_region_size
* @cmd
*
* 'mirror_region_size' and 'raid_region_size' are effectively the same thing.
* However, "raid" is more inclusive than "mirror", so the name has been
* changed. This function checks for the old setting and warns the user if
* it is being overridden by the new setting (i.e. warn if both settings are
* present).
*
* Note that the config files give defaults in kiB terms, but we
* return the value in terms of sectors.
*
* Returns: default region_size in sectors
*/
mirror: Validate raid region size config setting. If necessary, round down to a power of 2 the raid/mirror region size taken from the config files.
2014-12-04 01:47:08 +03:00
static int _get_default_region_size(struct cmd_context *cmd)
clean-up: Rename lvm.conf setting 'mirror_region_size' to 'raid_region_size' We have been using 'mirror_region_size' in lvm.conf as the default region size for RAID logical volumes as well as mirror logical volumes. Since, "raid" is more inclusive and representative than "mirror", I have changed the name of this setting. We must still check for the old setting and warn the user if we are overriding it with the new setting if both happen to be present.
2013-02-21 00:40:17 +04:00
{
int mrs, rrs;
/*
* 'mirror_region_size' is the old setting. It is overridden
* by the new setting, 'raid_region_size'.
*/
config: add profile arg to find_config_tree_int
2013-06-25 14:30:34 +04:00
mrs = 2 * find_config_tree_int(cmd, activation_mirror_region_size_CFG, NULL);
rrs = 2 * find_config_tree_int(cmd, activation_raid_region_size_CFG, NULL);
clean-up: Rename lvm.conf setting 'mirror_region_size' to 'raid_region_size' We have been using 'mirror_region_size' in lvm.conf as the default region size for RAID logical volumes as well as mirror logical volumes. Since, "raid" is more inclusive and representative than "mirror", I have changed the name of this setting. We must still check for the old setting and warn the user if we are overriding it with the new setting if both happen to be present.
2013-02-21 00:40:17 +04:00
if (!mrs && !rrs)
return DEFAULT_RAID_REGION_SIZE * 2;
if (!mrs)
return rrs;
if (!rrs)
return mrs;
if (mrs != rrs)
log_verbose("Overriding default 'mirror_region_size' setting"
" with 'raid_region_size' setting of %u kiB",
rrs / 2);
return rrs;
}
mirror: Validate raid region size config setting. If necessary, round down to a power of 2 the raid/mirror region size taken from the config files.
2014-12-04 01:47:08 +03:00
static int _round_down_pow2(int r)
{
/* Set all bits to the right of the leftmost set bit */
r |= (r >> 1);
r |= (r >> 2);
r |= (r >> 4);
r |= (r >> 8);
r |= (r >> 16);
/* Pull out the leftmost set bit */
return r & ~(r >> 1);
}
lv_manip: get_default_region_size return uint32_t
2020-08-28 21:07:34 +03:00
uint32_t get_default_region_size(struct cmd_context *cmd)
mirror: Validate raid region size config setting. If necessary, round down to a power of 2 the raid/mirror region size taken from the config files.
2014-12-04 01:47:08 +03:00
{
args: use arg parsing function for region size Consolidate the validation of the region size arg in a new arg parsing function.
2017-02-08 00:12:24 +03:00
int pagesize = lvm_getpagesize();
mirror: Validate raid region size config setting. If necessary, round down to a power of 2 the raid/mirror region size taken from the config files.
2014-12-04 01:47:08 +03:00
int region_size = _get_default_region_size(cmd);
macros: Use is_power_of_2.
2016-06-30 19:59:44 +03:00
if (!is_power_of_2(region_size)) {
mirror: Validate raid region size config setting. If necessary, round down to a power of 2 the raid/mirror region size taken from the config files.
2014-12-04 01:47:08 +03:00
region_size = _round_down_pow2(region_size);
style: Miscellaneous tidying up of metadata/lv*
2015-09-23 16:37:52 +03:00
log_verbose("Reducing region size to %u kiB (power of 2).",
mirror: Validate raid region size config setting. If necessary, round down to a power of 2 the raid/mirror region size taken from the config files.
2014-12-04 01:47:08 +03:00
region_size / 2);
}
args: use arg parsing function for region size Consolidate the validation of the region size arg in a new arg parsing function.
2017-02-08 00:12:24 +03:00
if (region_size % (pagesize >> SECTOR_SHIFT)) {
region_size = DEFAULT_RAID_REGION_SIZE * 2;
log_verbose("Using default region size %u kiB (multiple of page size).",
region_size / 2);
}
lv_manip: get_default_region_size return uint32_t
2020-08-28 21:07:34 +03:00
return (uint32_t) region_size;
mirror: Validate raid region size config setting. If necessary, round down to a power of 2 the raid/mirror region size taken from the config files.
2014-12-04 01:47:08 +03:00
}
pre-release review cleanups
2008-01-17 20:17:09 +03:00
int add_seg_to_segs_using_this_lv(struct logical_volume *lv,
struct lv_segment *seg)
Maintain lists of stacked LV segments using each LV.
2008-01-16 22:00:59 +03:00
{
struct seg_list *sl;
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
dm_list_iterate_items(sl, &lv->segs_using_this_lv) {
Maintain lists of stacked LV segments using each LV.
2008-01-16 22:00:59 +03:00
if (sl->seg == seg) {
sl->count++;
return 1;
}
}
cleanup: add some dots and use display_lvname Just some more VG/LV printing.
2016-11-25 16:08:39 +03:00
log_very_verbose("Adding %s:" FMTu32 " as an user of %s.",
display_lvname(seg->lv), seg->le, display_lvname(lv));
add lvconvert messages
2008-01-19 01:00:46 +03:00
Fix all segments memory is allocated from vg private mempool. Physical segments were still allocated from global command context mempool. This leads to very high memory usage when activating large VG (vgchange). (Memory usage was about 2G when >3000LVs). Fix it by properly using vg->vgmem private pool, so all the memory is released early. New memory pool parameter is needed here for pv_split_segment function. Also fix the same problem in some minor allocations (vg description, lv segment split).
2010-03-31 21:23:18 +04:00
if (!(sl = dm_pool_zalloc(lv->vg->vgmem, sizeof(*sl)))) {
cleanup: add some dots and use display_lvname Just some more VG/LV printing.
2016-11-25 16:08:39 +03:00
log_error("Failed to allocate segment list.");
Maintain lists of stacked LV segments using each LV.
2008-01-16 22:00:59 +03:00
return 0;
}
sl->count = 1;
sl->seg = seg;
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
dm_list_add(&lv->segs_using_this_lv, &sl->list);
Maintain lists of stacked LV segments using each LV.
2008-01-16 22:00:59 +03:00
return 1;
}
pre-release review cleanups
2008-01-17 20:17:09 +03:00
int remove_seg_from_segs_using_this_lv(struct logical_volume *lv,
struct lv_segment *seg)
Maintain lists of stacked LV segments using each LV.
2008-01-16 22:00:59 +03:00
{
struct seg_list *sl;
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
dm_list_iterate_items(sl, &lv->segs_using_this_lv) {
Maintain lists of stacked LV segments using each LV.
2008-01-16 22:00:59 +03:00
if (sl->seg != seg)
continue;
if (sl->count > 1)
sl->count--;
add lvconvert messages
2008-01-19 01:00:46 +03:00
else {
cleanup: add some dots and use display_lvname Just some more VG/LV printing.
2016-11-25 16:08:39 +03:00
log_very_verbose("%s:" FMTu32 " is no longer a user of %s.",
display_lvname(seg->lv), seg->le,
display_lvname(lv));
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
dm_list_del(&sl->list);
add lvconvert messages
2008-01-19 01:00:46 +03:00
}
Maintain lists of stacked LV segments using each LV.
2008-01-16 22:00:59 +03:00
return 1;
}
cleanup: add some dots and use display_lvname Just some more VG/LV printing.
2016-11-25 16:08:39 +03:00
log_error(INTERNAL_ERROR "Segment %s:" FMTu32 " is not a user of %s.",
display_lvname(seg->lv), seg->le, display_lvname(lv));
Maintain lists of stacked LV segments using each LV.
2008-01-16 22:00:59 +03:00
return 0;
}
/*
* This is a function specialized for the common case where there is
* only one segment which uses the LV.
* e.g. the LV is a layer inserted by insert_layer_for_lv().
*
* In general, walk through lv->segs_using_this_lv.
*/
report: Add lv_parent field. Only defined for thin/cache/raid/mirror at this stage as it relies on get_only_segment_using_this_lv().
2014-07-04 02:49:34 +04:00
struct lv_segment *get_only_segment_using_this_lv(const struct logical_volume *lv)
Maintain lists of stacked LV segments using each LV.
2008-01-16 22:00:59 +03:00
{
struct seg_list *sl;
allocation: misc fixes for percent/raid rounding Several fixes for the recent changes that treat allocation percentages as upper limits. Improve messages to make it easier to see what is happening. Fix some cases that failed with errors when they didn't need to. Fix crashes when first_seg() returns NULL. Remove a couple of log_errors that were actually debugging messages.
2014-02-22 04:26:01 +04:00
if (!lv) {
log_error(INTERNAL_ERROR "get_only_segment_using_this_lv() called with NULL LV.");
return NULL;
}
cleanup: avoid dm_list size calc in common path Calculate dm_list_size only when there is not just a single ont segment in list - so it's only counted on error path.
2014-11-05 01:06:21 +03:00
dm_list_iterate_items(sl, &lv->segs_using_this_lv) {
/* Needs to be he only item in list */
if (!dm_list_end(&lv->segs_using_this_lv, &sl->list))
break;
if (sl->count != 1) {
log_error("%s is expected to have only one segment using it, "
cleanup: add some dots and use display_lvname Just some more VG/LV printing.
2016-11-25 16:08:39 +03:00
"while %s:" FMTu32 " uses it %d times.",
display_lvname(lv), display_lvname(sl->seg->lv),
sl->seg->le, sl->count);
cleanup: avoid dm_list size calc in common path Calculate dm_list_size only when there is not just a single ont segment in list - so it's only counted on error path.
2014-11-05 01:06:21 +03:00
return NULL;
}
Maintain lists of stacked LV segments using each LV.
2008-01-16 22:00:59 +03:00
cleanup: avoid dm_list size calc in common path Calculate dm_list_size only when there is not just a single ont segment in list - so it's only counted on error path.
2014-11-05 01:06:21 +03:00
return sl->seg;
additional safety check on new segment list
2008-01-16 23:00:01 +03:00
}
cleanup: avoid dm_list size calc in common path Calculate dm_list_size only when there is not just a single ont segment in list - so it's only counted on error path.
2014-11-05 01:06:21 +03:00
log_error("%s is expected to have only one segment using it, while it has %d.",
display_lvname(lv), dm_list_size(&lv->segs_using_this_lv));
return NULL;
Maintain lists of stacked LV segments using each LV.
2008-01-16 22:00:59 +03:00
}
Determine parallel PVs to avoid with ALLOC_NORMAL allocation. (untested)
2005-11-28 23:01:00 +03:00
/*
* PVs used by a segment of an LV
*/
struct seg_pvs {
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
struct dm_list list;
Determine parallel PVs to avoid with ALLOC_NORMAL allocation. (untested)
2005-11-28 23:01:00 +03:00
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
struct dm_list pvs; /* struct pv_list */
Determine parallel PVs to avoid with ALLOC_NORMAL allocation. (untested)
2005-11-28 23:01:00 +03:00
uint32_t le;
uint32_t len;
};
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
static struct seg_pvs *_find_seg_pvs_by_le(struct dm_list *list, uint32_t le)
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
{
struct seg_pvs *spvs;
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
dm_list_iterate_items(spvs, list)
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
if (le >= spvs->le && le < spvs->le + spvs->len)
return spvs;
return NULL;
}
o Sync up todays work on converting to the segmented representation of logical volumes. It includes: format1 changes. metadata.h changes. lv_manip.c changed (striped allocation still not done though). activate.c changes. Nothing has been near a compiler as yet. Alasdair can you look at changing display.c to use to output the mappings in a more segment oriented format please ? I haven't put the span list into struct physical_volume to represent allocated extents. I think the burden of maintaining it for things like lv_extend may out weigh it's uses.
2001-11-27 19:37:33 +03:00
/*
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
* Find first unused LV number.
o Sync up todays work on converting to the segmented representation of logical volumes. It includes: format1 changes. metadata.h changes. lv_manip.c changed (striped allocation still not done though). activate.c changes. Nothing has been near a compiler as yet. Alasdair can you look at changing display.c to use to output the mappings in a more segment oriented format please ? I haven't put the span list into struct physical_volume to represent allocated extents. I think the burden of maintaining it for things like lv_extend may out weigh it's uses.
2001-11-27 19:37:33 +03:00
*/
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
uint32_t find_free_lvnum(struct logical_volume *lv)
o Sync up todays work on converting to the segmented representation of logical volumes. It includes: format1 changes. metadata.h changes. lv_manip.c changed (striped allocation still not done though). activate.c changes. Nothing has been near a compiler as yet. Alasdair can you look at changing display.c to use to output the mappings in a more segment oriented format please ? I haven't put the span list into struct physical_volume to represent allocated extents. I think the burden of maintaining it for things like lv_extend may out weigh it's uses.
2001-11-27 19:37:33 +03:00
{
cleanup: replace memset with struct initilization Simplifies the code, properly detects too long socket paths, drops unused parameter.
2012-06-21 23:19:28 +04:00
int lvnum_used[MAX_RESTRICTED_LVS + 1] = { 0 };
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
uint32_t i = 0;
struct lv_list *lvl;
int lvnum;
o Sync up todays work on converting to the segmented representation of logical volumes. It includes: format1 changes. metadata.h changes. lv_manip.c changed (striped allocation still not done though). activate.c changes. Nothing has been near a compiler as yet. Alasdair can you look at changing display.c to use to output the mappings in a more segment oriented format please ? I haven't put the span list into struct physical_volume to represent allocated extents. I think the burden of maintaining it for things like lv_extend may out weigh it's uses.
2001-11-27 19:37:33 +03:00
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
dm_list_iterate_items(lvl, &lv->vg->lvs) {
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
lvnum = lvnum_from_lvid(&lvl->lv->lvid);
if (lvnum <= MAX_RESTRICTED_LVS)
lvnum_used[lvnum] = 1;
o Sync up todays work on converting to the segmented representation of logical volumes. It includes: format1 changes. metadata.h changes. lv_manip.c changed (striped allocation still not done though). activate.c changes. Nothing has been near a compiler as yet. Alasdair can you look at changing display.c to use to output the mappings in a more segment oriented format please ? I haven't put the span list into struct physical_volume to represent allocated extents. I think the burden of maintaining it for things like lv_extend may out weigh it's uses.
2001-11-27 19:37:33 +03:00
}
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
while (lvnum_used[i])
i++;
o Metadata area struct change. o Support physical extent restrictions on PV lists for allocations e.g. lvcreate -l 200 vg1 /dev/sda1:100-199:300-399
2003-04-25 02:23:24 +04:00
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
/* FIXME What if none are free? */
o Sync up todays work on converting to the segmented representation of logical volumes. It includes: format1 changes. metadata.h changes. lv_manip.c changed (striped allocation still not done though). activate.c changes. Nothing has been near a compiler as yet. Alasdair can you look at changing display.c to use to output the mappings in a more segment oriented format please ? I haven't put the span list into struct physical_volume to represent allocated extents. I think the burden of maintaining it for things like lv_extend may out weigh it's uses.
2001-11-27 19:37:33 +03:00
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
return i;
o Sync up todays work on converting to the segmented representation of logical volumes. It includes: format1 changes. metadata.h changes. lv_manip.c changed (striped allocation still not done though). activate.c changes. Nothing has been near a compiler as yet. Alasdair can you look at changing display.c to use to output the mappings in a more segment oriented format please ? I haven't put the span list into struct physical_volume to represent allocated extents. I think the burden of maintaining it for things like lv_extend may out weigh it's uses.
2001-11-27 19:37:33 +03:00
}
report: select: refactor: move percent handling code to libdm for reuse
2014-06-09 14:08:27 +04:00
dm_percent_t copy_percent(const struct logical_volume *lv)
mirror/raid: Move 'copy_percent' to common code (mirror.c -> lv_manip.c) The 'copy_percent' function takes the 'extents_copied' field from each segment in an LV to create the numerator for the ratio that is to become the copy_percent. (Otherwise known as the 'sync' percent for non-pvmove uses, like mirror LVs and RAID LVs.) This function safely works on RAID - not just mirrors - so it is better to have it in lv_manip.c rather than mirror.c. There's a lot of different functions that do a lot of different things in lv_manip.c, so I placed the function near a function in lv_manip.c that it was close to in metadata-exported.h. Different placement in the file or a different name for the function may be useful.
2012-10-24 05:33:54 +04:00
{
uint32_t numerator = 0u, denominator = 0u;
struct lv_segment *seg;
dm_list_iterate_items(seg, &lv->segments) {
denominator += seg->area_len;
style: Miscellaneous tidying up of metadata/lv*
2015-09-23 16:37:52 +03:00
/* FIXME Generalise name of 'extents_copied' field */
raid0: Add raid0 segment type. This remains experimental and quite restrictive so should only be used for testing at this stage. (E.g. lvreduce is not supported.)
2016-05-23 18:46:38 +03:00
if (((seg_is_raid(seg) && !seg_is_any_raid0(seg)) || seg_is_mirrored(seg)) &&
metadata: cleanup comments and formatting
2013-07-09 15:34:48 +04:00
(seg->area_count > 1))
mirror/raid: Move 'copy_percent' to common code (mirror.c -> lv_manip.c) The 'copy_percent' function takes the 'extents_copied' field from each segment in an LV to create the numerator for the ratio that is to become the copy_percent. (Otherwise known as the 'sync' percent for non-pvmove uses, like mirror LVs and RAID LVs.) This function safely works on RAID - not just mirrors - so it is better to have it in lv_manip.c rather than mirror.c. There's a lot of different functions that do a lot of different things in lv_manip.c, so I placed the function near a function in lv_manip.c that it was close to in metadata-exported.h. Different placement in the file or a different name for the function may be useful.
2012-10-24 05:33:54 +04:00
numerator += seg->extents_copied;
else
numerator += seg->area_len;
}
report: fix report copy_percent value When mirror/raid called copy_percent function to return, when 100% was supposed to be returned, wrong float 100.0 value could have been reported back instead of dm_percent_t DM_PERCENT_100. There is broken API somewhere, since the function here rely on actively being modifid VG content even when doing 'lvs' operation. (extents_copies)
2016-05-27 14:48:30 +03:00
return denominator ? dm_make_percent(numerator, denominator) : DM_PERCENT_100;
mirror/raid: Move 'copy_percent' to common code (mirror.c -> lv_manip.c) The 'copy_percent' function takes the 'extents_copied' field from each segment in an LV to create the numerator for the ratio that is to become the copy_percent. (Otherwise known as the 'sync' percent for non-pvmove uses, like mirror LVs and RAID LVs.) This function safely works on RAID - not just mirrors - so it is better to have it in lv_manip.c rather than mirror.c. There's a lot of different functions that do a lot of different things in lv_manip.c, so I placed the function near a function in lv_manip.c that it was close to in metadata-exported.h. Different placement in the file or a different name for the function may be useful.
2012-10-24 05:33:54 +04:00
}
stripes: Introduce _round_to_stripe_boundary.
2015-09-24 19:50:53 +03:00
/* Round up extents to next stripe boundary for number of stripes */
static uint32_t _round_to_stripe_boundary(struct volume_group *vg, uint32_t extents,
uint32_t stripes, int extend)
{
uint32_t size_rest, new_extents = extents;
if (!stripes)
return extents;
/* Round up extents to stripe divisible amount */
if ((size_rest = extents % stripes)) {
new_extents += extend ? stripes - size_rest : -size_rest;
lv_manip: add space into message Just add space between %s(.
2020-10-19 11:28:06 +03:00
log_print_unless_silent("Rounding size %s (%u extents) %s to stripe boundary size %s (%u extents).",
cleanup: use 64bit multiply for print
2015-11-07 19:16:49 +03:00
display_size(vg->cmd, (uint64_t) extents * vg->extent_size), extents,
lvreduce/lvresize: add ability to reduce the size of a RaidLV - support shrinking of raid0/1/4/5/6/10 LVs - enhance lvresize-raid.sh tests: add raid0* and raid10 - fix have_raid4 in aux.sh to allow lv_resize-raid.sh and other scripts to test raid4 Resolves: rhbz1394048
2017-02-10 00:41:28 +03:00
new_extents < extents ? "down" : "up",
cleanup: use 64bit multiply for print
2015-11-07 19:16:49 +03:00
display_size(vg->cmd, (uint64_t) new_extents * vg->extent_size), new_extents);
stripes: Introduce _round_to_stripe_boundary.
2015-09-24 19:50:53 +03:00
}
return new_extents;
}
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
/*
* All lv_segments get created here.
*/
Always use vg memory pool for allocated lv segment Remove mem pool parameter from alloc_lv_segment() Since we should always allocate LV segment from the vg mempool.
2011-10-23 20:02:01 +04:00
struct lv_segment *alloc_lv_segment(const struct segment_type *segtype,
extend alloc_lv_segment
2005-04-22 19:44:00 +04:00
struct logical_volume *lv,
uint32_t le, uint32_t len,
lvconvert: add infrastructure for RaidLV reshaping support In order to support striped raid5/6/10 LV reshaping (change of LV type, stripesize or number of legs), this patch introduces infrastructure prerequisites to be used by raid_manip.c extensions in followup patches. This base is needed for allocation of out-of-place reshape space required by the MD raid personalities to avoid writing over data in-place when reading off the current RAID layout or number of legs and writing out the new layout or to a different number of legs (i.e. restripe) Changes: - add members reshape_len to 'struct lv_segment' to store out-of-place reshape length per component rimage - add member data_copies to struct lv_segment to support more than 2 raid10 data copies - make alloc_lv_segment() aware of both reshape_len and data_copies - adjust all alloc_lv_segment() callers to the new API - add functions to retrieve the current data offset (needed for out-of-place reshaping space allocation) and the devices count from the kernel - make libdm deptree code aware of reshape_len - add LV flags for disk add/remove reshaping - support import/export of the new 'struct lv_segment' members - enhance lv_extend/_lv_reduce to cope with reshape_len - add seg_is_*/segtype_is_* macros related to reshaping - add target version check for reshaping - grow rebuilds/writemostly bitmaps to 246 bit to support kernel maximal - enhance libdm deptree code to support data_offset (out-of-place reshaping) and delta_disk (legs add/remove reshaping) target arguments Related: rhbz834579 Related: rhbz1191935 Related: rhbz1191978
2017-02-24 02:50:00 +03:00
uint32_t reshape_len,
Switch status from 32-bit to 64-bit The physical_volume, volume_group, logical_volume and lv_segment structures' 'status' member is now uint64_t. The alignment of these structures was also audited to remove holes. The movement of some members in 'volume_group' and 'lv_segment' eliminates holes. The 'physical_volume' structure still has one 4-byte hole after 'pe_size'; the other structures no longer have any holes. Each structures' size has not changed.
2009-11-25 01:55:55 +03:00
uint64_t status,
extend alloc_lv_segment
2005-04-22 19:44:00 +04:00
uint32_t stripe_size,
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
struct logical_volume *log_lv,
extend alloc_lv_segment
2005-04-22 19:44:00 +04:00
uint32_t area_count,
uint32_t area_len,
lvconvert: add infrastructure for RaidLV reshaping support In order to support striped raid5/6/10 LV reshaping (change of LV type, stripesize or number of legs), this patch introduces infrastructure prerequisites to be used by raid_manip.c extensions in followup patches. This base is needed for allocation of out-of-place reshape space required by the MD raid personalities to avoid writing over data in-place when reading off the current RAID layout or number of legs and writing out the new layout or to a different number of legs (i.e. restripe) Changes: - add members reshape_len to 'struct lv_segment' to store out-of-place reshape length per component rimage - add member data_copies to struct lv_segment to support more than 2 raid10 data copies - make alloc_lv_segment() aware of both reshape_len and data_copies - adjust all alloc_lv_segment() callers to the new API - add functions to retrieve the current data offset (needed for out-of-place reshaping space allocation) and the devices count from the kernel - make libdm deptree code aware of reshape_len - add LV flags for disk add/remove reshaping - support import/export of the new 'struct lv_segment' members - enhance lv_extend/_lv_reduce to cope with reshape_len - add seg_is_*/segtype_is_* macros related to reshaping - add target version check for reshaping - grow rebuilds/writemostly bitmaps to 246 bit to support kernel maximal - enhance libdm deptree code to support data_offset (out-of-place reshaping) and delta_disk (legs add/remove reshaping) target arguments Related: rhbz834579 Related: rhbz1191935 Related: rhbz1191978
2017-02-24 02:50:00 +03:00
uint32_t data_copies,
extend alloc_lv_segment
2005-04-22 19:44:00 +04:00
uint32_t chunk_size,
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
uint32_t region_size,
Fix pvmove allocation to take existing parallel stripes into account. When moving parts of striped LVs, pvmove wouldn't care about leaving you with two stripes on the same disk. Now --alloc anywhere is needed for that. (Tried and gave up on two alternative approaches before the one committed here.)
2010-04-08 04:28:57 +04:00
uint32_t extents_copied,
struct lv_segment *pvmove_source_seg)
o Striped allocator o Changed pv_map.c to maintain the list of free areas in size order, which is more helpful to the allocators. If you want to allocate a bit of an area call consume_area(area, size), this will adjust the area if there's some space left and shuffle it to the correct place in the list. Not tested.
2001-11-29 21:45:35 +03:00
{
Some new features.
2002-11-18 17:04:08 +03:00
struct lv_segment *seg;
Always use vg memory pool for allocated lv segment Remove mem pool parameter from alloc_lv_segment() Since we should always allocate LV segment from the vg mempool.
2011-10-23 20:02:01 +04:00
struct dm_pool *mem = lv->vg->vgmem;
Split lv_segment_area from lv_segment to permit extension.
2005-10-18 17:43:40 +04:00
uint32_t areas_sz = area_count * sizeof(*seg->areas);
o Striped allocator o Changed pv_map.c to maintain the list of free areas in size order, which is more helpful to the allocators. If you want to allocate a bit of an area call consume_area(area, size), this will adjust the area if there's some space left and shuffle it to the correct place in the list. Not tested.
2001-11-29 21:45:35 +03:00
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
if (!segtype) {
log_error(INTERNAL_ERROR "alloc_lv_segment: Missing segtype.");
return NULL;
}
Use stack return macros throughout.
2008-01-30 16:19:47 +03:00
if (!(seg = dm_pool_zalloc(mem, sizeof(*seg))))
return_NULL;
Split lv_segment_area from lv_segment to permit extension.
2005-10-18 17:43:40 +04:00
if (!(seg->areas = dm_pool_zalloc(mem, areas_sz))) {
dm_pool_free(mem, seg);
Use stack return macros throughout.
2008-01-30 16:19:47 +03:00
return_NULL;
o Striped allocator o Changed pv_map.c to maintain the list of free areas in size order, which is more helpful to the allocators. If you want to allocate a bit of an area call consume_area(area, size), this will adjust the area if there's some space left and shuffle it to the correct place in the list. Not tested.
2001-11-29 21:45:35 +03:00
}
cleanup: use segtype_is_raid_with_meta Replace with common macro.
2017-11-01 01:16:13 +03:00
if (segtype_is_raid_with_meta(segtype) &&
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
!(seg->meta_areas = dm_pool_zalloc(mem, areas_sz))) {
dm_pool_free(mem, seg); /* frees everything alloced since seg */
return_NULL;
Always insert an intermediate layer for mirrors. Suppress hidden LVs from reports unless --all is given. Use square brackets for hidden LVs in reports. Centralise restrictions on LV names.
2005-06-03 18:49:51 +04:00
}
extend alloc_lv_segment
2005-04-22 19:44:00 +04:00
seg->segtype = segtype;
seg->lv = lv;
seg->le = le;
seg->len = len;
lvconvert: add infrastructure for RaidLV reshaping support In order to support striped raid5/6/10 LV reshaping (change of LV type, stripesize or number of legs), this patch introduces infrastructure prerequisites to be used by raid_manip.c extensions in followup patches. This base is needed for allocation of out-of-place reshape space required by the MD raid personalities to avoid writing over data in-place when reading off the current RAID layout or number of legs and writing out the new layout or to a different number of legs (i.e. restripe) Changes: - add members reshape_len to 'struct lv_segment' to store out-of-place reshape length per component rimage - add member data_copies to struct lv_segment to support more than 2 raid10 data copies - make alloc_lv_segment() aware of both reshape_len and data_copies - adjust all alloc_lv_segment() callers to the new API - add functions to retrieve the current data offset (needed for out-of-place reshaping space allocation) and the devices count from the kernel - make libdm deptree code aware of reshape_len - add LV flags for disk add/remove reshaping - support import/export of the new 'struct lv_segment' members - enhance lv_extend/_lv_reduce to cope with reshape_len - add seg_is_*/segtype_is_* macros related to reshaping - add target version check for reshaping - grow rebuilds/writemostly bitmaps to 246 bit to support kernel maximal - enhance libdm deptree code to support data_offset (out-of-place reshaping) and delta_disk (legs add/remove reshaping) target arguments Related: rhbz834579 Related: rhbz1191935 Related: rhbz1191978
2017-02-24 02:50:00 +03:00
seg->reshape_len = reshape_len;
extend alloc_lv_segment
2005-04-22 19:44:00 +04:00
seg->status = status;
seg->stripe_size = stripe_size;
seg->area_count = area_count;
seg->area_len = area_len;
lvconvert: add infrastructure for RaidLV reshaping support In order to support striped raid5/6/10 LV reshaping (change of LV type, stripesize or number of legs), this patch introduces more local infrastructure to raid_manip.c used by followup patches. Changes: - add lv_raid_data_copies returning raid type specific number; needed for raid10 with more than 2 data copies - remove _shift_and_rename_image_components() constraint to support more than 10 raid legs - add function to calculate total rimage length used by out-of-place reshape space allocation - add out-of-place reshape space alloc/relocate/free functions - move _data_rimages_count() used by reshape space alloc/realocate functions Related: rhbz834579 Related: rhbz1191935 Related: rhbz1191978
2017-02-24 03:57:04 +03:00
seg->data_copies = data_copies ? : lv_raid_data_copies(segtype, area_count);
extend alloc_lv_segment
2005-04-22 19:44:00 +04:00
seg->chunk_size = chunk_size;
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
seg->region_size = region_size;
extend alloc_lv_segment
2005-04-22 19:44:00 +04:00
seg->extents_copied = extents_copied;
Fix pvmove allocation to take existing parallel stripes into account. When moving parts of striped LVs, pvmove wouldn't care about leaving you with two stripes on the same disk. Now --alloc anywhere is needed for that. (Tried and gave up on two alternative approaches before the one committed here.)
2010-04-08 04:28:57 +04:00
seg->pvmove_source_seg = pvmove_source_seg;
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
dm_list_init(&seg->tags);
vg_validate: segment check enhancements for raids to catch bogus metadata General RAID and RAID segment type specific checks are added to merge.c. New static _check_raid_seg() is called on each segment of a RaidLV (which have just one) from check_lv_segments(). New checks caught some unititialized segment members which are addressed here as well: - initialize seg->region_size to 0 in lvcreate.c for raid0/raid0_meta - initialize list seg->origin_list in lv_manip.c
2016-07-27 19:17:29 +03:00
dm_list_init(&seg->origin_list);
Message support for thin provisiong lvm part of messaging. Each message is now stored it's own thin pool section: message1 { create = lv } Messages are queued to thin pool dm target when this target is going to be resumed or used through some dependency. Currently 'delete' message are purely queued and processed with next thin pool resume operation (i.e. create_thin). WARNING - thin provisioning support is developmental code.
2011-10-17 18:17:09 +04:00
dm_list_init(&seg->thin_messages);
tagging
2004-03-08 20:19:15 +03:00
lvcreate/remove thin_pool and thin volumes (--driverloaded n only)
2011-09-08 20:41:18 +04:00
if (log_lv && !attach_mirror_log(seg, log_lv))
return_NULL;
lvcreate parsing for thin provisioning. The rest is incomplete so this isn't usable yet.
2011-09-06 04:26:42 +04:00
mirrors: Fix checks for mirror/raid/pvmove LVs. Try to enforce consistent macro usage along these lines: lv_is_mirror - mirror that uses the original dm-raid1 implementation (segment type "mirror") lv_is_mirror_type - also includes internal mirror image and log LVs lv_is_raid - raid volume that uses the new dm-raid implementation (segment type "raid") lv_is_raid_type - also includes internal raid image / log / metadata LVs lv_is_mirrored - LV is mirrored using either kernel implementation (excludes non-mirror modes like raid5 etc.) lv_is_pvmove - internal pvmove volume
2014-09-16 03:13:46 +04:00
if (segtype_is_mirror(segtype))
lv->status |= MIRROR;
if (segtype_is_mirrored(segtype))
lv->status |= MIRRORED;
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
return seg;
}
lvreduce/lvresize: add ability to reduce the size of a RaidLV - support shrinking of raid0/1/4/5/6/10 LVs - enhance lvresize-raid.sh tests: add raid0* and raid10 - fix have_raid4 in aux.sh to allow lv_resize-raid.sh and other scripts to test raid4 Resolves: rhbz1394048
2017-02-10 00:41:28 +03:00
/*
* Temporary helper to return number of data copies for
* RAID segment @seg until seg->data_copies got added
*/
static uint32_t _raid_data_copies(struct lv_segment *seg)
{
/*
* FIXME: needs to change once more than 2 are supported.
* I.e. use seg->data_copies then
*/
if (seg_is_raid10(seg))
return 2;
tidy: prefer not using else after return clang-tidy: avoid using 'else' after return - give more readable code, and also saves indention level.
2017-07-19 17:16:12 +03:00
if (seg_is_raid1(seg))
lvreduce/lvresize: add ability to reduce the size of a RaidLV - support shrinking of raid0/1/4/5/6/10 LVs - enhance lvresize-raid.sh tests: add raid0* and raid10 - fix have_raid4 in aux.sh to allow lv_resize-raid.sh and other scripts to test raid4 Resolves: rhbz1394048
2017-02-10 00:41:28 +03:00
return seg->area_count;
return seg->segtype->parity_devs + 1;
}
/* Data image count for RAID segment @seg */
static uint32_t _raid_stripes_count(struct lv_segment *seg)
{
/*
* FIXME: raid10 needs to change once more than
* 2 data_copies and odd # of legs supported.
*/
if (seg_is_raid10(seg))
return seg->area_count / _raid_data_copies(seg);
return seg->area_count - seg->segtype->parity_devs;
}
discards: don't discard reconfigured extents Update release_lv_segment_area not to discard any PV extents, as it also gets used when moving extents between LVs. Instead, call a new function release_and_discard_lv_segment_area() in the two places where data should be discarded - lv_reduce() and remove_mirrors_from_segments().
2012-06-28 00:53:02 +04:00
static int _release_and_discard_lv_segment_area(struct lv_segment *seg, uint32_t s,
uint32_t area_reduction, int with_discard)
Various allocation-related pvmove fixes.
2005-06-14 21:54:48 +04:00
{
cache: Code to allow the create/remove of cache LVs This patch allows users to create cache LVs with 'lvcreate'. An origin or a cache pool LV must be created first. Then, while supplying the origin or cache pool to the lvcreate command, the cache can be created. Ex1: Here the cache pool is created first, followed by the origin which will be cached. ~> lvcreate --type cache_pool -L 500M -n cachepool vg /dev/small_n_fast ~> lvcreate --type cache -L 1G -n lv vg/cachepool /dev/large_n_slow Ex2: Here the origin is created first, followed by the cache pool - allowing a cache LV to be created covering the origin. ~> lvcreate -L 1G -n lv vg /dev/large_n_slow ~> lvcreate --type cache -L 500M -n cachepool vg/lv /dev/small_n_fast The code determines which type of LV was supplied (cache pool or origin) by checking its type. It ensures the right argument was given by ensuring that the origin is larger than the cache pool. If the user wants to remove just the cache for an LV. They specify the LV's associated cache pool when removing: ~> lvremove vg/cachepool If the user wishes to remove the origin, but leave the cachepool to be used for another LV, they specify the cache LV. ~> lvremove vg/lv In order to remove it all, specify both LVs. This patch also includes tests to create and remove cache pools and cache LVs.
2014-02-05 02:50:16 +04:00
struct lv_segment *cache_seg;
style: Miscellaneous tidying up of metadata/lv*
2015-09-23 16:37:52 +03:00
struct logical_volume *lv = seg_lv(seg, s);
cache: Code to allow the create/remove of cache LVs This patch allows users to create cache LVs with 'lvcreate'. An origin or a cache pool LV must be created first. Then, while supplying the origin or cache pool to the lvcreate command, the cache can be created. Ex1: Here the cache pool is created first, followed by the origin which will be cached. ~> lvcreate --type cache_pool -L 500M -n cachepool vg /dev/small_n_fast ~> lvcreate --type cache -L 1G -n lv vg/cachepool /dev/large_n_slow Ex2: Here the origin is created first, followed by the cache pool - allowing a cache LV to be created covering the origin. ~> lvcreate -L 1G -n lv vg /dev/large_n_slow ~> lvcreate --type cache -L 500M -n cachepool vg/lv /dev/small_n_fast The code determines which type of LV was supplied (cache pool or origin) by checking its type. It ensures the right argument was given by ensuring that the origin is larger than the cache pool. If the user wants to remove just the cache for an LV. They specify the LV's associated cache pool when removing: ~> lvremove vg/cachepool If the user wishes to remove the origin, but leave the cachepool to be used for another LV, they specify the cache LV. ~> lvremove vg/lv In order to remove it all, specify both LVs. This patch also includes tests to create and remove cache pools and cache LVs.
2014-02-05 02:50:16 +04:00
Various allocation-related pvmove fixes.
2005-06-14 21:54:48 +04:00
if (seg_type(seg, s) == AREA_UNASSIGNED)
allocation: allow release_lv_segment_area to fail Allow release_lv_segment_area to fail as functions it calls can fail.
2012-06-27 22:37:54 +04:00
return 1;
Various allocation-related pvmove fixes.
2005-06-14 21:54:48 +04:00
if (seg_type(seg, s) == AREA_PV) {
discards: don't discard reconfigured extents Update release_lv_segment_area not to discard any PV extents, as it also gets used when moving extents between LVs. Instead, call a new function release_and_discard_lv_segment_area() in the two places where data should be discarded - lv_reduce() and remove_mirrors_from_segments().
2012-06-28 00:53:02 +04:00
if (with_discard && !discard_pv_segment(seg_pvseg(seg, s), area_reduction))
return_0;
allocation: allow release_lv_segment_area to fail Allow release_lv_segment_area to fail as functions it calls can fail.
2012-06-27 22:37:54 +04:00
if (!release_pv_segment(seg_pvseg(seg, s), area_reduction))
return_0;
discards: don't discard reconfigured extents Update release_lv_segment_area not to discard any PV extents, as it also gets used when moving extents between LVs. Instead, call a new function release_and_discard_lv_segment_area() in the two places where data should be discarded - lv_reduce() and remove_mirrors_from_segments().
2012-06-28 00:53:02 +04:00
allocation: allow release_lv_segment_area to fail Allow release_lv_segment_area to fail as functions it calls can fail.
2012-06-27 22:37:54 +04:00
if (seg->area_len == area_reduction)
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
seg_type(seg, s) = AREA_UNASSIGNED;
discards: don't discard reconfigured extents Update release_lv_segment_area not to discard any PV extents, as it also gets used when moving extents between LVs. Instead, call a new function release_and_discard_lv_segment_area() in the two places where data should be discarded - lv_reduce() and remove_mirrors_from_segments().
2012-06-28 00:53:02 +04:00
allocation: allow release_lv_segment_area to fail Allow release_lv_segment_area to fail as functions it calls can fail.
2012-06-27 22:37:54 +04:00
return 1;
Various allocation-related pvmove fixes.
2005-06-14 21:54:48 +04:00
}
style: Miscellaneous tidying up of metadata/lv*
2015-09-23 16:37:52 +03:00
if (lv_is_mirror_image(lv) ||
lv_is_thin_pool_data(lv) ||
vdo: introduce segment types and manip functions Core functionality introducing lvm VDO support.
2018-06-29 12:11:14 +03:00
lv_is_vdo_pool_data(lv) ||
style: Miscellaneous tidying up of metadata/lv*
2015-09-23 16:37:52 +03:00
lv_is_cache_pool_data(lv)) {
if (!lv_reduce(lv, area_reduction))
allocation: allow release_lv_segment_area to fail Allow release_lv_segment_area to fail as functions it calls can fail.
2012-06-27 22:37:54 +04:00
return_0; /* FIXME: any upper level reporting */
return 1;
lvcreate/remove thin_pool and thin volumes (--driverloaded n only)
2011-09-08 20:41:18 +04:00
}
cache: Code to allow the create/remove of cache LVs This patch allows users to create cache LVs with 'lvcreate'. An origin or a cache pool LV must be created first. Then, while supplying the origin or cache pool to the lvcreate command, the cache can be created. Ex1: Here the cache pool is created first, followed by the origin which will be cached. ~> lvcreate --type cache_pool -L 500M -n cachepool vg /dev/small_n_fast ~> lvcreate --type cache -L 1G -n lv vg/cachepool /dev/large_n_slow Ex2: Here the origin is created first, followed by the cache pool - allowing a cache LV to be created covering the origin. ~> lvcreate -L 1G -n lv vg /dev/large_n_slow ~> lvcreate --type cache -L 500M -n cachepool vg/lv /dev/small_n_fast The code determines which type of LV was supplied (cache pool or origin) by checking its type. It ensures the right argument was given by ensuring that the origin is larger than the cache pool. If the user wants to remove just the cache for an LV. They specify the LV's associated cache pool when removing: ~> lvremove vg/cachepool If the user wishes to remove the origin, but leave the cachepool to be used for another LV, they specify the cache LV. ~> lvremove vg/lv In order to remove it all, specify both LVs. This patch also includes tests to create and remove cache pools and cache LVs.
2014-02-05 02:50:16 +04:00
if (seg_is_cache_pool(seg) &&
!dm_list_empty(&seg->lv->segs_using_this_lv)) {
if (!(cache_seg = get_only_segment_using_this_lv(seg->lv)))
return_0;
if (!lv_cache_remove(cache_seg->lv))
return_0;
}
style: Miscellaneous tidying up of metadata/lv*
2015-09-23 16:37:52 +03:00
if (lv_is_raid_image(lv)) {
cleanup: indent
2018-02-26 16:44:51 +03:00
/* Calculate the amount of extents to reduce per rmeta/rimage LV */
lvreduce/lvresize: add ability to reduce the size of a RaidLV - support shrinking of raid0/1/4/5/6/10 LVs - enhance lvresize-raid.sh tests: add raid0* and raid10 - fix have_raid4 in aux.sh to allow lv_resize-raid.sh and other scripts to test raid4 Resolves: rhbz1394048
2017-02-10 00:41:28 +03:00
uint32_t rimage_extents;
lvconvert: add infrastructure for RaidLV reshaping support In order to support striped raid5/6/10 LV reshaping (change of LV type, stripesize or number of legs), this patch introduces infrastructure prerequisites to be used by raid_manip.c extensions in followup patches. This base is needed for allocation of out-of-place reshape space required by the MD raid personalities to avoid writing over data in-place when reading off the current RAID layout or number of legs and writing out the new layout or to a different number of legs (i.e. restripe) Changes: - add members reshape_len to 'struct lv_segment' to store out-of-place reshape length per component rimage - add member data_copies to struct lv_segment to support more than 2 raid10 data copies - make alloc_lv_segment() aware of both reshape_len and data_copies - adjust all alloc_lv_segment() callers to the new API - add functions to retrieve the current data offset (needed for out-of-place reshaping space allocation) and the devices count from the kernel - make libdm deptree code aware of reshape_len - add LV flags for disk add/remove reshaping - support import/export of the new 'struct lv_segment' members - enhance lv_extend/_lv_reduce to cope with reshape_len - add seg_is_*/segtype_is_* macros related to reshaping - add target version check for reshaping - grow rebuilds/writemostly bitmaps to 246 bit to support kernel maximal - enhance libdm deptree code to support data_offset (out-of-place reshaping) and delta_disk (legs add/remove reshaping) target arguments Related: rhbz834579 Related: rhbz1191935 Related: rhbz1191978
2017-02-24 02:50:00 +03:00
struct lv_segment *seg1 = first_seg(lv);
lvreduce/lvresize: add ability to reduce the size of a RaidLV - support shrinking of raid0/1/4/5/6/10 LVs - enhance lvresize-raid.sh tests: add raid0* and raid10 - fix have_raid4 in aux.sh to allow lv_resize-raid.sh and other scripts to test raid4 Resolves: rhbz1394048
2017-02-10 00:41:28 +03:00
lvconvert: add infrastructure for RaidLV reshaping support In order to support striped raid5/6/10 LV reshaping (change of LV type, stripesize or number of legs), this patch introduces infrastructure prerequisites to be used by raid_manip.c extensions in followup patches. This base is needed for allocation of out-of-place reshape space required by the MD raid personalities to avoid writing over data in-place when reading off the current RAID layout or number of legs and writing out the new layout or to a different number of legs (i.e. restripe) Changes: - add members reshape_len to 'struct lv_segment' to store out-of-place reshape length per component rimage - add member data_copies to struct lv_segment to support more than 2 raid10 data copies - make alloc_lv_segment() aware of both reshape_len and data_copies - adjust all alloc_lv_segment() callers to the new API - add functions to retrieve the current data offset (needed for out-of-place reshaping space allocation) and the devices count from the kernel - make libdm deptree code aware of reshape_len - add LV flags for disk add/remove reshaping - support import/export of the new 'struct lv_segment' members - enhance lv_extend/_lv_reduce to cope with reshape_len - add seg_is_*/segtype_is_* macros related to reshaping - add target version check for reshaping - grow rebuilds/writemostly bitmaps to 246 bit to support kernel maximal - enhance libdm deptree code to support data_offset (out-of-place reshaping) and delta_disk (legs add/remove reshaping) target arguments Related: rhbz834579 Related: rhbz1191935 Related: rhbz1191978
2017-02-24 02:50:00 +03:00
/* FIXME: avoid extra seg_is_*() conditionals here */
cleanup: indent
2018-02-26 16:44:51 +03:00
rimage_extents = raid_rimage_extents(seg1->segtype, area_reduction,
seg_is_any_raid0(seg) ? 0 : _raid_stripes_count(seg),
lvreduce/lvresize: add ability to reduce the size of a RaidLV - support shrinking of raid0/1/4/5/6/10 LVs - enhance lvresize-raid.sh tests: add raid0* and raid10 - fix have_raid4 in aux.sh to allow lv_resize-raid.sh and other scripts to test raid4 Resolves: rhbz1394048
2017-02-10 00:41:28 +03:00
seg_is_raid10(seg) ? 1 :_raid_data_copies(seg));
if (!rimage_extents)
debug: more stacktrace corrections Continue previous patch dropping some unneeded stack traces after printed log_error/warn messages.
2016-11-25 15:46:06 +03:00
return 0;
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
lvreduce/lvresize: add ability to reduce the size of a RaidLV - support shrinking of raid0/1/4/5/6/10 LVs - enhance lvresize-raid.sh tests: add raid0* and raid10 - fix have_raid4 in aux.sh to allow lv_resize-raid.sh and other scripts to test raid4 Resolves: rhbz1394048
2017-02-10 00:41:28 +03:00
if (seg->meta_areas) {
uint32_t meta_area_reduction;
struct logical_volume *mlv;
struct volume_group *vg = lv->vg;
if (seg_metatype(seg, s) != AREA_LV ||
!(mlv = seg_metalv(seg, s)))
allocation: allow release_lv_segment_area to fail Allow release_lv_segment_area to fail as functions it calls can fail.
2012-06-27 22:37:54 +04:00
return 0;
lvreduce/lvresize: add ability to reduce the size of a RaidLV - support shrinking of raid0/1/4/5/6/10 LVs - enhance lvresize-raid.sh tests: add raid0* and raid10 - fix have_raid4 in aux.sh to allow lv_resize-raid.sh and other scripts to test raid4 Resolves: rhbz1394048
2017-02-10 00:41:28 +03:00
meta_area_reduction = raid_rmeta_extents_delta(vg->cmd, lv->le_count, lv->le_count - rimage_extents,
seg->region_size, vg->extent_size);
/* Limit for raid0_meta not having region size set */
if (meta_area_reduction > mlv->le_count ||
!(lv->le_count - rimage_extents))
meta_area_reduction = mlv->le_count;
if (meta_area_reduction &&
!lv_reduce(mlv, meta_area_reduction))
return_0; /* FIXME: any upper level reporting */
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
}
cleanup: indent
2016-11-25 16:21:34 +03:00
lvreduce/lvresize: add ability to reduce the size of a RaidLV - support shrinking of raid0/1/4/5/6/10 LVs - enhance lvresize-raid.sh tests: add raid0* and raid10 - fix have_raid4 in aux.sh to allow lv_resize-raid.sh and other scripts to test raid4 Resolves: rhbz1394048
2017-02-10 00:41:28 +03:00
if (!lv_reduce(lv, rimage_extents))
return_0; /* FIXME: any upper level reporting */
allocation: allow release_lv_segment_area to fail Allow release_lv_segment_area to fail as functions it calls can fail.
2012-06-27 22:37:54 +04:00
return 1;
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
}
Various allocation-related pvmove fixes.
2005-06-14 21:54:48 +04:00
if (area_reduction == seg->area_len) {
cleanup: add some dots and use display_lvname Just some more VG/LV printing.
2016-11-25 16:08:39 +03:00
log_very_verbose("Remove %s:" FMTu32 "[" FMTu32 "] from "
"the top of LV %s:" FMTu32 ".",
display_lvname(seg->lv), seg->le, s,
display_lvname(lv), seg_le(seg, s));
add lvconvert messages
2008-01-19 01:00:46 +03:00
style: Miscellaneous tidying up of metadata/lv*
2015-09-23 16:37:52 +03:00
if (!remove_seg_from_segs_using_this_lv(lv, seg))
lv_manip: check remove_seg_from_segs_using_this_lv() Add missing check for result of remove_seg_from_segs_using_this_lv(). Failure is reported as internal error.
2013-04-21 15:18:53 +04:00
return_0;
cleanup: add some dots and use display_lvname Just some more VG/LV printing.
2016-11-25 16:08:39 +03:00
Various allocation-related pvmove fixes.
2005-06-14 21:54:48 +04:00
seg_lv(seg, s) = NULL;
seg_le(seg, s) = 0;
seg_type(seg, s) = AREA_UNASSIGNED;
}
allocation: allow release_lv_segment_area to fail Allow release_lv_segment_area to fail as functions it calls can fail.
2012-06-27 22:37:54 +04:00
vdo: introduce segment types and manip functions Core functionality introducing lvm VDO support.
2018-06-29 12:11:14 +03:00
/* When removed last VDO user automatically removes VDO pool */
lvmlockd vdo: add support lvmlockd handling for vdo lv and vdo pool is like thin lv and thin pool.
2020-09-29 22:33:44 +03:00
if (lv_is_vdo_pool(lv) && dm_list_empty(&(lv->segs_using_this_lv))) {
struct volume_group *vg = lv->vg;
if (!lv_remove(lv)) /* FIXME: any upper level reporting */
return_0;
if (vg_is_shared(vg)) {
if (!lockd_lv_name(vg->cmd, vg, lv->name, &lv->lvid.id[1], lv->lock_args, "un", LDLV_PERSISTENT))
log_error("Failed to unlock vdo pool in lvmlockd.");
lockd_free_lv(vg->cmd, vg, lv->name, &lv->lvid.id[1], lv->lock_args);
}
return 1;
}
vdo: introduce segment types and manip functions Core functionality introducing lvm VDO support.
2018-06-29 12:11:14 +03:00
allocation: allow release_lv_segment_area to fail Allow release_lv_segment_area to fail as functions it calls can fail.
2012-06-27 22:37:54 +04:00
return 1;
Various allocation-related pvmove fixes.
2005-06-14 21:54:48 +04:00
}
discards: don't discard reconfigured extents Update release_lv_segment_area not to discard any PV extents, as it also gets used when moving extents between LVs. Instead, call a new function release_and_discard_lv_segment_area() in the two places where data should be discarded - lv_reduce() and remove_mirrors_from_segments().
2012-06-28 00:53:02 +04:00
int release_and_discard_lv_segment_area(struct lv_segment *seg, uint32_t s, uint32_t area_reduction)
{
return _release_and_discard_lv_segment_area(seg, s, area_reduction, 1);
}
int release_lv_segment_area(struct lv_segment *seg, uint32_t s, uint32_t area_reduction)
{
return _release_and_discard_lv_segment_area(seg, s, area_reduction, 0);
}
Various allocation-related pvmove fixes.
2005-06-14 21:54:48 +04:00
/*
* Move a segment area from one segment to another
*/
int move_lv_segment_area(struct lv_segment *seg_to, uint32_t area_to,
struct lv_segment *seg_from, uint32_t area_from)
{
struct physical_volume *pv;
struct logical_volume *lv;
uint32_t pe, le;
switch (seg_type(seg_from, area_from)) {
case AREA_PV:
pv = seg_pv(seg_from, area_from);
pe = seg_pe(seg_from, area_from);
allocation: allow release_lv_segment_area to fail Allow release_lv_segment_area to fail as functions it calls can fail.
2012-06-27 22:37:54 +04:00
if (!release_lv_segment_area(seg_from, area_from, seg_from->area_len))
return_0;
if (!release_lv_segment_area(seg_to, area_to, seg_to->area_len))
return_0;
Various allocation-related pvmove fixes.
2005-06-14 21:54:48 +04:00
Use stack return macros throughout.
2008-01-30 16:19:47 +03:00
if (!set_lv_segment_area_pv(seg_to, area_to, pv, pe))
return_0;
Various allocation-related pvmove fixes.
2005-06-14 21:54:48 +04:00
break;
case AREA_LV:
lv = seg_lv(seg_from, area_from);
le = seg_le(seg_from, area_from);
allocation: allow release_lv_segment_area to fail Allow release_lv_segment_area to fail as functions it calls can fail.
2012-06-27 22:37:54 +04:00
if (!release_lv_segment_area(seg_from, area_from, seg_from->area_len))
return_0;
if (!release_lv_segment_area(seg_to, area_to, seg_to->area_len))
return_0;
Various allocation-related pvmove fixes.
2005-06-14 21:54:48 +04:00
Maintain lists of stacked LV segments using each LV.
2008-01-16 22:00:59 +03:00
if (!set_lv_segment_area_lv(seg_to, area_to, lv, le, 0))
return_0;
Various allocation-related pvmove fixes.
2005-06-14 21:54:48 +04:00
break;
case AREA_UNASSIGNED:
allocation: allow release_lv_segment_area to fail Allow release_lv_segment_area to fail as functions it calls can fail.
2012-06-27 22:37:54 +04:00
if (!release_lv_segment_area(seg_to, area_to, seg_to->area_len))
return_0;
Various allocation-related pvmove fixes.
2005-06-14 21:54:48 +04:00
}
return 1;
}
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
/*
* Link part of a PV to an LV segment.
*/
Reinstate full PV size when removing from VG. Support loopfiles for testing. Complete the pv_segment support.
2005-05-03 21:28:23 +04:00
int set_lv_segment_area_pv(struct lv_segment *seg, uint32_t area_num,
struct physical_volume *pv, uint32_t pe)
set_lv_segment_area_pv/lv
2005-04-22 19:43:02 +04:00
{
Split lv_segment_area from lv_segment to permit extension.
2005-10-18 17:43:40 +04:00
seg->areas[area_num].type = AREA_PV;
Reinstate full PV size when removing from VG. Support loopfiles for testing. Complete the pv_segment support.
2005-05-03 21:28:23 +04:00
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
if (!(seg_pvseg(seg, area_num) =
Use stack return macros throughout.
2008-01-30 16:19:47 +03:00
assign_peg_to_lvseg(pv, pe, seg->area_len, seg, area_num)))
return_0;
Reinstate full PV size when removing from VG. Support loopfiles for testing. Complete the pv_segment support.
2005-05-03 21:28:23 +04:00
return 1;
set_lv_segment_area_pv/lv
2005-04-22 19:43:02 +04:00
}
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
/*
* Link one LV segment to another. Assumes sizes already match.
*/
Maintain lists of stacked LV segments using each LV.
2008-01-16 22:00:59 +03:00
int set_lv_segment_area_lv(struct lv_segment *seg, uint32_t area_num,
struct logical_volume *lv, uint32_t le,
Update a few more uint64_t's related to the 64-bit status change. At this point they probably do not matter but going forward they may - depends on future patches for replicator, etc. I think these probably got missed because they were 'flags' so I changed the name to 'status' to be consistent. So the on-disk things 'flags' and the in structure 'status' (bits). NOTE: WHATS_NEW already has entry for this in current release. Signed-off-by: Dave Wysochanski <dwysocha@redhat.com> Acked-by: Mike Snitzer <snitzer@redhat.com>
2009-12-04 20:48:32 +03:00
uint64_t status)
set_lv_segment_area_pv/lv
2005-04-22 19:43:02 +04:00
{
cleanup: use display_lvname and msg cleanup Use display_lvname in tracing messages. Add some missing 'dots' to messages.
2016-11-16 17:11:07 +03:00
log_very_verbose("Stack %s:" FMTu32 "[" FMTu32 "] on LV %s:" FMTu32 ".",
display_lvname(seg->lv), seg->le, area_num,
display_lvname(lv), le);
add lvconvert messages
2008-01-19 01:00:46 +03:00
lv_manip: add extra internal error Catch error early, when trying to store data into non-allocated area.
2018-06-20 11:44:13 +03:00
if (area_num >= seg->area_count) {
log_error(INTERNAL_ERROR "Try to set to high area number (%u >= %u) for LV %s.",
area_num, seg->area_count, display_lvname(seg->lv));
return 0;
}
cleanup: more lv_is_ usage
2016-12-13 02:09:15 +03:00
lv->status |= status;
if (lv_is_raid_metadata(lv)) {
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
seg->meta_areas[area_num].type = AREA_LV;
seg_metalv(seg, area_num) = lv;
if (le) {
cleanup: use display_lvname and msg cleanup Use display_lvname in tracing messages. Add some missing 'dots' to messages.
2016-11-16 17:11:07 +03:00
log_error(INTERNAL_ERROR "Meta le != 0.");
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
return 0;
}
seg_metale(seg, area_num) = 0;
} else {
seg->areas[area_num].type = AREA_LV;
seg_lv(seg, area_num) = lv;
seg_le(seg, area_num) = le;
}
Maintain lists of stacked LV segments using each LV.
2008-01-16 22:00:59 +03:00
if (!add_seg_to_segs_using_this_lv(lv, seg))
return_0;
return 1;
set_lv_segment_area_pv/lv
2005-04-22 19:43:02 +04:00
}
Split lv_segment_area from lv_segment to permit extension.
2005-10-18 17:43:40 +04:00
/*
* Prepare for adding parallel areas to an existing segment.
*/
lv_manip: add new internal api function
2018-06-23 12:35:22 +03:00
int add_lv_segment_areas(struct lv_segment *seg, uint32_t new_area_count)
Split lv_segment_area from lv_segment to permit extension.
2005-10-18 17:43:40 +04:00
{
struct lv_segment_area *newareas;
uint32_t areas_sz = new_area_count * sizeof(*newareas);
lv_manip: add new internal api function
2018-06-23 12:35:22 +03:00
if (!(newareas = dm_pool_zalloc(seg->lv->vg->vgmem, areas_sz))) {
log_error("Failed to allocate widened LV segment for %s.",
display_lvname(seg->lv));
cleanup: no backtraces needed after log_error Reduce double backtracing.
2021-03-09 13:42:29 +03:00
return 0;
lv_manip: add new internal api function
2018-06-23 12:35:22 +03:00
}
Split lv_segment_area from lv_segment to permit extension.
2005-10-18 17:43:40 +04:00
lv_manip: add new internal api function
2018-06-23 12:35:22 +03:00
if (seg->area_count)
memcpy(newareas, seg->areas, seg->area_count * sizeof(*seg->areas));
Split lv_segment_area from lv_segment to permit extension.
2005-10-18 17:43:40 +04:00
seg->areas = newareas;
seg->area_count = new_area_count;
return 1;
}
alloc: Move _calc_area_multiple.
2015-09-24 19:56:19 +03:00
static uint32_t _calc_area_multiple(const struct segment_type *segtype,
const uint32_t area_count,
const uint32_t stripes)
{
if (!area_count)
return 1;
/* Striped */
if (segtype_is_striped(segtype))
return area_count;
/* Parity RAID (e.g. RAID 4/5/6) */
if (segtype_is_raid(segtype) && segtype->parity_devs) {
/*
* As articulated in _alloc_init, we can tell by
* the area_count whether a replacement drive is
* being allocated; and if this is the case, then
* there is no area_multiple that should be used.
*/
if (area_count <= segtype->parity_devs)
return 1;
return area_count - segtype->parity_devs;
}
/*
* RAID10 - only has 2-way mirror right now.
* If we are to move beyond 2-way RAID10, then
* the 'stripes' argument will always need to
* be given.
*/
lvconvert: add infrastructure for RaidLV reshaping support In order to support striped raid5/6/10 LV reshaping (change of LV type, stripesize or number of legs), this patch introduces infrastructure prerequisites to be used by raid_manip.c extensions in followup patches. This base is needed for allocation of out-of-place reshape space required by the MD raid personalities to avoid writing over data in-place when reading off the current RAID layout or number of legs and writing out the new layout or to a different number of legs (i.e. restripe) Changes: - add members reshape_len to 'struct lv_segment' to store out-of-place reshape length per component rimage - add member data_copies to struct lv_segment to support more than 2 raid10 data copies - make alloc_lv_segment() aware of both reshape_len and data_copies - adjust all alloc_lv_segment() callers to the new API - add functions to retrieve the current data offset (needed for out-of-place reshaping space allocation) and the devices count from the kernel - make libdm deptree code aware of reshape_len - add LV flags for disk add/remove reshaping - support import/export of the new 'struct lv_segment' members - enhance lv_extend/_lv_reduce to cope with reshape_len - add seg_is_*/segtype_is_* macros related to reshaping - add target version check for reshaping - grow rebuilds/writemostly bitmaps to 246 bit to support kernel maximal - enhance libdm deptree code to support data_offset (out-of-place reshaping) and delta_disk (legs add/remove reshaping) target arguments Related: rhbz834579 Related: rhbz1191935 Related: rhbz1191978
2017-02-24 02:50:00 +03:00
if (segtype_is_raid10(segtype)) {
alloc: Move _calc_area_multiple.
2015-09-24 19:56:19 +03:00
if (!stripes)
return area_count / 2;
return stripes;
}
/* Mirrored stripes */
if (stripes)
return stripes;
/* Mirrored */
return 1;
}
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
/*
* Reduce the size of an lv_segment. New size can be zero.
*/
static int _lv_segment_reduce(struct lv_segment *seg, uint32_t reduction)
Reinstate full PV size when removing from VG. Support loopfiles for testing. Complete the pv_segment support.
2005-05-03 21:28:23 +04:00
{
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
uint32_t area_reduction, s;
lvconvert: add infrastructure for RaidLV reshaping support In order to support striped raid5/6/10 LV reshaping (change of LV type, stripesize or number of legs), this patch introduces infrastructure prerequisites to be used by raid_manip.c extensions in followup patches. This base is needed for allocation of out-of-place reshape space required by the MD raid personalities to avoid writing over data in-place when reading off the current RAID layout or number of legs and writing out the new layout or to a different number of legs (i.e. restripe) Changes: - add members reshape_len to 'struct lv_segment' to store out-of-place reshape length per component rimage - add member data_copies to struct lv_segment to support more than 2 raid10 data copies - make alloc_lv_segment() aware of both reshape_len and data_copies - adjust all alloc_lv_segment() callers to the new API - add functions to retrieve the current data offset (needed for out-of-place reshaping space allocation) and the devices count from the kernel - make libdm deptree code aware of reshape_len - add LV flags for disk add/remove reshaping - support import/export of the new 'struct lv_segment' members - enhance lv_extend/_lv_reduce to cope with reshape_len - add seg_is_*/segtype_is_* macros related to reshaping - add target version check for reshaping - grow rebuilds/writemostly bitmaps to 246 bit to support kernel maximal - enhance libdm deptree code to support data_offset (out-of-place reshaping) and delta_disk (legs add/remove reshaping) target arguments Related: rhbz834579 Related: rhbz1191935 Related: rhbz1191978
2017-02-24 02:50:00 +03:00
uint32_t areas = (seg->area_count / (seg_is_raid10(seg) ? seg->data_copies : 1)) - seg->segtype->parity_devs;
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
/* Caller must ensure exact divisibility */
lvconvert: add infrastructure for RaidLV reshaping support In order to support striped raid5/6/10 LV reshaping (change of LV type, stripesize or number of legs), this patch introduces infrastructure prerequisites to be used by raid_manip.c extensions in followup patches. This base is needed for allocation of out-of-place reshape space required by the MD raid personalities to avoid writing over data in-place when reading off the current RAID layout or number of legs and writing out the new layout or to a different number of legs (i.e. restripe) Changes: - add members reshape_len to 'struct lv_segment' to store out-of-place reshape length per component rimage - add member data_copies to struct lv_segment to support more than 2 raid10 data copies - make alloc_lv_segment() aware of both reshape_len and data_copies - adjust all alloc_lv_segment() callers to the new API - add functions to retrieve the current data offset (needed for out-of-place reshaping space allocation) and the devices count from the kernel - make libdm deptree code aware of reshape_len - add LV flags for disk add/remove reshaping - support import/export of the new 'struct lv_segment' members - enhance lv_extend/_lv_reduce to cope with reshape_len - add seg_is_*/segtype_is_* macros related to reshaping - add target version check for reshaping - grow rebuilds/writemostly bitmaps to 246 bit to support kernel maximal - enhance libdm deptree code to support data_offset (out-of-place reshaping) and delta_disk (legs add/remove reshaping) target arguments Related: rhbz834579 Related: rhbz1191935 Related: rhbz1191978
2017-02-24 02:50:00 +03:00
if (seg_is_striped(seg) || seg_is_striped_raid(seg)) {
if (reduction % areas) {
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
log_error("Segment extent reduction %" PRIu32
missing space in mesg
2011-06-06 16:08:42 +04:00
" not divisible by #stripes %" PRIu32,
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
reduction, seg->area_count);
return 0;
}
lvconvert: add infrastructure for RaidLV reshaping support In order to support striped raid5/6/10 LV reshaping (change of LV type, stripesize or number of legs), this patch introduces infrastructure prerequisites to be used by raid_manip.c extensions in followup patches. This base is needed for allocation of out-of-place reshape space required by the MD raid personalities to avoid writing over data in-place when reading off the current RAID layout or number of legs and writing out the new layout or to a different number of legs (i.e. restripe) Changes: - add members reshape_len to 'struct lv_segment' to store out-of-place reshape length per component rimage - add member data_copies to struct lv_segment to support more than 2 raid10 data copies - make alloc_lv_segment() aware of both reshape_len and data_copies - adjust all alloc_lv_segment() callers to the new API - add functions to retrieve the current data offset (needed for out-of-place reshaping space allocation) and the devices count from the kernel - make libdm deptree code aware of reshape_len - add LV flags for disk add/remove reshaping - support import/export of the new 'struct lv_segment' members - enhance lv_extend/_lv_reduce to cope with reshape_len - add seg_is_*/segtype_is_* macros related to reshaping - add target version check for reshaping - grow rebuilds/writemostly bitmaps to 246 bit to support kernel maximal - enhance libdm deptree code to support data_offset (out-of-place reshaping) and delta_disk (legs add/remove reshaping) target arguments Related: rhbz834579 Related: rhbz1191935 Related: rhbz1191978
2017-02-24 02:50:00 +03:00
area_reduction = reduction / areas;
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
} else
area_reduction = reduction;
Various allocation-related pvmove fixes.
2005-06-14 21:54:48 +04:00
for (s = 0; s < seg->area_count; s++)
discards: don't discard reconfigured extents Update release_lv_segment_area not to discard any PV extents, as it also gets used when moving extents between LVs. Instead, call a new function release_and_discard_lv_segment_area() in the two places where data should be discarded - lv_reduce() and remove_mirrors_from_segments().
2012-06-28 00:53:02 +04:00
if (!release_and_discard_lv_segment_area(seg, s, area_reduction))
allocation: allow release_lv_segment_area to fail Allow release_lv_segment_area to fail as functions it calls can fail.
2012-06-27 22:37:54 +04:00
return_0;
Various allocation-related pvmove fixes.
2005-06-14 21:54:48 +04:00
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
seg->len -= reduction;
lvconvert: add infrastructure for RaidLV reshaping support In order to support striped raid5/6/10 LV reshaping (change of LV type, stripesize or number of legs), this patch introduces infrastructure prerequisites to be used by raid_manip.c extensions in followup patches. This base is needed for allocation of out-of-place reshape space required by the MD raid personalities to avoid writing over data in-place when reading off the current RAID layout or number of legs and writing out the new layout or to a different number of legs (i.e. restripe) Changes: - add members reshape_len to 'struct lv_segment' to store out-of-place reshape length per component rimage - add member data_copies to struct lv_segment to support more than 2 raid10 data copies - make alloc_lv_segment() aware of both reshape_len and data_copies - adjust all alloc_lv_segment() callers to the new API - add functions to retrieve the current data offset (needed for out-of-place reshaping space allocation) and the devices count from the kernel - make libdm deptree code aware of reshape_len - add LV flags for disk add/remove reshaping - support import/export of the new 'struct lv_segment' members - enhance lv_extend/_lv_reduce to cope with reshape_len - add seg_is_*/segtype_is_* macros related to reshaping - add target version check for reshaping - grow rebuilds/writemostly bitmaps to 246 bit to support kernel maximal - enhance libdm deptree code to support data_offset (out-of-place reshaping) and delta_disk (legs add/remove reshaping) target arguments Related: rhbz834579 Related: rhbz1191935 Related: rhbz1191978
2017-02-24 02:50:00 +03:00
if (seg_is_raid(seg))
seg->area_len = seg->len;
else
seg->area_len -= area_reduction;
Reinstate full PV size when removing from VG. Support loopfiles for testing. Complete the pv_segment support.
2005-05-03 21:28:23 +04:00
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
return 1;
Reinstate full PV size when removing from VG. Support loopfiles for testing. Complete the pv_segment support.
2005-05-03 21:28:23 +04:00
}
lv_resize: support resizing of cached volumes Automatically figure out resizable layer in the LV stack and resize it online. Split check for reshaped raids and postpone removal of unused space after finished reshaping after metadata archiving. Drop warning about unsupported automatic resize of monitored thin-pool. Currently there is not yet support for resize of writecache.
2021-02-07 22:12:00 +03:00
/* Find the bottommost resizable LV in the stack.
* It does not matter which LV is used in this stack for cmdline tool. */
static struct logical_volume *_get_resizable_layer_lv(struct logical_volume *lv)
{
while (lv_is_cache(lv) || /* _corig */
lv_is_integrity(lv) ||
lv_is_thin_pool(lv) || /* _tdata */
lvextend: enable resize of writecached LV
2021-02-21 00:22:51 +03:00
lv_is_vdo_pool(lv) || /* _vdata */
lv_is_writecache(lv)) /* _worigin */
lv_resize: support resizing of cached volumes Automatically figure out resizable layer in the LV stack and resize it online. Split check for reshaped raids and postpone removal of unused space after finished reshaping after metadata archiving. Drop warning about unsupported automatic resize of monitored thin-pool. Currently there is not yet support for resize of writecache.
2021-02-07 22:12:00 +03:00
lv = seg_lv(first_seg(lv), 0); /* component-level down */
return lv;
}
/* Check if LV is component of resizable LV.
* When resize changes size of LV this also changes the size whole stack upward.
* Support syntax suggar - so user can pick any LV in stack for resize. */
static int _is_layered_lv(struct logical_volume *lv)
{
return (lv_is_cache_origin(lv) ||
lv_is_integrity_origin(lv) ||
lv_is_thin_pool_data(lv) ||
lvextend: enable resize of writecached LV
2021-02-21 00:22:51 +03:00
lv_is_vdo_pool_data(lv) ||
lv_is_writecache_origin(lv));
lv_resize: support resizing of cached volumes Automatically figure out resizable layer in the LV stack and resize it online. Split check for reshaped raids and postpone removal of unused space after finished reshaping after metadata archiving. Drop warning about unsupported automatic resize of monitored thin-pool. Currently there is not yet support for resize of writecache.
2021-02-07 22:12:00 +03:00
}
/* Find the topmost LV in the stack - usually such LV is visible. */
static struct logical_volume *_get_top_layer_lv(struct logical_volume *lv)
{
struct lv_segment *seg;
while (_is_layered_lv(lv)) {
if (!(seg = get_only_segment_using_this_lv(lv))) {
log_error(INTERNAL_ERROR "No single component user of logical volume %s.",
display_lvname(lv));
return NULL;
}
lv = seg->lv; /* component-level up */
}
return lv;
}
lv_manip: reuse function also during reduction Move function _setup_lv_size() in front of _lv_reduce() so it can be reused also in this function. Avoid propagating 0 length to upper layer.
2021-02-05 13:37:52 +03:00
/* Handles also stacking */
static int _setup_lv_size(struct logical_volume *lv, uint32_t extents)
{
struct lv_segment *seg;
lv->le_count = extents;
lv->size = (uint64_t) extents * lv->vg->extent_size;
lv_resize: support resizing of cached volumes Automatically figure out resizable layer in the LV stack and resize it online. Split check for reshaped raids and postpone removal of unused space after finished reshaping after metadata archiving. Drop warning about unsupported automatic resize of monitored thin-pool. Currently there is not yet support for resize of writecache.
2021-02-07 22:12:00 +03:00
while (lv->size && _is_layered_lv(lv)) {
lv_manip: reuse function also during reduction Move function _setup_lv_size() in front of _lv_reduce() so it can be reused also in this function. Avoid propagating 0 length to upper layer.
2021-02-05 13:37:52 +03:00
if (!(seg = get_only_segment_using_this_lv(lv)))
return_0;
seg->lv->le_count =
seg->len =
seg->area_len = lv->le_count;
seg->lv->size = lv->size;
lv_resize: support resizing of cached volumes Automatically figure out resizable layer in the LV stack and resize it online. Split check for reshaped raids and postpone removal of unused space after finished reshaping after metadata archiving. Drop warning about unsupported automatic resize of monitored thin-pool. Currently there is not yet support for resize of writecache.
2021-02-07 22:12:00 +03:00
lv = seg->lv;
lv_manip: reuse function also during reduction Move function _setup_lv_size() in front of _lv_reduce() so it can be reused also in this function. Avoid propagating 0 length to upper layer.
2021-02-05 13:37:52 +03:00
}
return 1;
}
Start merging cloned allocation functions.
2005-05-17 17:49:45 +04:00
/*
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
* Entry point for all LV reductions in size.
Start merging cloned allocation functions.
2005-05-17 17:49:45 +04:00
*/
Various allocation-related pvmove fixes.
2005-06-14 21:54:48 +04:00
static int _lv_reduce(struct logical_volume *lv, uint32_t extents, int delete)
o Striped allocator o Changed pv_map.c to maintain the list of free areas in size order, which is more helpful to the allocators. If you want to allocate a bit of an area call consume_area(area, size), this will adjust the area if there's some space left and shuffle it to the correct place in the list. Not tested.
2001-11-29 21:45:35 +03:00
{
lvreduce: check LV has segment Before accessing content make sure LV has segment. This can be used in case code removes LV without segments (i.e. on some error path)
2017-10-30 16:35:31 +03:00
struct lv_segment *seg = NULL;
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
uint32_t count = extents;
uint32_t reduction;
cache: lvremoved cached LV removes cache pool When we remove cached volume, whole tree must go down. There is 'lvconvert --splitcache' to preserve cache pool.
2014-10-04 01:36:11 +04:00
struct logical_volume *pool_lv;
thin: reload external origin with last thin External origin could be activated as stand-alone device. When the last thin LV is removed, external origin is no longer the external origin and it's layer property was dropped. Ensure dm table is correct by reloading external origin (when it's active).
2016-12-17 23:55:02 +03:00
struct logical_volume *external_lv = NULL;
lvreduce: check LV has segment Before accessing content make sure LV has segment. This can be used in case code removes LV without segments (i.e. on some error path)
2017-10-30 16:35:31 +03:00
int is_raid10 = 0;
uint32_t data_copies = 0;
pools: fix removal of spare volume When removing pool LV from a stacked LV setup, it's been possible to leak _pmspare and such hidden LV then required manual user removal. Fix it by moving automatic removal into _lv_reduce().
2021-01-22 16:31:12 +03:00
struct lv_list *lvl;
int is_last_pool = lv_is_pool(lv);
lvreduce: check LV has segment Before accessing content make sure LV has segment. This can be used in case code removes LV without segments (i.e. on some error path)
2017-10-30 16:35:31 +03:00
if (!dm_list_empty(&lv->segments)) {
seg = first_seg(lv);
is_raid10 = seg_is_any_raid10(seg) && seg->reshape_len;
data_copies = seg->data_copies;
}
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
thin: merge removal When thin is merged - properly handly device removal.
2013-11-30 00:21:00 +04:00
if (lv_is_merging_origin(lv)) {
log_debug_metadata("Dropping snapshot merge of %s to removed origin %s.",
find_snapshot(lv)->lv->name, lv->name);
clear_snapshot_merge(lv);
}
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
dm_list_iterate_back_items(seg, &lv->segments) {
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
if (!count)
break;
thin: reload external origin with last thin External origin could be activated as stand-alone device. When the last thin LV is removed, external origin is no longer the external origin and it's layer property was dropped. Ensure dm table is correct by reloading external origin (when it's active).
2016-12-17 23:55:02 +03:00
if (seg->external_lv)
external_lv = seg->external_lv;
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
if (seg->len <= count) {
thin: merge removal When thin is merged - properly handly device removal.
2013-11-30 00:21:00 +04:00
if (seg->merge_lv) {
log_debug_metadata("Dropping snapshot merge of removed %s to origin %s.",
seg->lv->name, seg->merge_lv->name);
clear_snapshot_merge(seg->merge_lv);
}
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
/* remove this segment completely */
/* FIXME Check this is safe */
Use stack return macros throughout.
2008-01-30 16:19:47 +03:00
if (seg->log_lv && !lv_remove(seg->log_lv))
return_0;
Just indent changes Some tabs & spaces.
2011-10-19 20:36:39 +04:00
Thin rename seg var pool_metadata_lv to metadata_lv Better fits the code.
2012-01-19 19:23:50 +04:00
if (seg->metadata_lv && !lv_remove(seg->metadata_lv))
lvcreate/remove thin_pool and thin volumes (--driverloaded n only)
2011-09-08 20:41:18 +04:00
return_0;
cache: cache segment is non-discardable Since cache segment is purely virtual mapping, it has nothing for discard. Discardable is cache origin here which is now properly removed on 'delete' phase. Plain lv_empty() call needs to only detach cache origin and leave origin unchanged.
2014-04-01 19:57:14 +04:00
/* Remove cache origin only when removing (not on lv_empty()) */
cache: pending_delete fixes
2014-11-11 15:31:25 +03:00
if (delete && seg_is_cache(seg)) {
if (lv_is_pending_delete(seg->lv)) {
/* Just dropping reference on origin when pending delete */
if (!remove_seg_from_segs_using_this_lv(seg_lv(seg, 0), seg))
return_0;
seg_lv(seg, 0) = NULL;
seg_le(seg, 0) = 0;
seg_type(seg, 0) = AREA_UNASSIGNED;
if (seg->pool_lv && !detach_pool_lv(seg))
return_0;
} else if (!lv_remove(seg_lv(seg, 0)))
return_0;
}
cache: cache segment is non-discardable Since cache segment is purely virtual mapping, it has nothing for discard. Discardable is cache origin here which is now properly removed on 'delete' phase. Plain lv_empty() call needs to only detach cache origin and leave origin unchanged.
2014-04-01 19:57:14 +04:00
Allow dm-integrity to be used for raid images dm-integrity stores checksums of the data written to an LV, and returns an error if data read from the LV does not match the previously saved checksum. When used on raid images, dm-raid will correct the error by reading the block from another image, and the device user sees no error. The integrity metadata (checksums) are stored on an internal LV allocated by lvm for each linear image. The internal LV is allocated on the same PV as the image. Create a raid LV with an integrity layer over each raid image (for raid levels 1,4,5,6,10): lvcreate --type raidN --raidintegrity y [options] Add an integrity layer to images of an existing raid LV: lvconvert --raidintegrity y LV Remove the integrity layer from images of a raid LV: lvconvert --raidintegrity n LV Settings Use --raidintegritymode journal|bitmap (journal is default) to configure the method used by dm-integrity to ensure crash consistency. Initialization When integrity is added to an LV, the kernel needs to initialize the integrity metadata/checksums for all blocks in the LV. The data corruption checking performed by dm-integrity will only operate on areas of the LV that are already initialized. The progress of integrity initialization is reported by the "syncpercent" LV reporting field (and under the Cpy%Sync lvs column.) Example: create a raid1 LV with integrity: $ lvcreate --type raid1 -m1 --raidintegrity y -n rr -L1G foo Creating integrity metadata LV rr_rimage_0_imeta with size 12.00 MiB. Logical volume "rr_rimage_0_imeta" created. Creating integrity metadata LV rr_rimage_1_imeta with size 12.00 MiB. Logical volume "rr_rimage_1_imeta" created. Logical volume "rr" created. $ lvs -a foo LV VG Attr LSize Origin Cpy%Sync rr foo rwi-a-r--- 1.00g 4.93 [rr_rimage_0] foo gwi-aor--- 1.00g [rr_rimage_0_iorig] 41.02 [rr_rimage_0_imeta] foo ewi-ao---- 12.00m [rr_rimage_0_iorig] foo -wi-ao---- 1.00g [rr_rimage_1] foo gwi-aor--- 1.00g [rr_rimage_1_iorig] 39.45 [rr_rimage_1_imeta] foo ewi-ao---- 12.00m [rr_rimage_1_iorig] foo -wi-ao---- 1.00g [rr_rmeta_0] foo ewi-aor--- 4.00m [rr_rmeta_1] foo ewi-aor--- 4.00m
2019-11-21 01:07:27 +03:00
if (delete && seg_is_integrity(seg)) {
/* Remove integrity origin in addition to integrity layer. */
if (!lv_remove(seg_lv(seg, 0)))
return_0;
/* Remove integrity metadata. */
if (seg->integrity_meta_dev && !lv_remove(seg->integrity_meta_dev))
return_0;
}
cache: lvremoved cached LV removes cache pool When we remove cached volume, whole tree must go down. There is 'lvconvert --splitcache' to preserve cache pool.
2014-10-04 01:36:11 +04:00
if ((pool_lv = seg->pool_lv)) {
if (!detach_pool_lv(seg))
return_0;
/* When removing cached LV, remove pool as well */
if (seg_is_cache(seg) && !lv_remove(pool_lv))
return_0;
}
lvcreate/remove thin_pool and thin volumes (--driverloaded n only)
2011-09-08 20:41:18 +04:00
lvremove: extra code for handling thinpool data Add some extra code to handle differently sized thin-pool from thin-pool data volume. ATM this can't really happen, but once we start to use multiple commits while resizing stacked LV, we may actually get into the position, where data LV has been already resized, but thin-pool stayed with old size. But for now - report difference as internal error.
2021-03-18 15:15:44 +03:00
if (seg_is_thin_pool(seg)) {
/* For some segtypes the size may differ between the segment size and its layered LV
* i.e. thin-pool and tdata.
*
* This can get useful, when we will support multiple commits
* while resizing a stacked LV.
*/
if (seg->len != seg_lv(seg, 0)->le_count) {
seg->len = seg_lv(seg, 0)->le_count;
/* FIXME: ATM capture as error as it should not happen. */
log_debug(INTERNAL_ERROR "Pool size mismatched data size for %s",
display_lvname(seg->lv));
}
}
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
dm_list_del(&seg->list);
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
reduction = seg->len;
} else
reduction = count;
Use stack return macros throughout.
2008-01-30 16:19:47 +03:00
if (!_lv_segment_reduce(seg, reduction))
return_0;
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
count -= reduction;
}
lv_manip: reuse function also during reduction Move function _setup_lv_size() in front of _lv_reduce() so it can be reused also in this function. Avoid propagating 0 length to upper layer.
2021-02-05 13:37:52 +03:00
if (!_setup_lv_size(lv, lv->le_count - extents * (is_raid10 ? data_copies : 1)))
return_0;
lvconvert: add infrastructure for RaidLV reshaping support In order to support striped raid5/6/10 LV reshaping (change of LV type, stripesize or number of legs), this patch introduces infrastructure prerequisites to be used by raid_manip.c extensions in followup patches. This base is needed for allocation of out-of-place reshape space required by the MD raid personalities to avoid writing over data in-place when reading off the current RAID layout or number of legs and writing out the new layout or to a different number of legs (i.e. restripe) Changes: - add members reshape_len to 'struct lv_segment' to store out-of-place reshape length per component rimage - add member data_copies to struct lv_segment to support more than 2 raid10 data copies - make alloc_lv_segment() aware of both reshape_len and data_copies - adjust all alloc_lv_segment() callers to the new API - add functions to retrieve the current data offset (needed for out-of-place reshaping space allocation) and the devices count from the kernel - make libdm deptree code aware of reshape_len - add LV flags for disk add/remove reshaping - support import/export of the new 'struct lv_segment' members - enhance lv_extend/_lv_reduce to cope with reshape_len - add seg_is_*/segtype_is_* macros related to reshaping - add target version check for reshaping - grow rebuilds/writemostly bitmaps to 246 bit to support kernel maximal - enhance libdm deptree code to support data_offset (out-of-place reshaping) and delta_disk (legs add/remove reshaping) target arguments Related: rhbz834579 Related: rhbz1191935 Related: rhbz1191978
2017-02-24 02:50:00 +03:00
lv_manip: reuse function also during reduction Move function _setup_lv_size() in front of _lv_reduce() so it can be reused also in this function. Avoid propagating 0 length to upper layer.
2021-02-05 13:37:52 +03:00
if ((seg = first_seg(lv))) {
if (is_raid10)
lvconvert: add infrastructure for RaidLV reshaping support In order to support striped raid5/6/10 LV reshaping (change of LV type, stripesize or number of legs), this patch introduces infrastructure prerequisites to be used by raid_manip.c extensions in followup patches. This base is needed for allocation of out-of-place reshape space required by the MD raid personalities to avoid writing over data in-place when reading off the current RAID layout or number of legs and writing out the new layout or to a different number of legs (i.e. restripe) Changes: - add members reshape_len to 'struct lv_segment' to store out-of-place reshape length per component rimage - add member data_copies to struct lv_segment to support more than 2 raid10 data copies - make alloc_lv_segment() aware of both reshape_len and data_copies - adjust all alloc_lv_segment() callers to the new API - add functions to retrieve the current data offset (needed for out-of-place reshaping space allocation) and the devices count from the kernel - make libdm deptree code aware of reshape_len - add LV flags for disk add/remove reshaping - support import/export of the new 'struct lv_segment' members - enhance lv_extend/_lv_reduce to cope with reshape_len - add seg_is_*/segtype_is_* macros related to reshaping - add target version check for reshaping - grow rebuilds/writemostly bitmaps to 246 bit to support kernel maximal - enhance libdm deptree code to support data_offset (out-of-place reshaping) and delta_disk (legs add/remove reshaping) target arguments Related: rhbz834579 Related: rhbz1191935 Related: rhbz1191978
2017-02-24 02:50:00 +03:00
seg->len = seg->area_len = lv->le_count;
raid: define seg->extents_copied seg->extents_copied has to be defined properly on reducing the size of a raid LV or conversion from raid5 with 1 stripe to raid1 will fail. Related: rhbz834579 Related: rhbz1191935 Related: rhbz1191978
2017-03-08 01:28:09 +03:00
seg->extents_copied = seg->len;
lv_manip: reuse function also during reduction Move function _setup_lv_size() in front of _lv_reduce() so it can be reused also in this function. Avoid propagating 0 length to upper layer.
2021-02-05 13:37:52 +03:00
}
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
Various allocation-related pvmove fixes.
2005-06-14 21:54:48 +04:00
if (!delete)
return 1;
pool: fix removal of pool metadata spare Since we support device stack of pools over pool (thin-pool with cache data volume) the existing code is no longer able to detect orphan _pmspare. So instead do a _pmspare check after volume removal, and remove spare afterwards.
2014-11-13 15:09:07 +03:00
if (lv == lv->vg->pool_metadata_spare_lv) {
lv->status &= ~POOL_METADATA_SPARE;
lv->vg->pool_metadata_spare_lv = NULL;
}
lvremove mirror images
2005-06-03 19:44:12 +04:00
/* Remove the LV if it is now empty */
Introduce link_lv_to_vg and unlink_lv_from_vg functions. link_lv_to_vg and unlink_lv_from_vg are the only functions for adding/removing logical volume from volume group. Only these function should manipulate with vg->lvs list.
2009-05-14 01:25:01 +04:00
if (!lv->le_count && !unlink_lv_from_vg(lv))
return_0;
else if (lv->vg->fid->fmt->ops->lv_setup &&
Use stack return macros throughout.
2008-01-30 16:19:47 +03:00
!lv->vg->fid->fmt->ops->lv_setup(lv->vg->fid, lv))
return_0;
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
thin: reload external origin with last thin External origin could be activated as stand-alone device. When the last thin LV is removed, external origin is no longer the external origin and it's layer property was dropped. Ensure dm table is correct by reloading external origin (when it's active).
2016-12-17 23:55:02 +03:00
/* Removal of last user enforces refresh */
if (external_lv && !lv_is_external_origin(external_lv) &&
lv_is_active(external_lv) &&
!lv_update_and_reload(external_lv))
return_0;
pools: fix removal of spare volume When removing pool LV from a stacked LV setup, it's been possible to leak _pmspare and such hidden LV then required manual user removal. Fix it by moving automatic removal into _lv_reduce().
2021-01-22 16:31:12 +03:00
/* When removing last pool, automatically drop the spare volume */
if (is_last_pool && lv->vg->pool_metadata_spare_lv) {
/* TODO: maybe use a list of pools or a counter to avoid linear search through VG */
dm_list_iterate_items(lvl, &lv->vg->lvs)
if (lv_is_thin_type(lvl->lv) ||
lv_is_cache_type(lvl->lv)) {
is_last_pool = 0;
break;
}
if (is_last_pool) {
/* This is purely internal LV volume, no question */
if (!deactivate_lv(lv->vg->cmd, lv->vg->pool_metadata_spare_lv)) {
log_error("Unable to deactivate spare logical volume %s.",
display_lvname(lv->vg->pool_metadata_spare_lv));
return 0;
}
if (!lv_remove(lv->vg->pool_metadata_spare_lv))
return_0;
}
}
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
return 1;
}
Various allocation-related pvmove fixes.
2005-06-14 21:54:48 +04:00
/*
preparation for parallel_areas changes to allocation code
2005-11-24 23:58:44 +03:00
* Empty an LV.
Various allocation-related pvmove fixes.
2005-06-14 21:54:48 +04:00
*/
int lv_empty(struct logical_volume *lv)
{
Fix lv_empty.
2005-11-24 21:46:51 +03:00
return _lv_reduce(lv, lv->le_count, 0);
Various allocation-related pvmove fixes.
2005-06-14 21:54:48 +04:00
}
lvconvert/vgreduce fixes
2008-01-17 16:13:54 +03:00
/*
* Empty an LV and add error segment.
*/
rename lv_remap_error
2008-01-17 16:54:05 +03:00
int replace_lv_with_error_segment(struct logical_volume *lv)
lvconvert/vgreduce fixes
2008-01-17 16:13:54 +03:00
{
uint32_t len = lv->le_count;
cov: check for possible NULL segtype Although likely impossible to ever miss ERROR segtype, make analyzer hapier.
2021-09-20 02:51:29 +03:00
struct segment_type *segtype;
if (!(segtype = get_segtype_from_string(lv->vg->cmd, SEG_TYPE_NAME_ERROR)))
return_0;
lvconvert/vgreduce fixes
2008-01-17 16:13:54 +03:00
Major pvmove fix to issue ioctls in the correct order when multiple LVs are affected by the move. (Currently it's possible for I/O to become trapped between suspended devices amongst other problems. The current fix was selected so as to minimise the testing surface. I hope eventually to replace it with a cleaner one that extends the deptree code. Some lvconvert scenarios still suffer from related problems.
2011-06-11 04:03:06 +04:00
if (len && !lv_empty(lv))
lvconvert/vgreduce fixes
2008-01-17 16:13:54 +03:00
return_0;
Major pvmove fix to issue ioctls in the correct order when multiple LVs are affected by the move. (Currently it's possible for I/O to become trapped between suspended devices amongst other problems. The current fix was selected so as to minimise the testing surface. I hope eventually to replace it with a cleaner one that extends the deptree code. Some lvconvert scenarios still suffer from related problems.
2011-06-11 04:03:06 +04:00
/* Minimum size required for a table. */
if (!len)
len = 1;
Fix for bug 637936: killing both redundant logs causes deadlock Problem: When both legs of a mirrored log fail, neither the log nor the parent mirror can proceed. The repair code must be careful to replace the log with an error target before operating on the parent - otherwise, the parent can get stuck trying to suspend because it can't push through any writes. The steps to replace the log device with an error target were incomplete and resulted in the replacement not happening at all! The code originally had all the necessary logic to complete the replacement task, but was pulled out in a effort to clean-up that section of code, while fixing another bug: <offending commit msg> In addition, I added following three changes. - Removed tmp_orphan_lvs handling procedure It seems that _delete_lv() can handle detached_log_lv properly without adding mirror legs in mirrored log to tmp_orphan_lvs. Therefore, I removed the procedure. - Removed vg_write()/vg_commit() Metadata is saved by vg_write()/vg_commit() just after detached_log_lv is handled. Therefore, I removed vg_write()/vg_commit(). </offending commit msg> http://sources.redhat.com/cgi-bin/cvsweb.cgi/LVM2/lib/metadata/mirror.c?cvsroot=lvm2&f=h#rev1.130 I've reverted the "clean-up" changes associated with that fix, but not what that commit was actually fixing. Signed-off-by: Jonathan Brassow <jbrassow@redhat.com> Reviewed-by: Petr Rockai <prockai@redhat.com>
2010-10-15 00:03:12 +04:00
/*
* Since we are replacing the whatever-was-there with
* an error segment, we should also clear any flags
* that suggest it is anything other than "error".
*/
mirrors: Fix checks for mirror/raid/pvmove LVs. Try to enforce consistent macro usage along these lines: lv_is_mirror - mirror that uses the original dm-raid1 implementation (segment type "mirror") lv_is_mirror_type - also includes internal mirror image and log LVs lv_is_raid - raid volume that uses the new dm-raid implementation (segment type "raid") lv_is_raid_type - also includes internal raid image / log / metadata LVs lv_is_mirrored - LV is mirrored using either kernel implementation (excludes non-mirror modes like raid5 etc.) lv_is_pvmove - internal pvmove volume
2014-09-16 03:13:46 +04:00
/* FIXME Check for other flags that need removing */
lv->status &= ~(MIRROR|MIRRORED|PVMOVE|LOCKED);
Fix for bug 637936: killing both redundant logs causes deadlock Problem: When both legs of a mirrored log fail, neither the log nor the parent mirror can proceed. The repair code must be careful to replace the log with an error target before operating on the parent - otherwise, the parent can get stuck trying to suspend because it can't push through any writes. The steps to replace the log device with an error target were incomplete and resulted in the replacement not happening at all! The code originally had all the necessary logic to complete the replacement task, but was pulled out in a effort to clean-up that section of code, while fixing another bug: <offending commit msg> In addition, I added following three changes. - Removed tmp_orphan_lvs handling procedure It seems that _delete_lv() can handle detached_log_lv properly without adding mirror legs in mirrored log to tmp_orphan_lvs. Therefore, I removed the procedure. - Removed vg_write()/vg_commit() Metadata is saved by vg_write()/vg_commit() just after detached_log_lv is handled. Therefore, I removed vg_write()/vg_commit(). </offending commit msg> http://sources.redhat.com/cgi-bin/cvsweb.cgi/LVM2/lib/metadata/mirror.c?cvsroot=lvm2&f=h#rev1.130 I've reverted the "clean-up" changes associated with that fix, but not what that commit was actually fixing. Signed-off-by: Jonathan Brassow <jbrassow@redhat.com> Reviewed-by: Petr Rockai <prockai@redhat.com>
2010-10-15 00:03:12 +04:00
mirrors: Fix checks for mirror/raid/pvmove LVs. Try to enforce consistent macro usage along these lines: lv_is_mirror - mirror that uses the original dm-raid1 implementation (segment type "mirror") lv_is_mirror_type - also includes internal mirror image and log LVs lv_is_raid - raid volume that uses the new dm-raid implementation (segment type "raid") lv_is_raid_type - also includes internal raid image / log / metadata LVs lv_is_mirrored - LV is mirrored using either kernel implementation (excludes non-mirror modes like raid5 etc.) lv_is_pvmove - internal pvmove volume
2014-09-16 03:13:46 +04:00
/* FIXME Check for any attached LVs that will become orphans e.g. mirror logs */
Fix for bug 637936: killing both redundant logs causes deadlock Problem: When both legs of a mirrored log fail, neither the log nor the parent mirror can proceed. The repair code must be careful to replace the log with an error target before operating on the parent - otherwise, the parent can get stuck trying to suspend because it can't push through any writes. The steps to replace the log device with an error target were incomplete and resulted in the replacement not happening at all! The code originally had all the necessary logic to complete the replacement task, but was pulled out in a effort to clean-up that section of code, while fixing another bug: <offending commit msg> In addition, I added following three changes. - Removed tmp_orphan_lvs handling procedure It seems that _delete_lv() can handle detached_log_lv properly without adding mirror legs in mirrored log to tmp_orphan_lvs. Therefore, I removed the procedure. - Removed vg_write()/vg_commit() Metadata is saved by vg_write()/vg_commit() just after detached_log_lv is handled. Therefore, I removed vg_write()/vg_commit(). </offending commit msg> http://sources.redhat.com/cgi-bin/cvsweb.cgi/LVM2/lib/metadata/mirror.c?cvsroot=lvm2&f=h#rev1.130 I've reverted the "clean-up" changes associated with that fix, but not what that commit was actually fixing. Signed-off-by: Jonathan Brassow <jbrassow@redhat.com> Reviewed-by: Petr Rockai <prockai@redhat.com>
2010-10-15 00:03:12 +04:00
cov: check for possible NULL segtype Although likely impossible to ever miss ERROR segtype, make analyzer hapier.
2021-09-20 02:51:29 +03:00
if (!lv_add_virtual_segment(lv, 0, len, segtype))
lvconvert/vgreduce fixes
2008-01-17 16:13:54 +03:00
return_0;
return 1;
}
lvchange: allow a transiently failed RaidLV to be refreshed In case any SubLV of a RaidLV transiently fails, it needs two "lvchange --refresh RaidLV" runs to get it to fully operational mode again. Reason being, that lvm reloads all targets for the RaidLV tree but doesn't resume the SubLVs until after the whole tree has been reloaded in the first refresh run. Thus the live mapping table of the SubLVs still point to an "error" mapping and the dm-raid target can't retrieve any superblock from the MetaLV(s) in processing the constructor during this preload thus not discovering the again accessible SubLVs. In the second run, the SubLV targets map proper (meta)data, hence the constructor discovers those fine now. Solve by resuming the SubLVs of the RaidLV before preloading the respective top-level RaidLV target. Resolves: rhbz1399844
2016-12-01 00:56:37 +03:00
static int _lv_refresh_suspend_resume(const struct logical_volume *lv)
lv_refresh: move the bulk of the function into lib So that it can be used from other lib code.
2015-06-16 21:38:40 +03:00
{
cleanup: drop cmd and constify lv for lv_refresh_suspend_resume() Like with most other lv_manip* functions take just LV arg and get cmd from embeded pointer when needed.
2016-05-20 11:55:05 +03:00
struct cmd_context *cmd = lv->vg->cmd;
refresh: call resume after failing suspend lv_refresh_suspend_resume() has escaped with fail ret code after failing suspend and could have left many volumes in suspend state. So always unconditionally call resume also when suspend has failed.
2016-05-20 14:20:54 +03:00
int r = 1;
cleanup: drop cmd and constify lv for lv_refresh_suspend_resume() Like with most other lv_manip* functions take just LV arg and get cmd from embeded pointer when needed.
2016-05-20 11:55:05 +03:00
cleanup: use lv_is_partial Check for PARTIAL_LV flag in standard way.
2016-03-02 22:59:03 +03:00
if (!cmd->partial_activation && lv_is_partial(lv)) {
lv_refresh: move the bulk of the function into lib So that it can be used from other lib code.
2015-06-16 21:38:40 +03:00
log_error("Refusing refresh of partial LV %s."
" Use '--activationmode partial' to override.",
display_lvname(lv));
return 0;
}
if (!suspend_lv(cmd, lv)) {
log_error("Failed to suspend %s.", display_lvname(lv));
refresh: call resume after failing suspend lv_refresh_suspend_resume() has escaped with fail ret code after failing suspend and could have left many volumes in suspend state. So always unconditionally call resume also when suspend has failed.
2016-05-20 14:20:54 +03:00
r = 0;
lv_refresh: move the bulk of the function into lib So that it can be used from other lib code.
2015-06-16 21:38:40 +03:00
}
if (!resume_lv(cmd, lv)) {
log_error("Failed to reactivate %s.", display_lvname(lv));
refresh: call resume after failing suspend lv_refresh_suspend_resume() has escaped with fail ret code after failing suspend and could have left many volumes in suspend state. So always unconditionally call resume also when suspend has failed.
2016-05-20 14:20:54 +03:00
r = 0;
lv_refresh: move the bulk of the function into lib So that it can be used from other lib code.
2015-06-16 21:38:40 +03:00
}
refresh: call resume after failing suspend lv_refresh_suspend_resume() has escaped with fail ret code after failing suspend and could have left many volumes in suspend state. So always unconditionally call resume also when suspend has failed.
2016-05-20 14:20:54 +03:00
return r;
lv_refresh: move the bulk of the function into lib So that it can be used from other lib code.
2015-06-16 21:38:40 +03:00
}
lvchange: allow a transiently failed RaidLV to be refreshed In case any SubLV of a RaidLV transiently fails, it needs two "lvchange --refresh RaidLV" runs to get it to fully operational mode again. Reason being, that lvm reloads all targets for the RaidLV tree but doesn't resume the SubLVs until after the whole tree has been reloaded in the first refresh run. Thus the live mapping table of the SubLVs still point to an "error" mapping and the dm-raid target can't retrieve any superblock from the MetaLV(s) in processing the constructor during this preload thus not discovering the again accessible SubLVs. In the second run, the SubLV targets map proper (meta)data, hence the constructor discovers those fine now. Solve by resuming the SubLVs of the RaidLV before preloading the respective top-level RaidLV target. Resolves: rhbz1399844
2016-12-01 00:56:37 +03:00
int lv_refresh_suspend_resume(const struct logical_volume *lv)
{
lvchange: allow a transiently failed RaidLV to be refreshed Add to commits 87117c2b2546 and 0b8bf73a63d8 to avoid refreshing two times altogether, thus avoiding issues related to clustered, remotely activated RaidLV. Avoid need to repeat "lvchange --refresh RaidLV" two times as a workaround to refresh a RaidLV. Fix handles removal of temporary *-missing-* devices created for any missing segments in RAID SubLVs during activation. Because the kernel dm-raid target isn't able to handle transiently failing devices properly we need "[dm-devel][PATCH] dm raid: fix transient device failure processing" as well. test: add lvchange-raid-transient-failures.sh and enhance lvconvert-raid.sh Resolves: rhbz1025322 Related: rhbz1265191 Related: rhbz1399844 Related: rhbz1404425
2016-12-23 05:35:13 +03:00
if (!_lv_refresh_suspend_resume(lv))
return 0;
lvchange: allow a transiently failed RaidLV to be refreshed In case any SubLV of a RaidLV transiently fails, it needs two "lvchange --refresh RaidLV" runs to get it to fully operational mode again. Reason being, that lvm reloads all targets for the RaidLV tree but doesn't resume the SubLVs until after the whole tree has been reloaded in the first refresh run. Thus the live mapping table of the SubLVs still point to an "error" mapping and the dm-raid target can't retrieve any superblock from the MetaLV(s) in processing the constructor during this preload thus not discovering the again accessible SubLVs. In the second run, the SubLV targets map proper (meta)data, hence the constructor discovers those fine now. Solve by resuming the SubLVs of the RaidLV before preloading the respective top-level RaidLV target. Resolves: rhbz1399844
2016-12-01 00:56:37 +03:00
/*
lvchange: allow a transiently failed RaidLV to be refreshed Add to commits 87117c2b2546 and 0b8bf73a63d8 to avoid refreshing two times altogether, thus avoiding issues related to clustered, remotely activated RaidLV. Avoid need to repeat "lvchange --refresh RaidLV" two times as a workaround to refresh a RaidLV. Fix handles removal of temporary *-missing-* devices created for any missing segments in RAID SubLVs during activation. Because the kernel dm-raid target isn't able to handle transiently failing devices properly we need "[dm-devel][PATCH] dm raid: fix transient device failure processing" as well. test: add lvchange-raid-transient-failures.sh and enhance lvconvert-raid.sh Resolves: rhbz1025322 Related: rhbz1265191 Related: rhbz1399844 Related: rhbz1404425
2016-12-23 05:35:13 +03:00
* Remove any transiently activated error
* devices which arean't used any more.
lvchange: allow a transiently failed RaidLV to be refreshed In case any SubLV of a RaidLV transiently fails, it needs two "lvchange --refresh RaidLV" runs to get it to fully operational mode again. Reason being, that lvm reloads all targets for the RaidLV tree but doesn't resume the SubLVs until after the whole tree has been reloaded in the first refresh run. Thus the live mapping table of the SubLVs still point to an "error" mapping and the dm-raid target can't retrieve any superblock from the MetaLV(s) in processing the constructor during this preload thus not discovering the again accessible SubLVs. In the second run, the SubLV targets map proper (meta)data, hence the constructor discovers those fine now. Solve by resuming the SubLVs of the RaidLV before preloading the respective top-level RaidLV target. Resolves: rhbz1399844
2016-12-01 00:56:37 +03:00
*/
lvchange: allow a transiently failed RaidLV to be refreshed Add to commits 87117c2b2546 and 0b8bf73a63d8 to avoid refreshing two times altogether, thus avoiding issues related to clustered, remotely activated RaidLV. Avoid need to repeat "lvchange --refresh RaidLV" two times as a workaround to refresh a RaidLV. Fix handles removal of temporary *-missing-* devices created for any missing segments in RAID SubLVs during activation. Because the kernel dm-raid target isn't able to handle transiently failing devices properly we need "[dm-devel][PATCH] dm raid: fix transient device failure processing" as well. test: add lvchange-raid-transient-failures.sh and enhance lvconvert-raid.sh Resolves: rhbz1025322 Related: rhbz1265191 Related: rhbz1399844 Related: rhbz1404425
2016-12-23 05:35:13 +03:00
if (lv_is_raid(lv) && !lv_deactivate_any_missing_subdevs(lv)) {
log_error("Failed to remove temporary SubLVs from %s", display_lvname(lv));
return 0;
lvchange: allow a transiently failed RaidLV to be refreshed In case any SubLV of a RaidLV transiently fails, it needs two "lvchange --refresh RaidLV" runs to get it to fully operational mode again. Reason being, that lvm reloads all targets for the RaidLV tree but doesn't resume the SubLVs until after the whole tree has been reloaded in the first refresh run. Thus the live mapping table of the SubLVs still point to an "error" mapping and the dm-raid target can't retrieve any superblock from the MetaLV(s) in processing the constructor during this preload thus not discovering the again accessible SubLVs. In the second run, the SubLV targets map proper (meta)data, hence the constructor discovers those fine now. Solve by resuming the SubLVs of the RaidLV before preloading the respective top-level RaidLV target. Resolves: rhbz1399844
2016-12-01 00:56:37 +03:00
}
lvchange: allow a transiently failed RaidLV to be refreshed Add to commits 87117c2b2546 and 0b8bf73a63d8 to avoid refreshing two times altogether, thus avoiding issues related to clustered, remotely activated RaidLV. Avoid need to repeat "lvchange --refresh RaidLV" two times as a workaround to refresh a RaidLV. Fix handles removal of temporary *-missing-* devices created for any missing segments in RAID SubLVs during activation. Because the kernel dm-raid target isn't able to handle transiently failing devices properly we need "[dm-devel][PATCH] dm raid: fix transient device failure processing" as well. test: add lvchange-raid-transient-failures.sh and enhance lvconvert-raid.sh Resolves: rhbz1025322 Related: rhbz1265191 Related: rhbz1399844 Related: rhbz1404425
2016-12-23 05:35:13 +03:00
return 1;
lvchange: allow a transiently failed RaidLV to be refreshed In case any SubLV of a RaidLV transiently fails, it needs two "lvchange --refresh RaidLV" runs to get it to fully operational mode again. Reason being, that lvm reloads all targets for the RaidLV tree but doesn't resume the SubLVs until after the whole tree has been reloaded in the first refresh run. Thus the live mapping table of the SubLVs still point to an "error" mapping and the dm-raid target can't retrieve any superblock from the MetaLV(s) in processing the constructor during this preload thus not discovering the again accessible SubLVs. In the second run, the SubLV targets map proper (meta)data, hence the constructor discovers those fine now. Solve by resuming the SubLVs of the RaidLV before preloading the respective top-level RaidLV target. Resolves: rhbz1399844
2016-12-01 00:56:37 +03:00
}
Fix lv_empty.
2005-11-24 21:46:51 +03:00
/*
preparation for parallel_areas changes to allocation code
2005-11-24 23:58:44 +03:00
* Remove given number of extents from LV.
Fix lv_empty.
2005-11-24 21:46:51 +03:00
*/
Various allocation-related pvmove fixes.
2005-06-14 21:54:48 +04:00
int lv_reduce(struct logical_volume *lv, uint32_t extents)
{
lvreduce/lvresize: add ability to reduce the size of a RaidLV - support shrinking of raid0/1/4/5/6/10 LVs - enhance lvresize-raid.sh tests: add raid0* and raid10 - fix have_raid4 in aux.sh to allow lv_resize-raid.sh and other scripts to test raid4 Resolves: rhbz1394048
2017-02-10 00:41:28 +03:00
struct lv_segment *seg = first_seg(lv);
raid: fix raid LV resizing The lv_extend/_lv_reduce API doesn't cope with resizing RaidLVs with allocated reshape space and ongoing conversions. Prohibit resizing during conversions and remove the reshape space before processing resize. Add missing seg->data_copies initialisation. Fix typo/comment.
2017-03-08 00:05:23 +03:00
/* Ensure stripe boundary extents on RAID LVs */
lvreduce/lvresize: add ability to reduce the size of a RaidLV - support shrinking of raid0/1/4/5/6/10 LVs - enhance lvresize-raid.sh tests: add raid0* and raid10 - fix have_raid4 in aux.sh to allow lv_resize-raid.sh and other scripts to test raid4 Resolves: rhbz1394048
2017-02-10 00:41:28 +03:00
if (lv_is_raid(lv) && extents != lv->le_count)
extents =_round_to_stripe_boundary(lv->vg, extents,
seg_is_raid1(seg) ? 0 : _raid_stripes_count(seg), 0);
lvremove: validate removed component LV is not active This is the 'last' place where a LV is present in metadata. Any removed device should not be left active in dm table. So this check is an extra validation protection to capture any forgotten deactivation (adding 1 extra ioctl into lvremove path)
2018-03-02 18:32:05 +03:00
if ((extents == lv->le_count) && lv_is_component(lv) && lv_is_active(lv)) {
/* When LV is removed, make sure it is inactive */
log_error(INTERNAL_ERROR "Removing still active LV %s.", display_lvname(lv));
return 0;
}
Various allocation-related pvmove fixes.
2005-06-14 21:54:48 +04:00
return _lv_reduce(lv, extents, 1);
}
metadata: add historical_glv_remove
2016-03-01 17:26:57 +03:00
int historical_glv_remove(struct generic_logical_volume *glv)
{
struct generic_logical_volume *origin_glv;
struct glv_list *glvl, *user_glvl;
struct historical_logical_volume *hlv;
int reconnected;
if (!glv || !glv->is_historical)
return_0;
hlv = glv->historical;
if (!(glv = find_historical_glv(hlv->vg, hlv->name, 0, &glvl))) {
if (!(find_historical_glv(hlv->vg, hlv->name, 1, NULL))) {
log_error(INTERNAL_ERROR "historical_glv_remove: historical LV %s/-%s not found ",
hlv->vg->name, hlv->name);
return 0;
}
tidy: prefer not using else after return clang-tidy: avoid using 'else' after return - give more readable code, and also saves indention level.
2017-07-19 17:16:12 +03:00
log_verbose("Historical LV %s/-%s already on removed list ",
hlv->vg->name, hlv->name);
return 1;
metadata: add historical_glv_remove
2016-03-01 17:26:57 +03:00
}
if ((origin_glv = hlv->indirect_origin) &&
!remove_glv_from_indirect_glvs(origin_glv, glv))
return_0;
dm_list_iterate_items(user_glvl, &hlv->indirect_glvs) {
reconnected = 0;
if ((origin_glv && !origin_glv->is_historical) && !user_glvl->glv->is_historical)
log_verbose("Removing historical connection between %s and %s.",
origin_glv->live->name, user_glvl->glv->live->name);
else if (hlv->vg->cmd->record_historical_lvs) {
if (!add_glv_to_indirect_glvs(hlv->vg->vgmem, origin_glv, user_glvl->glv))
return_0;
reconnected = 1;
}
if (!reconnected) {
/*
* Break ancestry chain if we're removing historical LV and tracking
* historical LVs is switched off either via:
* - "metadata/record_lvs_history=0" config
* - "--nohistory" cmd line option
*
* Also, break the chain if we're unable to store such connection at all
* because we're removing the very last historical LV that was in between
* live LVs - pure live LVs can't store any indirect origin relation in
* metadata - we need at least one historical LV to do that!
*/
if (user_glvl->glv->is_historical)
user_glvl->glv->historical->indirect_origin = NULL;
else
first_seg(user_glvl->glv->live)->indirect_origin = NULL;
}
}
dm_list_move(&hlv->vg->removed_historical_lvs, &glvl->list);
return 1;
}
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
/*
* Completely remove an LV.
*/
int lv_remove(struct logical_volume *lv)
{
metadata: add historical_glv_remove
2016-03-01 17:26:57 +03:00
if (lv_is_historical(lv))
return historical_glv_remove(lv->this_glv);
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
Use stack return macros throughout.
2008-01-30 16:19:47 +03:00
if (!lv_reduce(lv, lv->le_count))
return_0;
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
return 1;
}
/*
* A set of contiguous physical extents allocated
*/
struct alloced_area {
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
struct dm_list list;
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
struct physical_volume *pv;
uint32_t pe;
uint32_t len;
};
/*
* Details of an allocation attempt
*/
struct alloc_handle {
check_contiguous to use for_each_pv
2006-10-08 03:40:36 +04:00
struct cmd_context *cmd;
Use hash, bitset, malloc, pool from libdevmapper.
2005-10-17 03:03:59 +04:00
struct dm_pool *mem;
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
alloc_policy_t alloc; /* Overall policy */
style: Miscellaneous tidying up of metadata/lv*
2015-09-23 16:37:52 +03:00
int approx_alloc; /* get as much as possible up to new_extents */
Extend core allocation code in preparation for mirrored log areas.
2010-03-01 23:00:20 +03:00
uint32_t new_extents; /* Number of new extents required */
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
uint32_t area_count; /* Number of parallel areas */
style: Miscellaneous tidying up of metadata/lv*
2015-09-23 16:37:52 +03:00
uint32_t parity_count; /* Adds to area_count, but not area_multiple */
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
uint32_t area_multiple; /* seg->len = area_len * area_multiple */
Extend core allocation code in preparation for mirrored log areas.
2010-03-01 23:00:20 +03:00
uint32_t log_area_count; /* Number of parallel logs */
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
uint32_t metadata_area_count; /* Number of parallel metadata areas */
uint32_t log_len; /* Length of log/metadata_area */
Extend core allocation code in preparation for mirrored log areas.
2010-03-01 23:00:20 +03:00
uint32_t region_size; /* Mirror region size */
Always insert an intermediate layer for mirrors. Suppress hidden LVs from reports unless --all is given. Use square brackets for hidden LVs in reports. Centralise restrictions on LV names.
2005-06-03 18:49:51 +04:00
uint32_t total_area_len; /* Total number of parallel extents */
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
unsigned maximise_cling;
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
unsigned mirror_logs_separate; /* Force mirror logs on separate PVs? */
/*
* RAID devices require a metadata area that accompanies each
* device. During initial creation, it is best to look for space
* that is new_extents + log_len and then split that between two
* allocated areas when found. 'alloc_and_split_meta' indicates
* that this is the desired dynamic.
cache: Allocation code changes necessary to support cache_pool Cache pools require a data and metadata area (like thin pools). Unlike thin pool, if 'cache_pool_metadata_require_separate_pvs' is not set to '1', the metadata and data area will be allocated from the same device. It is also done in a manner similar to RAID, where a single chunk of space is allocated and then split to form the metadata and data device - ensuring that they are together.
2014-01-28 22:25:02 +04:00
*
* This same idea is used by cache LVs to get the metadata device
* and data device allocated together.
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
*/
unsigned alloc_and_split_meta;
allocation: misc fixes for percent/raid rounding Several fixes for the recent changes that treat allocation percentages as upper limits. Improve messages to make it easier to see what is happening. Fix some cases that failed with errors when they didn't need to. Fix crashes when first_seg() returns NULL. Remove a couple of log_errors that were actually debugging messages.
2014-02-22 04:26:01 +04:00
unsigned split_metadata_is_allocated; /* Metadata has been allocated */
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
Move the core of the lib/config/config.c functionality into libdevmapper, leaving behind the LVM-specific parts of the code (convenience wrappers that handle `struct device` and `struct cmd_context`, basically). A number of functions have been renamed (in addition to getting a dm_ prefix) -- namely, all of the config interface now has a dm_config_ prefix.
2011-08-30 18:55:15 +04:00
const struct dm_config_node *cling_tag_list_cn;
Extend cling allocation policy to recognise PV tags (cling_by_tags). Add allocation/cling_tag_list to lvm.conf.
2010-11-09 15:34:40 +03:00
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
struct dm_list *parallel_areas; /* PVs to avoid */
preparation for parallel_areas changes to allocation code
2005-11-24 23:58:44 +03:00
Extend core allocation code in preparation for mirrored log areas.
2010-03-01 23:00:20 +03:00
/*
* Contains area_count lists of areas allocated to data stripes
* followed by log_area_count lists of areas allocated to log stripes.
*/
gcc: zero-sized array to fexlible array C99 Switch remaining zero sized struct to flexible arrays to be C99 complient. These simple rules should apply: - The incomplete array type must be the last element within the structure. - There cannot be an array of structures that contain a flexible array member. - Structures that contain a flexible array member cannot be used as a member of another structure. - The structure must contain at least one named member in addition to the flexible array member. Although some of the code pieces should be still improved.
2020-08-28 20:15:01 +03:00
struct dm_list alloced_areas[];
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
};
Extend core allocation code in preparation for mirrored log areas.
2010-03-01 23:00:20 +03:00
/*
* Returns log device size in extents, algorithm from kernel code
*/
#define BYTE_SHIFT 3
mirror: Fix log size calc when more than 1 extent. Currently the code creates the log separately after allocating space for the data and as no data allocation is needed this second time, total_extents ends up holding zero so use new_extents directly instead.
2015-11-06 02:40:47 +03:00
static uint32_t _mirror_log_extents(uint32_t region_size, uint32_t pe_size, uint32_t area_len)
Extend core allocation code in preparation for mirrored log areas.
2010-03-01 23:00:20 +03:00
{
mirror: fix 32bit size calculation On 32bit arch size_t remains 4-byte wide - so size can't get correct result for multiplication of 32bit numbers.
2018-04-19 13:29:42 +03:00
uint64_t area_size, region_count, bitset_size, log_size;
Extend core allocation code in preparation for mirrored log areas.
2010-03-01 23:00:20 +03:00
mirror: fix 32bit size calculation On 32bit arch size_t remains 4-byte wide - so size can't get correct result for multiplication of 32bit numbers.
2018-04-19 13:29:42 +03:00
area_size = (uint64_t) area_len * pe_size;
Extend core allocation code in preparation for mirrored log areas.
2010-03-01 23:00:20 +03:00
region_count = dm_div_up(area_size, region_size);
/* Work out how many "unsigned long"s we need to hold the bitset. */
bitset_size = dm_round_up(region_count, sizeof(uint32_t) << BYTE_SHIFT);
bitset_size >>= BYTE_SHIFT;
/* Log device holds both header and bitset. */
log_size = dm_round_up((MIRROR_LOG_OFFSET << SECTOR_SHIFT) + bitset_size, 1 << SECTOR_SHIFT);
log_size >>= SECTOR_SHIFT;
Fix for bug 737200 - Can't create mirrored-log mirror on a VG with small extents Kernel requires a mirror to be at least 1 region large. So, if our mirror log is itself a mirror, it must be at least 1 region large. This restriction may not be necessary for non-mirrored logs, but we apply the rule anyway. (The other option is to make the region size of the log mirror smaller than the mirror it is acting as a log for, but that really complicates things. It's much easier to keep the region_size the same for both.)
2011-09-13 22:42:57 +04:00
log_size = dm_div_up(log_size, pe_size);
Extend core allocation code in preparation for mirrored log areas.
2010-03-01 23:00:20 +03:00
mirror: improve mirror log size estimation Drop mirrored mirror log limitation that applies only in very limited use-case and actually mirrored mirror log is deprecated anyway. So 'disk' mirror log is selecting the correct minimal size, and bigger size is only enforced with real mirrored mirror log. Also for mirrored mirror log we let use 'smalled' region size if needed so if user uses 1G region size, we still keep small mirror log with much smaller region size in this case when needed. Also mirror log extent calculation is now properly detecting error with too big mirrors where previosly trimmed uint32_t was applies unintentionally.
2018-04-20 11:12:25 +03:00
if (log_size > UINT32_MAX) {
log_error("Log size needs too many extents "FMTu64" with region size of %u sectors.",
log_size, region_size);
log_size = UINT32_MAX;
/* VG likely will not have enough free space for this allocation -> error */
}
return (uint32_t) log_size;
Extend core allocation code in preparation for mirrored log areas.
2010-03-01 23:00:20 +03:00
}
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
/* Is there enough total space or should we give up immediately? */
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
static int _sufficient_pes_free(struct alloc_handle *ah, struct dm_list *pvms,
alloc: enhance estimation of sufficient_pes_free Since commit 77fdc17d70e62cab75efaaf0dad02493b948610d always include log_len size into needed extents - however now we may need sometimes more extents then necessary - mainly when multiple PVs are involved into allocation. Add logs_still_needed into calculation of sufficient_pes_free()
2021-01-12 17:58:07 +03:00
uint32_t allocated, uint32_t log_still_needed,
uint32_t extents_still_needed)
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
{
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
uint32_t area_extents_needed = (extents_still_needed - allocated) * ah->area_count / ah->area_multiple;
uint32_t parity_extents_needed = (extents_still_needed - allocated) * ah->parity_count / ah->area_multiple;
alloc: enhance estimation of sufficient_pes_free Since commit 77fdc17d70e62cab75efaaf0dad02493b948610d always include log_len size into needed extents - however now we may need sometimes more extents then necessary - mainly when multiple PVs are involved into allocation. Add logs_still_needed into calculation of sufficient_pes_free()
2021-01-12 17:58:07 +03:00
uint32_t metadata_extents_needed = (ah->alloc_and_split_meta ? 0 : ah->metadata_area_count * RAID_METADATA_AREA_LEN) +
(log_still_needed ? ah->log_len : 0); /* One each */
alloc: improve estimation of sufficient_pes_free Metadata size was calculated correctly only for raids. Fixes problem for crash during lvcreate when thin-pool was created on a VG where remaining free space had the size to only fit a single metadata LV and not also its _pmspare. Lvcreate crashed with this assert message: lvcreate: metadata/pv_map.c:198: consume_pv_area: Assertion `to_go <= pva->count' failed. Aborted (core dumped) TODO: there is probably to large overload of several alloc_handle variables. Reported-by: Wu Guanghao<wuguanghao3@huawei.com> Reported-by: Zhiqiang Liu <liuzhiqiang26@huawei.com>
2020-09-11 21:57:20 +03:00
uint64_t total_extents_needed = (uint64_t)area_extents_needed + parity_extents_needed + metadata_extents_needed;
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
uint32_t free_pes = pv_maps_size(pvms);
if (total_extents_needed > free_pes) {
alloc: improve estimation of sufficient_pes_free Metadata size was calculated correctly only for raids. Fixes problem for crash during lvcreate when thin-pool was created on a VG where remaining free space had the size to only fit a single metadata LV and not also its _pmspare. Lvcreate crashed with this assert message: lvcreate: metadata/pv_map.c:198: consume_pv_area: Assertion `to_go <= pva->count' failed. Aborted (core dumped) TODO: there is probably to large overload of several alloc_handle variables. Reported-by: Wu Guanghao<wuguanghao3@huawei.com> Reported-by: Zhiqiang Liu <liuzhiqiang26@huawei.com>
2020-09-11 21:57:20 +03:00
log_error("Insufficient free space: %" PRIu64 " extents needed,"
allocation: misc fixes for percent/raid rounding Several fixes for the recent changes that treat allocation percentages as upper limits. Improve messages to make it easier to see what is happening. Fix some cases that failed with errors when they didn't need to. Fix crashes when first_seg() returns NULL. Remove a couple of log_errors that were actually debugging messages.
2014-02-22 04:26:01 +04:00
" but only %" PRIu32 " available",
total_extents_needed, free_pes);
return 0;
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
}
return 1;
}
/* For striped mirrors, all the areas are counted, through the mirror layer */
static uint32_t _stripes_per_mimage(struct lv_segment *seg)
{
struct lv_segment *last_lvseg;
if (seg_is_mirrored(seg) && seg->area_count && seg_type(seg, 0) == AREA_LV) {
last_lvseg = dm_list_item(dm_list_last(&seg_lv(seg, 0)->segments), struct lv_segment);
if (seg_is_striped(last_lvseg))
return last_lvseg->area_count;
}
return 1;
}
Test/clean-up: Indent clean-up and additional RAID resize test Better indenting and a test for bug 1005434 (parity RAID should extend in a contiguous fashion).
2013-09-25 06:32:53 +04:00
static void _init_alloc_parms(struct alloc_handle *ah,
struct alloc_parms *alloc_parms,
alloc_policy_t alloc,
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
struct lv_segment *prev_lvseg, unsigned can_split,
uint32_t allocated, uint32_t extents_still_needed)
{
alloc_parms->alloc = alloc;
alloc_parms->prev_lvseg = prev_lvseg;
alloc_parms->flags = 0;
alloc_parms->extents_still_needed = extents_still_needed;
Test/clean-up: Indent clean-up and additional RAID resize test Better indenting and a test for bug 1005434 (parity RAID should extend in a contiguous fashion).
2013-09-25 06:32:53 +04:00
/*
* Only attempt contiguous/cling allocation to previous segment
* areas if the number of areas matches.
*/
RAID: Fix broken allocation policies for parity RAID types A previous commit (b6bfddcd0a830d0c9312bc3ab906cb3d1b7a6dd9) which was designed to prevent segfaults during lvextend when trying to extend striped logical volumes forgot to include calculations for RAID4/5/6 parity devices. This was causing the 'contiguous' and 'cling_by_tags' allocation policies to fail for RAID 4/5/6. The solution is to remember that while we can compare ah->area_count == prev_lvseg->area_count for non-RAID, we should compare (ah->area_count + ah->parity_count) == prev_lvseg->area_count for a general solution.
2013-09-25 06:32:10 +04:00
if (alloc_parms->prev_lvseg &&
alloc: Correct existing use of positional fill. Perform two allocation attempts with cling if maximise_cling is set, first with then without positional fill. Avoid segfaults from confusion between positional and sorted sequential allocation when number of stripes varies as reported here: https://www.redhat.com/archives/linux-lvm/2014-March/msg00001.html
2014-04-15 05:34:35 +04:00
((ah->area_count + ah->parity_count) == prev_lvseg->area_count)) {
alloc: fix lvextend when stripe number varies The PREFERRED allocation mechanism requires the number of areas in the previous LV segment to match the number in the new segment being allocated. If they do not match, the code may crash. E.g. https://bugzilla.redhat.com/989347 Introduce A_AREA_COUNT_MATCHES and when not set avoid referring to the previous segment with the contiguous and cling policies.
2013-07-29 22:35:45 +04:00
alloc_parms->flags |= A_AREA_COUNT_MATCHES;
alloc: Correct existing use of positional fill. Perform two allocation attempts with cling if maximise_cling is set, first with then without positional fill. Avoid segfaults from confusion between positional and sorted sequential allocation when number of stripes varies as reported here: https://www.redhat.com/archives/linux-lvm/2014-March/msg00001.html
2014-04-15 05:34:35 +04:00
/* Are there any preceding segments we must follow on from? */
if (alloc_parms->alloc == ALLOC_CONTIGUOUS) {
Append _TO_LVSEG to names of internal A_CONTIGUOUS and A_CLING flags. Remove some unnecesary prev_lvseg checks.
2012-05-11 22:59:01 +04:00
alloc_parms->flags |= A_CONTIGUOUS_TO_LVSEG;
alloc: Correct existing use of positional fill. Perform two allocation attempts with cling if maximise_cling is set, first with then without positional fill. Avoid segfaults from confusion between positional and sorted sequential allocation when number of stripes varies as reported here: https://www.redhat.com/archives/linux-lvm/2014-March/msg00001.html
2014-04-15 05:34:35 +04:00
alloc_parms->flags |= A_POSITIONAL_FILL;
} else if ((alloc_parms->alloc == ALLOC_CLING) ||
(alloc_parms->alloc == ALLOC_CLING_BY_TAGS)) {
Append _TO_LVSEG to names of internal A_CONTIGUOUS and A_CLING flags. Remove some unnecesary prev_lvseg checks.
2012-05-11 22:59:01 +04:00
alloc_parms->flags |= A_CLING_TO_LVSEG;
alloc: Correct existing use of positional fill. Perform two allocation attempts with cling if maximise_cling is set, first with then without positional fill. Avoid segfaults from confusion between positional and sorted sequential allocation when number of stripes varies as reported here: https://www.redhat.com/archives/linux-lvm/2014-March/msg00001.html
2014-04-15 05:34:35 +04:00
alloc_parms->flags |= A_POSITIONAL_FILL;
}
Fix cling policy not to behave like normal policy if no previous LV seg. Fix alloc cling to cling to PVs already found with contiguous policy.
2012-05-12 02:53:13 +04:00
} else
/*
Test/clean-up: Indent clean-up and additional RAID resize test Better indenting and a test for bug 1005434 (parity RAID should extend in a contiguous fashion).
2013-09-25 06:32:53 +04:00
* A cling allocation that follows a successful contiguous
* allocation must use the same PVs (or else fail).
Fix cling policy not to behave like normal policy if no previous LV seg. Fix alloc cling to cling to PVs already found with contiguous policy.
2012-05-12 02:53:13 +04:00
*/
Test/clean-up: Indent clean-up and additional RAID resize test Better indenting and a test for bug 1005434 (parity RAID should extend in a contiguous fashion).
2013-09-25 06:32:53 +04:00
if ((alloc_parms->alloc == ALLOC_CLING) ||
alloc: Introduce A_POSITIONAL_FILL. Set A_POSITIONAL_FILL if the array of areas is being filled positionally (with a slot corresponding to each 'leg') rather than sequentially (with all suitable areas found, to be sorted and selected from).
2014-04-15 04:13:47 +04:00
(alloc_parms->alloc == ALLOC_CLING_BY_TAGS)) {
Fix cling policy not to behave like normal policy if no previous LV seg. Fix alloc cling to cling to PVs already found with contiguous policy.
2012-05-12 02:53:13 +04:00
alloc_parms->flags |= A_CLING_TO_ALLOCED;
alloc: Introduce A_POSITIONAL_FILL. Set A_POSITIONAL_FILL if the array of areas is being filled positionally (with a slot corresponding to each 'leg') rather than sequentially (with all suitable areas found, to be sorted and selected from).
2014-04-15 04:13:47 +04:00
alloc_parms->flags |= A_POSITIONAL_FILL;
}
Fix cling policy not to behave like normal policy if no previous LV seg. Fix alloc cling to cling to PVs already found with contiguous policy.
2012-05-12 02:53:13 +04:00
if (alloc_parms->alloc == ALLOC_CLING_BY_TAGS)
alloc_parms->flags |= A_CLING_BY_TAGS;
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
alloc: Add A_PARTITION_BY_TAGS to avoid sharing. Add A_PARTITION_BY_TAGS set when allocated areas should not share tags with each other and allow _match_pv_tags to accept an alternative list of tags. (Not used yet.)
2015-04-10 23:57:52 +03:00
if (!(alloc_parms->alloc & A_POSITIONAL_FILL) &&
(alloc_parms->alloc == ALLOC_CONTIGUOUS) &&
ah->cling_tag_list_cn)
alloc_parms->flags |= A_PARTITION_BY_TAGS;
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
/*
cleanup: spaces
2016-01-11 16:11:37 +03:00
* For normal allocations, if any extents have already been found
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
* for allocation, prefer to place further extents on the same disks as
* have already been used.
*/
Test/clean-up: Indent clean-up and additional RAID resize test Better indenting and a test for bug 1005434 (parity RAID should extend in a contiguous fashion).
2013-09-25 06:32:53 +04:00
if (ah->maximise_cling &&
(alloc_parms->alloc == ALLOC_NORMAL) &&
(allocated != alloc_parms->extents_still_needed))
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
alloc_parms->flags |= A_CLING_TO_ALLOCED;
if (can_split)
alloc_parms->flags |= A_CAN_SPLIT;
}
Switch status from 32-bit to 64-bit The physical_volume, volume_group, logical_volume and lv_segment structures' 'status' member is now uint64_t. The alignment of these structures was also audited to remove holes. The movement of some members in 'volume_group' and 'lv_segment' eliminates holes. The 'physical_volume' structure still has one 4-byte hole after 'pe_size'; the other structures no longer have any holes. Each structures' size has not changed.
2009-11-25 01:55:55 +03:00
static int _setup_alloced_segment(struct logical_volume *lv, uint64_t status,
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
uint32_t area_count,
uint32_t stripe_size,
Make SIZE_SHORT the default for display_size(). Fix some memory leaks in error paths found by coverity. Use C99 struct initialisers. Move DEFS into configure.h. Clean-ups to remove miscellaneous compiler warnings.
2006-05-10 01:23:51 +04:00
const struct segment_type *segtype,
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
struct alloced_area *aa,
Extend core allocation code in preparation for mirrored log areas.
2010-03-01 23:00:20 +03:00
uint32_t region_size)
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
{
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
uint32_t s, extents, area_multiple;
lvresize: fix stacked resize Commit b64703401da1f4bef60579a0b3766c087fcfe96a cause regression when handling stacked resize of pool metadata volume that would be a raid LV. Fix it by properly setting up size also for layer extension.
2016-03-16 01:13:28 +03:00
struct lv_segment *seg;
LV allocation variable renaming
2004-03-26 23:35:14 +03:00
Permit mimage LVs to be striped in lvcreate and lvresize.
2010-04-09 05:00:10 +04:00
area_multiple = _calc_area_multiple(segtype, area_count, 0);
style: lv_manip.c changes
2015-09-24 15:43:58 +03:00
extents = aa[0].len * area_multiple;
o Striped allocator o Changed pv_map.c to maintain the list of free areas in size order, which is more helpful to the allocators. If you want to allocate a bit of an area call consume_area(area, size), this will adjust the area if there's some space left and shuffle it to the correct place in the list. Not tested.
2001-11-29 21:45:35 +03:00
lvconvert: add infrastructure for RaidLV reshaping support In order to support striped raid5/6/10 LV reshaping (change of LV type, stripesize or number of legs), this patch introduces infrastructure prerequisites to be used by raid_manip.c extensions in followup patches. This base is needed for allocation of out-of-place reshape space required by the MD raid personalities to avoid writing over data in-place when reading off the current RAID layout or number of legs and writing out the new layout or to a different number of legs (i.e. restripe) Changes: - add members reshape_len to 'struct lv_segment' to store out-of-place reshape length per component rimage - add member data_copies to struct lv_segment to support more than 2 raid10 data copies - make alloc_lv_segment() aware of both reshape_len and data_copies - adjust all alloc_lv_segment() callers to the new API - add functions to retrieve the current data offset (needed for out-of-place reshaping space allocation) and the devices count from the kernel - make libdm deptree code aware of reshape_len - add LV flags for disk add/remove reshaping - support import/export of the new 'struct lv_segment' members - enhance lv_extend/_lv_reduce to cope with reshape_len - add seg_is_*/segtype_is_* macros related to reshaping - add target version check for reshaping - grow rebuilds/writemostly bitmaps to 246 bit to support kernel maximal - enhance libdm deptree code to support data_offset (out-of-place reshaping) and delta_disk (legs add/remove reshaping) target arguments Related: rhbz834579 Related: rhbz1191935 Related: rhbz1191978
2017-02-24 02:50:00 +03:00
if (!(seg = alloc_lv_segment(segtype, lv, lv->le_count, extents, 0,
thin: simplify thin volume creation Move code for creation of thin volume into a single place out of lv_extend(). This allows to drop extra pool arg for alloc_lv_segment() && lv_extend() and makes code more easier to read and follow.
2014-10-26 10:13:59 +03:00
status, stripe_size, NULL,
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
area_count,
lvconvert: add infrastructure for RaidLV reshaping support In order to support striped raid5/6/10 LV reshaping (change of LV type, stripesize or number of legs), this patch introduces infrastructure prerequisites to be used by raid_manip.c extensions in followup patches. This base is needed for allocation of out-of-place reshape space required by the MD raid personalities to avoid writing over data in-place when reading off the current RAID layout or number of legs and writing out the new layout or to a different number of legs (i.e. restripe) Changes: - add members reshape_len to 'struct lv_segment' to store out-of-place reshape length per component rimage - add member data_copies to struct lv_segment to support more than 2 raid10 data copies - make alloc_lv_segment() aware of both reshape_len and data_copies - adjust all alloc_lv_segment() callers to the new API - add functions to retrieve the current data offset (needed for out-of-place reshaping space allocation) and the devices count from the kernel - make libdm deptree code aware of reshape_len - add LV flags for disk add/remove reshaping - support import/export of the new 'struct lv_segment' members - enhance lv_extend/_lv_reduce to cope with reshape_len - add seg_is_*/segtype_is_* macros related to reshaping - add target version check for reshaping - grow rebuilds/writemostly bitmaps to 246 bit to support kernel maximal - enhance libdm deptree code to support data_offset (out-of-place reshaping) and delta_disk (legs add/remove reshaping) target arguments Related: rhbz834579 Related: rhbz1191935 Related: rhbz1191978
2017-02-24 02:50:00 +03:00
aa[0].len, 0, 0u, region_size, 0u, NULL))) {
Start merging cloned allocation functions.
2005-05-17 17:49:45 +04:00
log_error("Couldn't allocate new LV segment.");
o Striped allocator o Changed pv_map.c to maintain the list of free areas in size order, which is more helpful to the allocators. If you want to allocate a bit of an area call consume_area(area, size), this will adjust the area if there's some space left and shuffle it to the correct place in the list. Not tested.
2001-11-29 21:45:35 +03:00
return 0;
}
Use stack return macros throughout.
2008-01-30 16:19:47 +03:00
for (s = 0; s < area_count; s++)
if (!set_lv_segment_area_pv(seg, s, aa[s].pv, aa[s].pe))
return_0;
o Striped allocator o Changed pv_map.c to maintain the list of free areas in size order, which is more helpful to the allocators. If you want to allocate a bit of an area call consume_area(area, size), this will adjust the area if there's some space left and shuffle it to the correct place in the list. Not tested.
2001-11-29 21:45:35 +03:00
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
dm_list_add(&lv->segments, &seg->list);
Begin to separate out segment types.
2004-05-05 01:25:57 +04:00
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
extents = aa[0].len * area_multiple;
coverity: ensure thin_pool_seg is not NULL thin_pool_seg being NULL would be an internal error.
2016-02-23 23:36:51 +03:00
lvresize: fix stacked resize Commit b64703401da1f4bef60579a0b3766c087fcfe96a cause regression when handling stacked resize of pool metadata volume that would be a raid LV. Fix it by properly setting up size also for layer extension.
2016-03-16 01:13:28 +03:00
if (!_setup_lv_size(lv, lv->le_count + extents))
return_0;
cleanup: relocate size assign Directly set thin-pool size when thin data LV size changes.
2016-01-19 01:22:48 +03:00
o Striped allocator o Changed pv_map.c to maintain the list of free areas in size order, which is more helpful to the allocators. If you want to allocate a bit of an area call consume_area(area, size), this will adjust the area if there's some space left and shuffle it to the correct place in the list. Not tested.
2001-11-29 21:45:35 +03:00
return 1;
}
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
static int _setup_alloced_segments(struct logical_volume *lv,
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
struct dm_list *alloced_areas,
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
uint32_t area_count,
Switch status from 32-bit to 64-bit The physical_volume, volume_group, logical_volume and lv_segment structures' 'status' member is now uint64_t. The alignment of these structures was also audited to remove holes. The movement of some members in 'volume_group' and 'lv_segment' eliminates holes. The 'physical_volume' structure still has one 4-byte hole after 'pe_size'; the other structures no longer have any holes. Each structures' size has not changed.
2009-11-25 01:55:55 +03:00
uint64_t status,
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
uint32_t stripe_size,
Make SIZE_SHORT the default for display_size(). Fix some memory leaks in error paths found by coverity. Use C99 struct initialisers. Move DEFS into configure.h. Clean-ups to remove miscellaneous compiler warnings.
2006-05-10 01:23:51 +04:00
const struct segment_type *segtype,
Extend core allocation code in preparation for mirrored log areas.
2010-03-01 23:00:20 +03:00
uint32_t region_size)
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
{
struct alloced_area *aa;
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
dm_list_iterate_items(aa, &alloced_areas[0]) {
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
if (!_setup_alloced_segment(lv, status, area_count,
stripe_size, segtype, aa,
Extend core allocation code in preparation for mirrored log areas.
2010-03-01 23:00:20 +03:00
region_size))
Use stack return macros throughout.
2008-01-30 16:19:47 +03:00
return_0;
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
}
return 1;
}
/*
* This function takes a list of pv_areas and adds them to allocated_areas.
* If the complete area is not needed then it gets split.
* The part used is removed from the pv_map so it can't be allocated twice.
*/
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
static int _alloc_parallel_area(struct alloc_handle *ah, uint32_t max_to_allocate,
struct alloc_state *alloc_state, uint32_t ix_log_offset)
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
{
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
uint32_t area_len, len;
alloc: Refactor area reservation code. No functional changes intended to be included in this patch.
2014-04-10 23:48:59 +04:00
uint32_t s, smeta;
Extend core allocation code in preparation for mirrored log areas.
2010-03-01 23:00:20 +03:00
uint32_t ix_log_skip = 0; /* How many areas to skip in middle of array to reach log areas */
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
uint32_t total_area_count;
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
struct alloced_area *aa;
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
struct pv_area *pva;
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
allocation: Fix alloc anywhere with parity. Take account of parity areas with alloc anywhere in _calc_required_extents. Extents beyond area_count were treated incorrectly as mirror logs.
2014-05-14 19:25:43 +04:00
total_area_count = ah->area_count + ah->parity_count + alloc_state->log_area_count_still_needed;
Add some assertions to allocation code.
2010-03-25 21:16:54 +03:00
if (!total_area_count) {
cleanup: switch log_error to log_warn Use log_warn to print non-fatal warning messages. Use of log_error would confuse checker for testing whether proper error has been reported for some real error.
2012-10-16 12:14:41 +04:00
log_warn(INTERNAL_ERROR "_alloc_parallel_area called without any allocation to do.");
Add some assertions to allocation code.
2010-03-25 21:16:54 +03:00
return 1;
}
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
area_len = max_to_allocate / ah->area_multiple;
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
Fix detection of smallest area in _alloc_parallel_area() for cling policy.
2006-12-12 22:30:10 +03:00
/* Reduce area_len to the smallest of the areas */
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
for (s = 0; s < ah->area_count + ah->parity_count; s++)
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
if (area_len > alloc_state->areas[s].used)
area_len = alloc_state->areas[s].used;
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
allocation: misc fixes for percent/raid rounding Several fixes for the recent changes that treat allocation percentages as upper limits. Improve messages to make it easier to see what is happening. Fix some cases that failed with errors when they didn't need to. Fix crashes when first_seg() returns NULL. Remove a couple of log_errors that were actually debugging messages.
2014-02-22 04:26:01 +04:00
len = (ah->alloc_and_split_meta && !ah->split_metadata_is_allocated) ? total_area_count * 2 : total_area_count;
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
len *= sizeof(*aa);
if (!(aa = dm_pool_alloc(ah->mem, len))) {
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
log_error("alloced_area allocation failed");
return 0;
}
Extend core allocation code in preparation for mirrored log areas.
2010-03-01 23:00:20 +03:00
/*
* Areas consists of area_count areas for data stripes, then
* ix_log_skip areas to skip, then log_area_count areas to use for the
* log, then some areas too small for the log.
*/
len = area_len;
for (s = 0; s < total_area_count; s++) {
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
if (s == (ah->area_count + ah->parity_count)) {
Extend core allocation code in preparation for mirrored log areas.
2010-03-01 23:00:20 +03:00
ix_log_skip = ix_log_offset - ah->area_count;
len = ah->log_len;
}
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
pva = alloc_state->areas[s + ix_log_skip].pva;
allocation: misc fixes for percent/raid rounding Several fixes for the recent changes that treat allocation percentages as upper limits. Improve messages to make it easier to see what is happening. Fix some cases that failed with errors when they didn't need to. Fix crashes when first_seg() returns NULL. Remove a couple of log_errors that were actually debugging messages.
2014-02-22 04:26:01 +04:00
if (ah->alloc_and_split_meta && !ah->split_metadata_is_allocated) {
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
/*
* The metadata area goes at the front of the allocated
* space for now, but could easily go at the end (or
* middle!).
*
* Even though we split these two from the same
* allocation, we store the images at the beginning
* of the areas array and the metadata at the end.
*/
alloc: Refactor area reservation code. No functional changes intended to be included in this patch.
2014-04-10 23:48:59 +04:00
smeta = s + ah->area_count + ah->parity_count;
aa[smeta].pv = pva->map->pv;
aa[smeta].pe = pva->start;
aa[smeta].len = ah->log_len;
allocation: report allocation error instead of crash Current allocation limitation requires to fit metadata/log LV on a single PV. This is usually not a big problem, but since thin-pool and cache-pool is using this for allocating extents for their metadata LVs it might be eventually causing errors where the remaining free spaces for large metadata size is spread over several PV.
2021-02-01 12:24:19 +03:00
if (aa[smeta].len > pva->count) {
log_error("Metadata does not fit on a single PV.");
return 0;
}
logging: classify log_debug messages Place most log_debug() messages into a class.
2013-01-08 02:30:29 +04:00
log_debug_alloc("Allocating parallel metadata area %" PRIu32
" on %s start PE %" PRIu32
" length %" PRIu32 ".",
alloc: Refactor area reservation code. No functional changes intended to be included in this patch.
2014-04-10 23:48:59 +04:00
(smeta - (ah->area_count + ah->parity_count)),
pv_dev_name(aa[smeta].pv), aa[smeta].pe,
allocation: report allocation error instead of crash Current allocation limitation requires to fit metadata/log LV on a single PV. This is usually not a big problem, but since thin-pool and cache-pool is using this for allocating extents for their metadata LVs it might be eventually causing errors where the remaining free spaces for large metadata size is spread over several PV.
2021-02-01 12:24:19 +03:00
aa[smeta].len);
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
allocation: report allocation error instead of crash Current allocation limitation requires to fit metadata/log LV on a single PV. This is usually not a big problem, but since thin-pool and cache-pool is using this for allocating extents for their metadata LVs it might be eventually causing errors where the remaining free spaces for large metadata size is spread over several PV.
2021-02-01 12:24:19 +03:00
consume_pv_area(pva, aa[smeta].len);
alloc: Refactor area reservation code. No functional changes intended to be included in this patch.
2014-04-10 23:48:59 +04:00
dm_list_add(&ah->alloced_areas[smeta], &aa[smeta].list);
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
}
allocation: misc fixes for percent/raid rounding Several fixes for the recent changes that treat allocation percentages as upper limits. Improve messages to make it easier to see what is happening. Fix some cases that failed with errors when they didn't need to. Fix crashes when first_seg() returns NULL. Remove a couple of log_errors that were actually debugging messages.
2014-02-22 04:26:01 +04:00
aa[s].len = (ah->alloc_and_split_meta && !ah->split_metadata_is_allocated) ? len - ah->log_len : len;
alloc: fix raid --alloc anywhere double allocs If _alloc_parallel_area for raid devices chooses an area already used up, it doesn't notice that it has no space left in it and leaves later code trying to place a zero-length area into the LV. https://bugzilla.redhat.com/832596
2012-06-29 02:26:42 +04:00
/* Skip empty allocations */
if (!aa[s].len)
continue;
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
aa[s].pv = pva->map->pv;
aa[s].pe = pva->start;
Always insert an intermediate layer for mirrors. Suppress hidden LVs from reports unless --all is given. Use square brackets for hidden LVs in reports. Centralise restrictions on LV names.
2005-06-03 18:49:51 +04:00
logging: classify log_debug messages Place most log_debug() messages into a class.
2013-01-08 02:30:29 +04:00
log_debug_alloc("Allocating parallel area %" PRIu32
" on %s start PE %" PRIu32 " length %" PRIu32 ".",
s, pv_dev_name(aa[s].pv), aa[s].pe, aa[s].len);
Introduce pv_area_used into allocation algorithm and add debug messages. This is the next preparatory step towards better --alloc anywhere support and is not intended to break anything that currently works so please report any problems - segfaults, bogus data in the new debug messages, or if the code now chooses bizarre allocation layouts.
2010-03-25 05:31:48 +03:00
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
consume_pv_area(pva, aa[s].len);
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
Extend core allocation code in preparation for mirrored log areas.
2010-03-01 23:00:20 +03:00
dm_list_add(&ah->alloced_areas[s], &aa[s].list);
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
}
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
/* Only need to alloc metadata from the first batch */
allocation: misc fixes for percent/raid rounding Several fixes for the recent changes that treat allocation percentages as upper limits. Improve messages to make it easier to see what is happening. Fix some cases that failed with errors when they didn't need to. Fix crashes when first_seg() returns NULL. Remove a couple of log_errors that were actually debugging messages.
2014-02-22 04:26:01 +04:00
if (ah->alloc_and_split_meta)
ah->split_metadata_is_allocated = 1;
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
Extend core allocation code in preparation for mirrored log areas.
2010-03-01 23:00:20 +03:00
ah->total_area_len += area_len;
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
alloc_state->allocated += area_len * ah->area_multiple;
Permit mimage LVs to be striped in lvcreate and lvresize.
2010-04-09 05:00:10 +04:00
return 1;
}
move _for_each_pv()
2006-10-07 15:23:22 +04:00
/*
* Call fn for each AREA_PV used by the LV segment at lv:le of length *max_seg_len.
* If any constituent area contains more than one segment, max_seg_len is
* reduced to cover only the first.
Extend _for_each_pv() to allow termination without error.
2006-10-07 16:41:06 +04:00
* fn should return 0 on error, 1 to continue scanning or >1 to terminate without error.
* In the last case, this function passes on the return code.
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
* FIXME I think some callers are expecting this to check all PV segments used by an LV.
move _for_each_pv()
2006-10-07 15:23:22 +04:00
*/
static int _for_each_pv(struct cmd_context *cmd, struct logical_volume *lv,
Fix pvmove allocation to take existing parallel stripes into account. When moving parts of striped LVs, pvmove wouldn't care about leaving you with two stripes on the same disk. Now --alloc anywhere is needed for that. (Tried and gave up on two alternative approaches before the one committed here.)
2010-04-08 04:28:57 +04:00
uint32_t le, uint32_t len, struct lv_segment *seg,
uint32_t *max_seg_len,
check_contiguous to use for_each_pv
2006-10-08 03:40:36 +04:00
uint32_t first_area, uint32_t max_areas,
int top_level_area_index,
int only_single_area_segments,
int (*fn)(struct cmd_context *cmd,
struct pv_segment *peg, uint32_t s,
void *data),
move _for_each_pv()
2006-10-07 15:23:22 +04:00
void *data)
{
uint32_t s;
uint32_t remaining_seg_len, area_len, area_multiple;
Permit mimage LVs to be striped in lvcreate and lvresize.
2010-04-09 05:00:10 +04:00
uint32_t stripes_per_mimage = 1;
more refactoring
2006-10-07 20:00:28 +04:00
int r = 1;
move _for_each_pv()
2006-10-07 15:23:22 +04:00
Fix pvmove allocation to take existing parallel stripes into account. When moving parts of striped LVs, pvmove wouldn't care about leaving you with two stripes on the same disk. Now --alloc anywhere is needed for that. (Tried and gave up on two alternative approaches before the one committed here.)
2010-04-08 04:28:57 +04:00
if (!seg && !(seg = find_seg_by_le(lv, le))) {
move _for_each_pv()
2006-10-07 15:23:22 +04:00
log_error("Failed to find segment for %s extent %" PRIu32,
lv->name, le);
return 0;
}
/* Remaining logical length of segment */
remaining_seg_len = seg->len - (le - seg->le);
if (remaining_seg_len > len)
remaining_seg_len = len;
if (max_seg_len && *max_seg_len > remaining_seg_len)
*max_seg_len = remaining_seg_len;
Permit mimage LVs to be striped in lvcreate and lvresize.
2010-04-09 05:00:10 +04:00
area_multiple = _calc_area_multiple(seg->segtype, seg->area_count, 0);
alloc: fix update or area_len Commit: 192d9ad97769f2c16f3ebe67e51cfb287e67f67c changed logic for area_len formula - so it returns different values. Placing () to restore previous behaviour and make it explicit.
2015-10-01 15:59:21 +03:00
area_len = (remaining_seg_len / area_multiple) ? : 1;
move _for_each_pv()
2006-10-07 15:23:22 +04:00
Permit mimage LVs to be striped in lvcreate and lvresize.
2010-04-09 05:00:10 +04:00
/* For striped mirrors, all the areas are counted, through the mirror layer */
if (top_level_area_index == -1)
stripes_per_mimage = _stripes_per_mimage(seg);
check_contiguous to use for_each_pv
2006-10-08 03:40:36 +04:00
for (s = first_area;
s < seg->area_count && (!max_areas || s <= max_areas);
s++) {
move _for_each_pv()
2006-10-07 15:23:22 +04:00
if (seg_type(seg, s) == AREA_LV) {
Extend _for_each_pv() to allow termination without error.
2006-10-07 16:41:06 +04:00
if (!(r = _for_each_pv(cmd, seg_lv(seg, s),
seg_le(seg, s) +
(le - seg->le) / area_multiple,
Permit mimage LVs to be striped in lvcreate and lvresize.
2010-04-09 05:00:10 +04:00
area_len, NULL, max_seg_len, 0,
(stripes_per_mimage == 1) && only_single_area_segments ? 1U : 0U,
Fix some unmatching sign comparation gcc warnings Simple replacement for unsigned type - usually in for() loops.
2011-04-08 18:40:18 +04:00
(top_level_area_index != -1) ? top_level_area_index : (int) (s * stripes_per_mimage),
check_contiguous to use for_each_pv
2006-10-08 03:40:36 +04:00
only_single_area_segments, fn,
Extend _for_each_pv() to allow termination without error.
2006-10-07 16:41:06 +04:00
data)))
stack;
} else if (seg_type(seg, s) == AREA_PV)
Permit mimage LVs to be striped in lvcreate and lvresize.
2010-04-09 05:00:10 +04:00
if (!(r = fn(cmd, seg_pvseg(seg, s), top_level_area_index != -1 ? (uint32_t) top_level_area_index + s : s, data)))
Extend _for_each_pv() to allow termination without error.
2006-10-07 16:41:06 +04:00
stack;
if (r != 1)
return r;
}
check_contiguous to use for_each_pv
2006-10-08 03:40:36 +04:00
/* FIXME only_single_area_segments used as workaround to skip log LV - needs new param? */
if (!only_single_area_segments && seg_is_mirrored(seg) && seg->log_lv) {
Fix pvmove allocation to take existing parallel stripes into account. When moving parts of striped LVs, pvmove wouldn't care about leaving you with two stripes on the same disk. Now --alloc anywhere is needed for that. (Tried and gave up on two alternative approaches before the one committed here.)
2010-04-08 04:28:57 +04:00
if (!(r = _for_each_pv(cmd, seg->log_lv, 0, seg->log_lv->le_count, NULL,
check_contiguous to use for_each_pv
2006-10-08 03:40:36 +04:00
NULL, 0, 0, 0, only_single_area_segments,
fn, data)))
Extend _for_each_pv() to allow termination without error.
2006-10-07 16:41:06 +04:00
stack;
if (r != 1)
return r;
}
move _for_each_pv()
2006-10-07 15:23:22 +04:00
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
/* FIXME Add snapshot cow, thin meta etc. */
/*
if (!only_single_area_segments && !max_areas && seg_is_raid(seg)) {
for (s = first_area; s < seg->area_count; s++) {
if (seg_metalv(seg, s))
if (!(r = _for_each_pv(cmd, seg_metalv(seg, s), 0, seg_metalv(seg, s)->le_count, NULL,
NULL, 0, 0, 0, 0, fn, data)))
stack;
if (r != 1)
return r;
}
}
*/
move _for_each_pv()
2006-10-07 15:23:22 +04:00
return 1;
}
o Striped allocator o Changed pv_map.c to maintain the list of free areas in size order, which is more helpful to the allocators. If you want to allocate a bit of an area call consume_area(area, size), this will adjust the area if there's some space left and shuffle it to the correct place in the list. Not tested.
2001-11-29 21:45:35 +03:00
static int _comp_area(const void *l, const void *r)
{
Attempt to fix non-ALLOC_ANYWHERE allocation code after recent changes broke The preference given to the PVs with the largest free areas.
2010-04-01 00:26:04 +04:00
const struct pv_area_used *lhs = (const struct pv_area_used *) l;
const struct pv_area_used *rhs = (const struct pv_area_used *) r;
o Striped allocator o Changed pv_map.c to maintain the list of free areas in size order, which is more helpful to the allocators. If you want to allocate a bit of an area call consume_area(area, size), this will adjust the area if there's some space left and shuffle it to the correct place in the list. Not tested.
2001-11-29 21:45:35 +03:00
Introduce pv_area_used into allocation algorithm and add debug messages. This is the next preparatory step towards better --alloc anywhere support and is not intended to break anything that currently works so please report any problems - segfaults, bogus data in the new debug messages, or if the code now chooses bizarre allocation layouts.
2010-03-25 05:31:48 +03:00
if (lhs->used < rhs->used)
o Comparison function was sorting things in ascending rather than descending order. o free off the sort array when finished with it.
2001-11-30 12:19:46 +03:00
return 1;
o Striped allocator o Changed pv_map.c to maintain the list of free areas in size order, which is more helpful to the allocators. If you want to allocate a bit of an area call consume_area(area, size), this will adjust the area if there's some space left and shuffle it to the correct place in the list. Not tested.
2001-11-29 21:45:35 +03:00
tidy: prefer not using else after return clang-tidy: avoid using 'else' after return - give more readable code, and also saves indention level.
2017-07-19 17:16:12 +03:00
if (lhs->used > rhs->used)
o Comparison function was sorting things in ascending rather than descending order. o free off the sort array when finished with it.
2001-11-30 12:19:46 +03:00
return -1;
o Striped allocator o Changed pv_map.c to maintain the list of free areas in size order, which is more helpful to the allocators. If you want to allocate a bit of an area call consume_area(area, size), this will adjust the area if there's some space left and shuffle it to the correct place in the list. Not tested.
2001-11-29 21:45:35 +03:00
return 0;
}
check_contiguous to use for_each_pv
2006-10-08 03:40:36 +04:00
/*
* Search for pvseg that matches condition
*/
struct pv_match {
Extend cling allocation policy to recognise PV tags (cling_by_tags). Add allocation/cling_tag_list to lvm.conf.
2010-11-09 15:34:40 +03:00
int (*condition)(struct pv_match *pvmatch, struct pv_segment *pvseg, struct pv_area *pva);
check_contiguous to use for_each_pv
2006-10-08 03:40:36 +04:00
alloc: Pass alloc_handle through to _reserve_area.
2015-03-26 23:32:59 +03:00
struct alloc_handle *ah;
alloc: Refactor area reservation code. No functional changes intended to be included in this patch.
2014-04-10 23:48:59 +04:00
struct alloc_state *alloc_state;
check_contiguous to use for_each_pv
2006-10-08 03:40:36 +04:00
struct pv_area *pva;
Move the core of the lib/config/config.c functionality into libdevmapper, leaving behind the LVM-specific parts of the code (convenience wrappers that handle `struct device` and `struct cmd_context`, basically). A number of functions have been renamed (in addition to getting a dm_ prefix) -- namely, all of the config interface now has a dm_config_ prefix.
2011-08-30 18:55:15 +04:00
const struct dm_config_node *cling_tag_list_cn;
check_contiguous to use for_each_pv
2006-10-08 03:40:36 +04:00
int s; /* Area index of match */
};
add cling allocation policy
2006-10-08 16:01:13 +04:00
/*
* Is PV area on the same PV?
*/
Extend cling allocation policy to recognise PV tags (cling_by_tags). Add allocation/cling_tag_list to lvm.conf.
2010-11-09 15:34:40 +03:00
static int _is_same_pv(struct pv_match *pvmatch __attribute((unused)), struct pv_segment *pvseg, struct pv_area *pva)
add cling allocation policy
2006-10-08 16:01:13 +04:00
{
if (pvseg->pv != pva->map->pv)
return 0;
return 1;
}
Extend cling allocation policy to recognise PV tags (cling_by_tags). Add allocation/cling_tag_list to lvm.conf.
2010-11-09 15:34:40 +03:00
/*
cleanup: spaces
2016-01-11 16:11:37 +03:00
* Does PV area have a tag listed in allocation/cling_tag_list that
alloc: Add A_PARTITION_BY_TAGS to avoid sharing. Add A_PARTITION_BY_TAGS set when allocated areas should not share tags with each other and allow _match_pv_tags to accept an alternative list of tags. (Not used yet.)
2015-04-10 23:57:52 +03:00
* matches EITHER a tag of the PV of the existing segment OR a tag in pv_tags?
alloc: Record PV tags of parallel PVs in log.
2016-08-24 17:49:34 +03:00
* If mem is set, then instead we append a list of matching tags for printing to the object there.
Extend cling allocation policy to recognise PV tags (cling_by_tags). Add allocation/cling_tag_list to lvm.conf.
2010-11-09 15:34:40 +03:00
*/
alloc: Only report cling tag errors once.
2015-03-26 22:43:51 +03:00
static int _match_pv_tags(const struct dm_config_node *cling_tag_list_cn,
alloc: Add A_PARTITION_BY_TAGS to avoid sharing. Add A_PARTITION_BY_TAGS set when allocated areas should not share tags with each other and allow _match_pv_tags to accept an alternative list of tags. (Not used yet.)
2015-04-10 23:57:52 +03:00
struct physical_volume *pv1, uint32_t pv1_start_pe, uint32_t area_num,
struct physical_volume *pv2, struct dm_list *pv_tags, unsigned validate_only,
alloc: Avoid PV tags too when avoiding parallel PV allocation. Also add debug messages for parallel PVs.
2016-08-24 21:37:50 +03:00
struct dm_pool *mem, unsigned parallel_pv)
Extend cling allocation policy to recognise PV tags (cling_by_tags). Add allocation/cling_tag_list to lvm.conf.
2010-11-09 15:34:40 +03:00
{
Move the core of the lib/config/config.c functionality into libdevmapper, leaving behind the LVM-specific parts of the code (convenience wrappers that handle `struct device` and `struct cmd_context`, basically). A number of functions have been renamed (in addition to getting a dm_ prefix) -- namely, all of the config interface now has a dm_config_ prefix.
2011-08-30 18:55:15 +04:00
const struct dm_config_value *cv;
Add more strict const pointers around config tree To have better control were the config tree could be modified use more const pointers and very carefully downcast them back to non-const (for config tree merge).
2010-12-20 16:12:55 +03:00
const char *str;
Preserve const for char pointer Keep char pointers 'const' (introduced with cling commit).
2010-11-11 15:32:33 +03:00
const char *tag_matched;
cov: check pointer before dereferencing Check pv2 is non-null before trying to deref its tags.
2021-10-15 15:48:48 +03:00
struct dm_list *tags_to_match = mem ? NULL : pv_tags ? : ((pv2) ? &pv2->tags : NULL);
alloc: Log PV tags when reserving areas.
2015-03-27 00:13:26 +03:00
struct dm_str_list *sl;
unsigned first_tag = 1;
Refactor _has_matching_pv_tag to provide a fn that takes PV structs.
2012-05-11 19:26:30 +04:00
for (cv = cling_tag_list_cn->v; cv; cv = cv->next) {
Move the core of the lib/config/config.c functionality into libdevmapper, leaving behind the LVM-specific parts of the code (convenience wrappers that handle `struct device` and `struct cmd_context`, basically). A number of functions have been renamed (in addition to getting a dm_ prefix) -- namely, all of the config interface now has a dm_config_ prefix.
2011-08-30 18:55:15 +04:00
if (cv->type != DM_CFG_STRING) {
alloc: Only report cling tag errors once.
2015-03-26 22:43:51 +03:00
if (validate_only)
log_warn("WARNING: Ignoring invalid string in config file entry "
"allocation/cling_tag_list");
Extend cling allocation policy to recognise PV tags (cling_by_tags). Add allocation/cling_tag_list to lvm.conf.
2010-11-09 15:34:40 +03:00
continue;
}
str = cv->v.str;
if (!*str) {
alloc: Only report cling tag errors once.
2015-03-26 22:43:51 +03:00
if (validate_only)
log_warn("WARNING: Ignoring empty string in config file entry "
"allocation/cling_tag_list");
Extend cling allocation policy to recognise PV tags (cling_by_tags). Add allocation/cling_tag_list to lvm.conf.
2010-11-09 15:34:40 +03:00
continue;
}
if (*str != '@') {
alloc: Only report cling tag errors once.
2015-03-26 22:43:51 +03:00
if (validate_only)
log_warn("WARNING: Ignoring string not starting with @ in config file entry "
"allocation/cling_tag_list: %s", str);
Extend cling allocation policy to recognise PV tags (cling_by_tags). Add allocation/cling_tag_list to lvm.conf.
2010-11-09 15:34:40 +03:00
continue;
}
str++;
if (!*str) {
alloc: Only report cling tag errors once.
2015-03-26 22:43:51 +03:00
if (validate_only)
log_warn("WARNING: Ignoring empty tag in config file entry "
"allocation/cling_tag_list");
Extend cling allocation policy to recognise PV tags (cling_by_tags). Add allocation/cling_tag_list to lvm.conf.
2010-11-09 15:34:40 +03:00
continue;
}
alloc: Only report cling tag errors once.
2015-03-26 22:43:51 +03:00
if (validate_only)
continue;
Extend cling allocation policy to recognise PV tags (cling_by_tags). Add allocation/cling_tag_list to lvm.conf.
2010-11-09 15:34:40 +03:00
/* Wildcard matches any tag against any tag. */
if (!strcmp(str, "*")) {
alloc: Record PV tags of parallel PVs in log.
2016-08-24 17:49:34 +03:00
if (mem) {
alloc: Log PV tags when reserving areas.
2015-03-27 00:13:26 +03:00
dm_list_iterate_items(sl, &pv1->tags) {
if (!first_tag && !dm_pool_grow_object(mem, ",", 0)) {
log_error("PV tags string extension failed.");
return 0;
}
first_tag = 0;
if (!dm_pool_grow_object(mem, sl->str, 0)) {
log_error("PV tags string extension failed.");
return 0;
}
}
continue;
}
tidy: else after continue Similar as with 'else' after 'return' unindent whole block for better readability of code.
2017-07-20 00:12:48 +03:00
cov: check pointer before dereferencing Check pv2 is non-null before trying to deref its tags.
2021-10-15 15:48:48 +03:00
if (tags_to_match && !str_list_match_list(&pv1->tags, tags_to_match, &tag_matched))
Extend cling allocation policy to recognise PV tags (cling_by_tags). Add allocation/cling_tag_list to lvm.conf.
2010-11-09 15:34:40 +03:00
continue;
alloc: Avoid PV tags too when avoiding parallel PV allocation. Also add debug messages for parallel PVs.
2016-08-24 21:37:50 +03:00
if (!pv_tags) {
if (parallel_pv)
log_debug_alloc("Not using free space on %s: Matched allocation PV tag %s on existing parallel PV %s.",
tidy: else after continue Similar as with 'else' after 'return' unindent whole block for better readability of code.
2017-07-20 00:12:48 +03:00
pv_dev_name(pv1), tag_matched, pv2 ? pv_dev_name(pv2) : "-");
alloc: Avoid PV tags too when avoiding parallel PV allocation. Also add debug messages for parallel PVs.
2016-08-24 21:37:50 +03:00
else
log_debug_alloc("Matched allocation PV tag %s on existing %s with free space on %s.",
tidy: else after continue Similar as with 'else' after 'return' unindent whole block for better readability of code.
2017-07-20 00:12:48 +03:00
tag_matched, pv_dev_name(pv1), pv2 ? pv_dev_name(pv2) : "-");
alloc: Avoid PV tags too when avoiding parallel PV allocation. Also add debug messages for parallel PVs.
2016-08-24 21:37:50 +03:00
} else
alloc: Add A_PARTITION_BY_TAGS to avoid sharing. Add A_PARTITION_BY_TAGS set when allocated areas should not share tags with each other and allow _match_pv_tags to accept an alternative list of tags. (Not used yet.)
2015-04-10 23:57:52 +03:00
log_debug_alloc("Eliminating allocation area %" PRIu32 " at PV %s start PE %" PRIu32
" from consideration: PV tag %s already used.",
tidy: else after continue Similar as with 'else' after 'return' unindent whole block for better readability of code.
2017-07-20 00:12:48 +03:00
area_num, pv_dev_name(pv1), pv1_start_pe, tag_matched);
Extend cling allocation policy to recognise PV tags (cling_by_tags). Add allocation/cling_tag_list to lvm.conf.
2010-11-09 15:34:40 +03:00
return 1;
}
tidy: else after continue Similar as with 'else' after 'return' unindent whole block for better readability of code.
2017-07-20 00:12:48 +03:00
if (!str_list_match_item(&pv1->tags, str) ||
(tags_to_match && !str_list_match_item(tags_to_match, str)))
continue;
if (mem) {
if (!first_tag && !dm_pool_grow_object(mem, ",", 0)) {
log_error("PV tags string extension failed.");
return 0;
}
first_tag = 0;
if (!dm_pool_grow_object(mem, str, 0)) {
log_error("PV tags string extension failed.");
return 0;
}
continue;
}
if (!pv_tags) {
if (parallel_pv)
log_debug_alloc("Not using free space on %s: Matched allocation PV tag %s on existing parallel PV %s.",
pv2 ? pv_dev_name(pv2) : "-", str, pv_dev_name(pv1));
else
log_debug_alloc("Matched allocation PV tag %s on existing %s with free space on %s.",
str, pv_dev_name(pv1), pv2 ? pv_dev_name(pv2) : "-");
} else
log_debug_alloc("Eliminating allocation area %" PRIu32 " at PV %s start PE %" PRIu32
" from consideration: PV tag %s already used.",
area_num, pv_dev_name(pv1), pv1_start_pe, str);
return 1;
Extend cling allocation policy to recognise PV tags (cling_by_tags). Add allocation/cling_tag_list to lvm.conf.
2010-11-09 15:34:40 +03:00
}
alloc: Record PV tags of parallel PVs in log.
2016-08-24 17:49:34 +03:00
if (mem)
alloc: Log PV tags when reserving areas.
2015-03-27 00:13:26 +03:00
return 1;
Extend cling allocation policy to recognise PV tags (cling_by_tags). Add allocation/cling_tag_list to lvm.conf.
2010-11-09 15:34:40 +03:00
return 0;
}
alloc: Only report cling tag errors once.
2015-03-26 22:43:51 +03:00
static int _validate_tag_list(const struct dm_config_node *cling_tag_list_cn)
{
alloc: Avoid PV tags too when avoiding parallel PV allocation. Also add debug messages for parallel PVs.
2016-08-24 21:37:50 +03:00
return _match_pv_tags(cling_tag_list_cn, NULL, 0, 0, NULL, NULL, 1, NULL, 0);
alloc: Log PV tags when reserving areas.
2015-03-27 00:13:26 +03:00
}
alloc: Record PV tags of parallel PVs in log.
2016-08-24 17:49:34 +03:00
static int _tags_list_str(struct dm_pool *mem, struct physical_volume *pv1, const struct dm_config_node *cling_tag_list_cn)
alloc: Log PV tags when reserving areas.
2015-03-27 00:13:26 +03:00
{
alloc: Avoid PV tags too when avoiding parallel PV allocation. Also add debug messages for parallel PVs.
2016-08-24 21:37:50 +03:00
if (!_match_pv_tags(cling_tag_list_cn, pv1, 0, 0, NULL, NULL, 0, mem, 0)) {
alloc: Record PV tags of parallel PVs in log.
2016-08-24 17:49:34 +03:00
dm_pool_abandon_object(mem);
return_0;
}
alloc: Log PV tags when reserving areas.
2015-03-27 00:13:26 +03:00
alloc: Record PV tags of parallel PVs in log.
2016-08-24 17:49:34 +03:00
return 1;
alloc: Only report cling tag errors once.
2015-03-26 22:43:51 +03:00
}
alloc: Respect cling_tag_list in contig alloc. When performing initial allocation (so there is nothing yet to cling to), use the list of tags in allocation/cling_tag_list to partition the PVs. We implement this by maintaining a list of tags that have been "used up" as we proceed and ignoring further devices that have a tag on the list. https://bugzilla.redhat.com/983600
2015-04-11 03:55:24 +03:00
/*
* Does PV area have a tag listed in allocation/cling_tag_list that
* matches a tag in the pv_tags list?
*/
static int _pv_has_matching_tag(const struct dm_config_node *cling_tag_list_cn,
struct physical_volume *pv1, uint32_t pv1_start_pe, uint32_t area_num,
struct dm_list *pv_tags)
{
alloc: Avoid PV tags too when avoiding parallel PV allocation. Also add debug messages for parallel PVs.
2016-08-24 21:37:50 +03:00
return _match_pv_tags(cling_tag_list_cn, pv1, pv1_start_pe, area_num, NULL, pv_tags, 0, NULL, 0);
alloc: Respect cling_tag_list in contig alloc. When performing initial allocation (so there is nothing yet to cling to), use the list of tags in allocation/cling_tag_list to partition the PVs. We implement this by maintaining a list of tags that have been "used up" as we proceed and ignoring further devices that have a tag on the list. https://bugzilla.redhat.com/983600
2015-04-11 03:55:24 +03:00
}
alloc: Only report cling tag errors once.
2015-03-26 22:43:51 +03:00
/*
cleanup: spaces
2016-01-11 16:11:37 +03:00
* Does PV area have a tag listed in allocation/cling_tag_list that
alloc: Only report cling tag errors once.
2015-03-26 22:43:51 +03:00
* matches a tag of the PV of the existing segment?
*/
static int _pvs_have_matching_tag(const struct dm_config_node *cling_tag_list_cn,
alloc: Avoid PV tags too when avoiding parallel PV allocation. Also add debug messages for parallel PVs.
2016-08-24 21:37:50 +03:00
struct physical_volume *pv1, struct physical_volume *pv2,
unsigned parallel_pv)
alloc: Only report cling tag errors once.
2015-03-26 22:43:51 +03:00
{
alloc: Avoid PV tags too when avoiding parallel PV allocation. Also add debug messages for parallel PVs.
2016-08-24 21:37:50 +03:00
return _match_pv_tags(cling_tag_list_cn, pv1, 0, 0, pv2, NULL, 0, NULL, parallel_pv);
alloc: Only report cling tag errors once.
2015-03-26 22:43:51 +03:00
}
Refactor _has_matching_pv_tag to provide a fn that takes PV structs.
2012-05-11 19:26:30 +04:00
static int _has_matching_pv_tag(struct pv_match *pvmatch, struct pv_segment *pvseg, struct pv_area *pva)
{
alloc: Avoid PV tags too when avoiding parallel PV allocation. Also add debug messages for parallel PVs.
2016-08-24 21:37:50 +03:00
return _pvs_have_matching_tag(pvmatch->cling_tag_list_cn, pvseg->pv, pva->map->pv, 0);
Refactor _has_matching_pv_tag to provide a fn that takes PV structs.
2012-05-11 19:26:30 +04:00
}
alloc: Record PV tags of parallel PVs in log.
2016-08-24 17:49:34 +03:00
static int _log_parallel_areas(struct dm_pool *mem, struct dm_list *parallel_areas,
const struct dm_config_node *cling_tag_list_cn)
alloc: Move _log_parallel_areas.
2016-08-24 17:39:56 +03:00
{
struct seg_pvs *spvs;
struct pv_list *pvl;
char *pvnames;
alloc: Record PV tags of parallel PVs in log.
2016-08-24 17:49:34 +03:00
unsigned first;
alloc: Move _log_parallel_areas.
2016-08-24 17:39:56 +03:00
if (!parallel_areas)
return 1;
dm_list_iterate_items(spvs, parallel_areas) {
alloc: Record PV tags of parallel PVs in log.
2016-08-24 17:49:34 +03:00
first = 1;
alloc: Move _log_parallel_areas.
2016-08-24 17:39:56 +03:00
if (!dm_pool_begin_object(mem, 256)) {
log_error("dm_pool_begin_object failed");
return 0;
}
dm_list_iterate_items(pvl, &spvs->pvs) {
alloc: Record PV tags of parallel PVs in log.
2016-08-24 17:49:34 +03:00
if (!first && !dm_pool_grow_object(mem, " ", 1)) {
alloc: Move _log_parallel_areas.
2016-08-24 17:39:56 +03:00
log_error("dm_pool_grow_object failed");
dm_pool_abandon_object(mem);
return 0;
}
alloc: Record PV tags of parallel PVs in log.
2016-08-24 17:49:34 +03:00
if (!dm_pool_grow_object(mem, pv_dev_name(pvl->pv), strlen(pv_dev_name(pvl->pv)))) {
alloc: Move _log_parallel_areas.
2016-08-24 17:39:56 +03:00
log_error("dm_pool_grow_object failed");
dm_pool_abandon_object(mem);
return 0;
}
alloc: Record PV tags of parallel PVs in log.
2016-08-24 17:49:34 +03:00
if (cling_tag_list_cn) {
if (!dm_pool_grow_object(mem, "(", 1)) {
log_error("dm_pool_grow_object failed");
dm_pool_abandon_object(mem);
return 0;
}
if (!_tags_list_str(mem, pvl->pv, cling_tag_list_cn)) {
dm_pool_abandon_object(mem);
return_0;
}
if (!dm_pool_grow_object(mem, ")", 1)) {
log_error("dm_pool_grow_object failed");
dm_pool_abandon_object(mem);
return 0;
}
}
first = 0;
alloc: Move _log_parallel_areas.
2016-08-24 17:39:56 +03:00
}
if (!dm_pool_grow_object(mem, "\0", 1)) {
log_error("dm_pool_grow_object failed");
dm_pool_abandon_object(mem);
return 0;
}
pvnames = dm_pool_end_object(mem);
log_debug_alloc("Parallel PVs at LE %" PRIu32 " length %" PRIu32 ": %s",
spvs->le, spvs->len, pvnames);
dm_pool_free(mem, pvnames);
}
return 1;
}
abstract _is_contiguous()
2006-10-07 15:34:53 +04:00
/*
* Is PV area contiguous to PV segment?
*/
Extend cling allocation policy to recognise PV tags (cling_by_tags). Add allocation/cling_tag_list to lvm.conf.
2010-11-09 15:34:40 +03:00
static int _is_contiguous(struct pv_match *pvmatch __attribute((unused)), struct pv_segment *pvseg, struct pv_area *pva)
abstract _is_contiguous()
2006-10-07 15:34:53 +04:00
{
if (pvseg->pv != pva->map->pv)
return 0;
if (pvseg->pe + pvseg->len != pva->start)
return 0;
return 1;
}
lv_manip: add error handling for _reserve_area Since _reserve_area() may fail due to error allocation failure, add support to report this already reported failure upward. FIXME: it's log_error() without causing direct command failure.
2020-01-30 17:23:47 +03:00
static int _reserve_area(struct alloc_handle *ah, struct alloc_state *alloc_state, struct pv_area *pva,
alloc: Pass alloc_handle through to _reserve_area.
2015-03-26 23:32:59 +03:00
uint32_t required, uint32_t ix_pva, uint32_t unreserved)
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
{
alloc: Refactor area reservation code. No functional changes intended to be included in this patch.
2014-04-10 23:48:59 +04:00
struct pv_area_used *area_used = &alloc_state->areas[ix_pva];
alloc: Log PV tags when reserving areas.
2015-03-27 00:13:26 +03:00
const char *pv_tag_list = NULL;
alloc: Record PV tags of parallel PVs in log.
2016-08-24 17:49:34 +03:00
if (ah->cling_tag_list_cn) {
lv_manip: add error handling for _reserve_area Since _reserve_area() may fail due to error allocation failure, add support to report this already reported failure upward. FIXME: it's log_error() without causing direct command failure.
2020-01-30 17:23:47 +03:00
if (!dm_pool_begin_object(ah->mem, 256)) {
log_error("PV tags string allocation failed.");
return 0;
} else if (!_tags_list_str(ah->mem, pva->map->pv, ah->cling_tag_list_cn))
alloc: Record PV tags of parallel PVs in log.
2016-08-24 17:49:34 +03:00
dm_pool_abandon_object(ah->mem);
else if (!dm_pool_grow_object(ah->mem, "\0", 1)) {
dm_pool_abandon_object(ah->mem);
log_error("PV tags string extension failed.");
lv_manip: add error handling for _reserve_area Since _reserve_area() may fail due to error allocation failure, add support to report this already reported failure upward. FIXME: it's log_error() without causing direct command failure.
2020-01-30 17:23:47 +03:00
return 0;
alloc: Record PV tags of parallel PVs in log.
2016-08-24 17:49:34 +03:00
} else
pv_tag_list = dm_pool_end_object(ah->mem);
}
alloc: Refactor area reservation code. No functional changes intended to be included in this patch.
2014-04-10 23:48:59 +04:00
logging: classify log_debug messages Place most log_debug() messages into a class.
2013-01-08 02:30:29 +04:00
log_debug_alloc("%s allocation area %" PRIu32 " %s %s start PE %" PRIu32
alloc: Log PV tags when reserving areas.
2015-03-27 00:13:26 +03:00
" length %" PRIu32 " leaving %" PRIu32 "%s%s.",
cleanup: spaces
2016-01-11 16:11:37 +03:00
area_used->pva ? "Changing " : "Considering",
ix_pva, area_used->pva ? "to" : "as",
alloc: Log PV tags when reserving areas.
2015-03-27 00:13:26 +03:00
dev_name(pva->map->pv->dev), pva->start, required, unreserved,
pv_tag_list ? " with PV tags: " : "",
pv_tag_list ? : "");
if (pv_tag_list)
dm_pool_free(ah->mem, (void *)pv_tag_list);
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
area_used->pva = pva;
area_used->used = required;
lv_manip: add error handling for _reserve_area Since _reserve_area() may fail due to error allocation failure, add support to report this already reported failure upward. FIXME: it's log_error() without causing direct command failure.
2020-01-30 17:23:47 +03:00
return 1;
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
}
alloc: Pass alloc_handle through to _reserve_area.
2015-03-26 23:32:59 +03:00
static int _reserve_required_area(struct alloc_handle *ah, struct alloc_state *alloc_state, struct pv_area *pva,
uint32_t required, uint32_t ix_pva, uint32_t unreserved)
alloc: Refactor area reservation code. No functional changes intended to be included in this patch.
2014-04-10 23:48:59 +04:00
{
uint32_t s;
lv_manip: add error handling for _reserve_area Since _reserve_area() may fail due to error allocation failure, add support to report this already reported failure upward. FIXME: it's log_error() without causing direct command failure.
2020-01-30 17:23:47 +03:00
struct pv_area_used *new_state;
alloc: Refactor area reservation code. No functional changes intended to be included in this patch.
2014-04-10 23:48:59 +04:00
/* Expand areas array if needed after an area was split. */
if (ix_pva >= alloc_state->areas_size) {
alloc_state->areas_size *= 2;
lv_manip: add error handling for _reserve_area Since _reserve_area() may fail due to error allocation failure, add support to report this already reported failure upward. FIXME: it's log_error() without causing direct command failure.
2020-01-30 17:23:47 +03:00
if (!(new_state = realloc(alloc_state->areas, sizeof(*alloc_state->areas) * (alloc_state->areas_size)))) {
alloc: Refactor area reservation code. No functional changes intended to be included in this patch.
2014-04-10 23:48:59 +04:00
log_error("Memory reallocation for parallel areas failed.");
return 0;
}
lv_manip: add error handling for _reserve_area Since _reserve_area() may fail due to error allocation failure, add support to report this already reported failure upward. FIXME: it's log_error() without causing direct command failure.
2020-01-30 17:23:47 +03:00
alloc_state->areas = new_state;
alloc: Refactor area reservation code. No functional changes intended to be included in this patch.
2014-04-10 23:48:59 +04:00
for (s = alloc_state->areas_size / 2; s < alloc_state->areas_size; s++)
alloc_state->areas[s].pva = NULL;
}
lv_manip: add error handling for _reserve_area Since _reserve_area() may fail due to error allocation failure, add support to report this already reported failure upward. FIXME: it's log_error() without causing direct command failure.
2020-01-30 17:23:47 +03:00
if (!_reserve_area(ah, alloc_state, pva, required, ix_pva, unreserved))
return_0;
alloc: Refactor area reservation code. No functional changes intended to be included in this patch.
2014-04-10 23:48:59 +04:00
return 1;
}
Use __attribute__ consistently throughout.
2010-07-09 19:34:40 +04:00
static int _is_condition(struct cmd_context *cmd __attribute__((unused)),
add cling allocation policy
2006-10-08 16:01:13 +04:00
struct pv_segment *pvseg, uint32_t s,
void *data)
more refactoring
2006-10-07 20:00:28 +04:00
{
check_contiguous to use for_each_pv
2006-10-08 03:40:36 +04:00
struct pv_match *pvmatch = data;
alloc: Introduce A_POSITIONAL_FILL. Set A_POSITIONAL_FILL if the array of areas is being filled positionally (with a slot corresponding to each 'leg') rather than sequentially (with all suitable areas found, to be sorted and selected from).
2014-04-15 04:13:47 +04:00
int positional = pvmatch->alloc_state->alloc_parms->flags & A_POSITIONAL_FILL;
more refactoring
2006-10-07 20:00:28 +04:00
alloc: Introduce A_POSITIONAL_FILL. Set A_POSITIONAL_FILL if the array of areas is being filled positionally (with a slot corresponding to each 'leg') rather than sequentially (with all suitable areas found, to be sorted and selected from).
2014-04-15 04:13:47 +04:00
if (positional && pvmatch->alloc_state->areas[s].pva)
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
return 1; /* Area already assigned */
Extend cling allocation policy to recognise PV tags (cling_by_tags). Add allocation/cling_tag_list to lvm.conf.
2010-11-09 15:34:40 +03:00
if (!pvmatch->condition(pvmatch, pvseg, pvmatch->pva))
check_contiguous to use for_each_pv
2006-10-08 03:40:36 +04:00
return 1; /* Continue */
more refactoring
2006-10-07 20:00:28 +04:00
alloc: Fix lvextend failure when varying stripes. A segfault was reported when extending an LV with a smaller number of stripes than originally used. Under unusual circumstances, the cling detection code could successfully find a match against the excess stripe positions and think it had finished prematurely leading to an allocation being pursued with a length of zero. Rename ix_offset to num_positional_areas and move it to struct alloc_state so that _is_condition() can obtain access to it. In _is_condition(), areas_size can no longer be assumed to match the number of positional slots being filled so check this newly-exposed num_positional_areas directly instead. If the slot is outside the range we are trying to fill, just ignore the match for now. (Also note that the code still only performs cling detection against the first segment of the LV.)
2015-07-16 01:12:54 +03:00
if (positional && (s >= pvmatch->alloc_state->num_positional_areas))
return 1;
/* FIXME The previous test should make this one redundant. */
alloc: Introduce A_POSITIONAL_FILL. Set A_POSITIONAL_FILL if the array of areas is being filled positionally (with a slot corresponding to each 'leg') rather than sequentially (with all suitable areas found, to be sorted and selected from).
2014-04-15 04:13:47 +04:00
if (positional && (s >= pvmatch->alloc_state->areas_size))
check_contiguous to use for_each_pv
2006-10-08 03:40:36 +04:00
return 1;
Introduce pv_area_used into allocation algorithm and add debug messages. This is the next preparatory step towards better --alloc anywhere support and is not intended to break anything that currently works so please report any problems - segfaults, bogus data in the new debug messages, or if the code now chooses bizarre allocation layouts.
2010-03-25 05:31:48 +03:00
/*
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
* Only used for cling and contiguous policies (which only make one allocation per PV)
* so it's safe to say all the available space is used.
Introduce pv_area_used into allocation algorithm and add debug messages. This is the next preparatory step towards better --alloc anywhere support and is not intended to break anything that currently works so please report any problems - segfaults, bogus data in the new debug messages, or if the code now chooses bizarre allocation layouts.
2010-03-25 05:31:48 +03:00
*/
lv_manip: add error handling for _reserve_area Since _reserve_area() may fail due to error allocation failure, add support to report this already reported failure upward. FIXME: it's log_error() without causing direct command failure.
2020-01-30 17:23:47 +03:00
if (positional &&
!_reserve_required_area(pvmatch->ah, pvmatch->alloc_state, pvmatch->pva, pvmatch->pva->count, s, 0))
return_0;
Permit mimage LVs to be striped in lvcreate and lvresize.
2010-04-09 05:00:10 +04:00
check_contiguous to use for_each_pv
2006-10-08 03:40:36 +04:00
return 2; /* Finished */
more refactoring
2006-10-07 20:00:28 +04:00
}
add cling allocation policy
2006-10-08 16:01:13 +04:00
/*
* Is pva on same PV as any existing areas?
*/
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
static int _check_cling(struct alloc_handle *ah,
Move the core of the lib/config/config.c functionality into libdevmapper, leaving behind the LVM-specific parts of the code (convenience wrappers that handle `struct device` and `struct cmd_context`, basically). A number of functions have been renamed (in addition to getting a dm_ prefix) -- namely, all of the config interface now has a dm_config_ prefix.
2011-08-30 18:55:15 +04:00
const struct dm_config_node *cling_tag_list_cn,
add cling allocation policy
2006-10-08 16:01:13 +04:00
struct lv_segment *prev_lvseg, struct pv_area *pva,
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
struct alloc_state *alloc_state)
add cling allocation policy
2006-10-08 16:01:13 +04:00
{
struct pv_match pvmatch;
int r;
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
uint32_t le, len;
add cling allocation policy
2006-10-08 16:01:13 +04:00
alloc: Pass alloc_handle through to _reserve_area.
2015-03-26 23:32:59 +03:00
pvmatch.ah = ah;
Extend cling allocation policy to recognise PV tags (cling_by_tags). Add allocation/cling_tag_list to lvm.conf.
2010-11-09 15:34:40 +03:00
pvmatch.condition = cling_tag_list_cn ? _has_matching_pv_tag : _is_same_pv;
alloc: Refactor area reservation code. No functional changes intended to be included in this patch.
2014-04-10 23:48:59 +04:00
pvmatch.alloc_state = alloc_state;
add cling allocation policy
2006-10-08 16:01:13 +04:00
pvmatch.pva = pva;
Extend cling allocation policy to recognise PV tags (cling_by_tags). Add allocation/cling_tag_list to lvm.conf.
2010-11-09 15:34:40 +03:00
pvmatch.cling_tag_list_cn = cling_tag_list_cn;
add cling allocation policy
2006-10-08 16:01:13 +04:00
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
if (ah->maximise_cling) {
/* Check entire LV */
le = 0;
len = prev_lvseg->le + prev_lvseg->len;
} else {
/* Only check 1 LE at end of previous LV segment */
le = prev_lvseg->le + prev_lvseg->len - 1;
len = 1;
}
add cling allocation policy
2006-10-08 16:01:13 +04:00
/* FIXME Cope with stacks by flattening */
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
if (!(r = _for_each_pv(ah->cmd, prev_lvseg->lv, le, len, NULL, NULL,
add cling allocation policy
2006-10-08 16:01:13 +04:00
0, 0, -1, 1,
_is_condition, &pvmatch)))
stack;
if (r != 2)
return 0;
return 1;
}
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
/*
* Is pva contiguous to any existing areas or on the same PV?
*/
alloc: Pass alloc_handle through to _reserve_area.
2015-03-26 23:32:59 +03:00
static int _check_contiguous(struct alloc_handle *ah,
check_contiguous to use for_each_pv
2006-10-08 03:40:36 +04:00
struct lv_segment *prev_lvseg, struct pv_area *pva,
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
struct alloc_state *alloc_state)
o Striped allocator o Changed pv_map.c to maintain the list of free areas in size order, which is more helpful to the allocators. If you want to allocate a bit of an area call consume_area(area, size), this will adjust the area if there's some space left and shuffle it to the correct place in the list. Not tested.
2001-11-29 21:45:35 +03:00
{
check_contiguous to use for_each_pv
2006-10-08 03:40:36 +04:00
struct pv_match pvmatch;
more refactoring
2006-10-07 20:00:28 +04:00
int r;
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
alloc: Pass alloc_handle through to _reserve_area.
2015-03-26 23:32:59 +03:00
pvmatch.ah = ah;
check_contiguous to use for_each_pv
2006-10-08 03:40:36 +04:00
pvmatch.condition = _is_contiguous;
alloc: Refactor area reservation code. No functional changes intended to be included in this patch.
2014-04-10 23:48:59 +04:00
pvmatch.alloc_state = alloc_state;
check_contiguous to use for_each_pv
2006-10-08 03:40:36 +04:00
pvmatch.pva = pva;
Extend cling allocation policy to recognise PV tags (cling_by_tags). Add allocation/cling_tag_list to lvm.conf.
2010-11-09 15:34:40 +03:00
pvmatch.cling_tag_list_cn = NULL;
check_contiguous to use for_each_pv
2006-10-08 03:40:36 +04:00
/* FIXME Cope with stacks by flattening */
alloc: Pass alloc_handle through to _reserve_area.
2015-03-26 23:32:59 +03:00
if (!(r = _for_each_pv(ah->cmd, prev_lvseg->lv,
Fix pvmove allocation to take existing parallel stripes into account. When moving parts of striped LVs, pvmove wouldn't care about leaving you with two stripes on the same disk. Now --alloc anywhere is needed for that. (Tried and gave up on two alternative approaches before the one committed here.)
2010-04-08 04:28:57 +04:00
prev_lvseg->le + prev_lvseg->len - 1, 1, NULL, NULL,
check_contiguous to use for_each_pv
2006-10-08 03:40:36 +04:00
0, 0, -1, 1,
add cling allocation policy
2006-10-08 16:01:13 +04:00
_is_condition, &pvmatch)))
more refactoring
2006-10-07 20:00:28 +04:00
stack;
Start merging cloned allocation functions.
2005-05-17 17:49:45 +04:00
check_contiguous to use for_each_pv
2006-10-08 03:40:36 +04:00
if (r != 2)
return 0;
return 1;
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
}
o Striped allocator o Changed pv_map.c to maintain the list of free areas in size order, which is more helpful to the allocators. If you want to allocate a bit of an area call consume_area(area, size), this will adjust the area if there's some space left and shuffle it to the correct place in the list. Not tested.
2001-11-29 21:45:35 +03:00
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
/*
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
* Is pva on same PV as any areas already used in this allocation attempt?
*/
Fix cling policy not to behave like normal policy if no previous LV seg. Fix alloc cling to cling to PVs already found with contiguous policy.
2012-05-12 02:53:13 +04:00
static int _check_cling_to_alloced(struct alloc_handle *ah, const struct dm_config_node *cling_tag_list_cn,
struct pv_area *pva, struct alloc_state *alloc_state)
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
{
unsigned s;
struct alloced_area *aa;
alloc: Introduce A_POSITIONAL_FILL. Set A_POSITIONAL_FILL if the array of areas is being filled positionally (with a slot corresponding to each 'leg') rather than sequentially (with all suitable areas found, to be sorted and selected from).
2014-04-15 04:13:47 +04:00
int positional = alloc_state->alloc_parms->flags & A_POSITIONAL_FILL;
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
/*
* Ignore log areas. They are always allocated whole as part of the
* first allocation. If they aren't yet set, we know we've nothing to do.
*/
if (alloc_state->log_area_count_still_needed)
return 0;
for (s = 0; s < ah->area_count; s++) {
alloc: Introduce A_POSITIONAL_FILL. Set A_POSITIONAL_FILL if the array of areas is being filled positionally (with a slot corresponding to each 'leg') rather than sequentially (with all suitable areas found, to be sorted and selected from).
2014-04-15 04:13:47 +04:00
if (positional && alloc_state->areas[s].pva)
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
continue; /* Area already assigned */
dm_list_iterate_items(aa, &ah->alloced_areas[s]) {
Fix cling policy not to behave like normal policy if no previous LV seg. Fix alloc cling to cling to PVs already found with contiguous policy.
2012-05-12 02:53:13 +04:00
if ((!cling_tag_list_cn && (pva->map->pv == aa[0].pv)) ||
alloc: Avoid PV tags too when avoiding parallel PV allocation. Also add debug messages for parallel PVs.
2016-08-24 21:37:50 +03:00
(cling_tag_list_cn && _pvs_have_matching_tag(cling_tag_list_cn, pva->map->pv, aa[0].pv, 0))) {
lv_manip: add error handling for _reserve_area Since _reserve_area() may fail due to error allocation failure, add support to report this already reported failure upward. FIXME: it's log_error() without causing direct command failure.
2020-01-30 17:23:47 +03:00
if (positional &&
!_reserve_required_area(ah, alloc_state, pva, pva->count, s, 0))
return_0;
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
return 1;
}
}
}
return 0;
}
alloc: Avoid PV tags too when avoiding parallel PV allocation. Also add debug messages for parallel PVs.
2016-08-24 21:37:50 +03:00
static int _pv_is_parallel(struct physical_volume *pv, struct dm_list *parallel_pvs, const struct dm_config_node *cling_tag_list_cn)
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
{
struct pv_list *pvl;
alloc: Avoid PV tags too when avoiding parallel PV allocation. Also add debug messages for parallel PVs.
2016-08-24 21:37:50 +03:00
dm_list_iterate_items(pvl, parallel_pvs) {
if (pv == pvl->pv) {
log_debug_alloc("Not using free space on existing parallel PV %s.",
pv_dev_name(pvl->pv));
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
return 1;
alloc: Avoid PV tags too when avoiding parallel PV allocation. Also add debug messages for parallel PVs.
2016-08-24 21:37:50 +03:00
}
if (cling_tag_list_cn && _pvs_have_matching_tag(cling_tag_list_cn, pvl->pv, pv, 1))
return 1;
}
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
return 0;
}
/*
* Decide whether or not to try allocation from supplied area pva.
* alloc_state->areas may get modified.
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
*/
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
static area_use_t _check_pva(struct alloc_handle *ah, struct pv_area *pva, uint32_t still_needed,
alloc: Access alloc_parms from alloc_state. alloc_parms is constant while allocating.
2014-04-15 04:05:34 +04:00
struct alloc_state *alloc_state,
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
unsigned already_found_one, unsigned iteration_count, unsigned log_iteration_count)
{
alloc: Access alloc_parms from alloc_state. alloc_parms is constant while allocating.
2014-04-15 04:05:34 +04:00
const struct alloc_parms *alloc_parms = alloc_state->alloc_parms;
lost line
2012-02-01 06:11:43 +04:00
unsigned s;
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
/* Skip fully-reserved areas (which are not currently removed from the list). */
if (!pva->unreserved)
return NEXT_AREA;
Track unreserved space for all alloc policies and then permit NORMAL to place log and data on same single PV.
2012-02-01 06:10:45 +04:00
/* FIXME Should this test be removed? */
if (iteration_count)
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
/*
Track unreserved space for all alloc policies and then permit NORMAL to place log and data on same single PV.
2012-02-01 06:10:45 +04:00
* Don't use an area twice.
*/
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
for (s = 0; s < alloc_state->areas_size; s++)
if (alloc_state->areas[s].pva == pva)
return NEXT_AREA;
/* If maximise_cling is set, perform several checks, otherwise perform exactly one. */
Append _TO_LVSEG to names of internal A_CONTIGUOUS and A_CLING flags. Remove some unnecesary prev_lvseg checks.
2012-05-11 22:59:01 +04:00
if (!iteration_count && !log_iteration_count && alloc_parms->flags & (A_CONTIGUOUS_TO_LVSEG | A_CLING_TO_LVSEG | A_CLING_TO_ALLOCED)) {
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
/* Contiguous? */
alloc: fix lvextend when stripe number varies The PREFERRED allocation mechanism requires the number of areas in the previous LV segment to match the number in the new segment being allocated. If they do not match, the code may crash. E.g. https://bugzilla.redhat.com/989347 Introduce A_AREA_COUNT_MATCHES and when not set avoid referring to the previous segment with the contiguous and cling policies.
2013-07-29 22:35:45 +04:00
if (((alloc_parms->flags & A_CONTIGUOUS_TO_LVSEG) ||
alloc: Correct existing use of positional fill. Perform two allocation attempts with cling if maximise_cling is set, first with then without positional fill. Avoid segfaults from confusion between positional and sorted sequential allocation when number of stripes varies as reported here: https://www.redhat.com/archives/linux-lvm/2014-March/msg00001.html
2014-04-15 05:34:35 +04:00
(ah->maximise_cling && (alloc_parms->flags & A_AREA_COUNT_MATCHES))) &&
alloc: Pass alloc_handle through to _reserve_area.
2015-03-26 23:32:59 +03:00
_check_contiguous(ah, alloc_parms->prev_lvseg, pva, alloc_state))
alloc: Refactor area reservation code. No functional changes intended to be included in this patch.
2014-04-10 23:48:59 +04:00
goto found;
lvresize: separate validation from action Start separating the validation from the action in the basic lvresize code moved to the library. Remove incorrect use of command line error codes from lvresize library functions. Move errors.h to tools directory to reinforce this, exporting public versions of the error codes in lvm2cmd.h for dmeventd plugins to use.
2013-07-06 06:28:21 +04:00
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
/* Try next area on same PV if looking for contiguous space */
Append _TO_LVSEG to names of internal A_CONTIGUOUS and A_CLING flags. Remove some unnecesary prev_lvseg checks.
2012-05-11 22:59:01 +04:00
if (alloc_parms->flags & A_CONTIGUOUS_TO_LVSEG)
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
return NEXT_AREA;
Fix cling policy not to behave like normal policy if no previous LV seg. Fix alloc cling to cling to PVs already found with contiguous policy.
2012-05-12 02:53:13 +04:00
/* Cling to prev_lvseg? */
alloc: fix lvextend when stripe number varies The PREFERRED allocation mechanism requires the number of areas in the previous LV segment to match the number in the new segment being allocated. If they do not match, the code may crash. E.g. https://bugzilla.redhat.com/989347 Introduce A_AREA_COUNT_MATCHES and when not set avoid referring to the previous segment with the contiguous and cling policies.
2013-07-29 22:35:45 +04:00
if (((alloc_parms->flags & A_CLING_TO_LVSEG) ||
alloc: Correct existing use of positional fill. Perform two allocation attempts with cling if maximise_cling is set, first with then without positional fill. Avoid segfaults from confusion between positional and sorted sequential allocation when number of stripes varies as reported here: https://www.redhat.com/archives/linux-lvm/2014-March/msg00001.html
2014-04-15 05:34:35 +04:00
(ah->maximise_cling && (alloc_parms->flags & A_AREA_COUNT_MATCHES))) &&
Fix cling policy not to behave like normal policy if no previous LV seg. Fix alloc cling to cling to PVs already found with contiguous policy.
2012-05-12 02:53:13 +04:00
_check_cling(ah, NULL, alloc_parms->prev_lvseg, pva, alloc_state))
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
/* If this PV is suitable, use this first area */
alloc: Refactor area reservation code. No functional changes intended to be included in this patch.
2014-04-10 23:48:59 +04:00
goto found;
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
Fix cling policy not to behave like normal policy if no previous LV seg. Fix alloc cling to cling to PVs already found with contiguous policy.
2012-05-12 02:53:13 +04:00
/* Cling_to_alloced? */
if ((alloc_parms->flags & A_CLING_TO_ALLOCED) &&
_check_cling_to_alloced(ah, NULL, pva, alloc_state))
alloc: Refactor area reservation code. No functional changes intended to be included in this patch.
2014-04-10 23:48:59 +04:00
goto found;
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
/* Cling_by_tags? */
Fix cling policy not to behave like normal policy if no previous LV seg. Fix alloc cling to cling to PVs already found with contiguous policy.
2012-05-12 02:53:13 +04:00
if (!(alloc_parms->flags & A_CLING_BY_TAGS) || !ah->cling_tag_list_cn)
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
return NEXT_PV;
alloc: Correct existing use of positional fill. Perform two allocation attempts with cling if maximise_cling is set, first with then without positional fill. Avoid segfaults from confusion between positional and sorted sequential allocation when number of stripes varies as reported here: https://www.redhat.com/archives/linux-lvm/2014-March/msg00001.html
2014-04-15 05:34:35 +04:00
if ((alloc_parms->flags & A_AREA_COUNT_MATCHES)) {
Fix cling policy not to behave like normal policy if no previous LV seg. Fix alloc cling to cling to PVs already found with contiguous policy.
2012-05-12 02:53:13 +04:00
if (_check_cling(ah, ah->cling_tag_list_cn, alloc_parms->prev_lvseg, pva, alloc_state))
alloc: Refactor area reservation code. No functional changes intended to be included in this patch.
2014-04-10 23:48:59 +04:00
goto found;
Fix cling policy not to behave like normal policy if no previous LV seg. Fix alloc cling to cling to PVs already found with contiguous policy.
2012-05-12 02:53:13 +04:00
} else if (_check_cling_to_alloced(ah, ah->cling_tag_list_cn, pva, alloc_state))
alloc: Refactor area reservation code. No functional changes intended to be included in this patch.
2014-04-10 23:48:59 +04:00
goto found;
Fix cling policy not to behave like normal policy if no previous LV seg. Fix alloc cling to cling to PVs already found with contiguous policy.
2012-05-12 02:53:13 +04:00
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
/* All areas on this PV give same result so pointless checking more */
return NEXT_PV;
}
/* Normal/Anywhere */
/* Is it big enough on its own? */
if (pva->unreserved * ah->area_multiple < still_needed &&
((!(alloc_parms->flags & A_CAN_SPLIT) && !ah->log_area_count) ||
(already_found_one && alloc_parms->alloc != ALLOC_ANYWHERE)))
return NEXT_PV;
alloc: Refactor area reservation code. No functional changes intended to be included in this patch.
2014-04-10 23:48:59 +04:00
found:
alloc: Introduce A_POSITIONAL_FILL. Set A_POSITIONAL_FILL if the array of areas is being filled positionally (with a slot corresponding to each 'leg') rather than sequentially (with all suitable areas found, to be sorted and selected from).
2014-04-15 04:13:47 +04:00
if (alloc_parms->flags & A_POSITIONAL_FILL)
return PREFERRED;
return USE_AREA;
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
}
/*
* Decide how many extents we're trying to obtain from a given area.
* Removes the extents from further consideration.
*/
static uint32_t _calc_required_extents(struct alloc_handle *ah, struct pv_area *pva, unsigned ix_pva, uint32_t max_to_allocate, alloc_policy_t alloc)
{
uint32_t required = max_to_allocate / ah->area_multiple;
Track unreserved space for all alloc policies and then permit NORMAL to place log and data on same single PV.
2012-02-01 06:10:45 +04:00
/*
cleanup: spaces
2016-01-11 16:11:37 +03:00
* Update amount unreserved - effectively splitting an area
Track unreserved space for all alloc policies and then permit NORMAL to place log and data on same single PV.
2012-02-01 06:10:45 +04:00
* into two or more parts. If the whole stripe doesn't fit,
* reduce amount we're looking for.
*/
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
if (alloc == ALLOC_ANYWHERE) {
allocation: Fix alloc anywhere with parity. Take account of parity areas with alloc anywhere in _calc_required_extents. Extents beyond area_count were treated incorrectly as mirror logs.
2014-05-14 19:25:43 +04:00
if (ix_pva >= ah->area_count + ah->parity_count)
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
required = ah->log_len;
Track unreserved space for all alloc policies and then permit NORMAL to place log and data on same single PV.
2012-02-01 06:10:45 +04:00
} else if (required < ah->log_len)
required = ah->log_len;
if (required >= pva->unreserved) {
required = pva->unreserved;
pva->unreserved = 0;
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
} else {
Track unreserved space for all alloc policies and then permit NORMAL to place log and data on same single PV.
2012-02-01 06:10:45 +04:00
pva->unreserved -= required;
reinsert_changed_pv_area(pva);
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
}
return required;
}
static void _clear_areas(struct alloc_state *alloc_state)
{
uint32_t s;
alloc: Fix lvextend failure when varying stripes. A segfault was reported when extending an LV with a smaller number of stripes than originally used. Under unusual circumstances, the cling detection code could successfully find a match against the excess stripe positions and think it had finished prematurely leading to an allocation being pursued with a length of zero. Rename ix_offset to num_positional_areas and move it to struct alloc_state so that _is_condition() can obtain access to it. In _is_condition(), areas_size can no longer be assumed to match the number of positional slots being filled so check this newly-exposed num_positional_areas directly instead. If the slot is outside the range we are trying to fill, just ignore the match for now. (Also note that the code still only performs cling detection against the first segment of the LV.)
2015-07-16 01:12:54 +03:00
alloc_state->num_positional_areas = 0;
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
for (s = 0; s < alloc_state->areas_size; s++)
alloc_state->areas[s].pva = NULL;
}
Track unreserved space for all alloc policies and then permit NORMAL to place log and data on same single PV.
2012-02-01 06:10:45 +04:00
static void _reset_unreserved(struct dm_list *pvms)
{
struct pv_map *pvm;
struct pv_area *pva;
dm_list_iterate_items(pvm, pvms)
dm_list_iterate_items(pva, &pvm->areas)
if (pva->unreserved != pva->count) {
pva->unreserved = pva->count;
reinsert_changed_pv_area(pva);
}
}
Add support for m-way to n-way up-convert in RAID1 (no linear to n-way yet) This patch adds the ability to upconvert a raid1 array - say from 2-way to 3-way. It does not yet support upconverting linear to n-way. The 'raid' device-mapper target allows for individual components (images) of an array to be specified for rebuild. This mechanism is used when adding new images to the array so that the new images can be resync'ed while the rest of the images in the array can remain 'in-sync'. (There is no mirror-on-mirror layering required.)
2011-08-18 23:41:21 +04:00
static void _report_needed_allocation_space(struct alloc_handle *ah,
allocation: misc fixes for percent/raid rounding Several fixes for the recent changes that treat allocation percentages as upper limits. Improve messages to make it easier to see what is happening. Fix some cases that failed with errors when they didn't need to. Fix crashes when first_seg() returns NULL. Remove a couple of log_errors that were actually debugging messages.
2014-02-22 04:26:01 +04:00
struct alloc_state *alloc_state,
struct dm_list *pvms)
Add support for m-way to n-way up-convert in RAID1 (no linear to n-way yet) This patch adds the ability to upconvert a raid1 array - say from 2-way to 3-way. It does not yet support upconverting linear to n-way. The 'raid' device-mapper target allows for individual components (images) of an array to be specified for rebuild. This mechanism is used when adding new images to the array so that the new images can be resync'ed while the rest of the images in the array can remain 'in-sync'. (There is no mirror-on-mirror layering required.)
2011-08-18 23:41:21 +04:00
{
const char *metadata_type;
avoid multi-line calc with incorrect intermediate var contents
2011-08-19 20:41:26 +04:00
uint32_t parallel_areas_count, parallel_area_size;
Add support for m-way to n-way up-convert in RAID1 (no linear to n-way yet) This patch adds the ability to upconvert a raid1 array - say from 2-way to 3-way. It does not yet support upconverting linear to n-way. The 'raid' device-mapper target allows for individual components (images) of an array to be specified for rebuild. This mechanism is used when adding new images to the array so that the new images can be resync'ed while the rest of the images in the array can remain 'in-sync'. (There is no mirror-on-mirror layering required.)
2011-08-18 23:41:21 +04:00
uint32_t metadata_count, metadata_size;
cache: Allocation code changes necessary to support cache_pool Cache pools require a data and metadata area (like thin pools). Unlike thin pool, if 'cache_pool_metadata_require_separate_pvs' is not set to '1', the metadata and data area will be allocated from the same device. It is also done in a manner similar to RAID, where a single chunk of space is allocated and then split to form the metadata and data device - ensuring that they are together.
2014-01-28 22:25:02 +04:00
parallel_area_size = ah->new_extents - alloc_state->allocated;
parallel_area_size /= ah->area_multiple;
allocation: misc fixes for percent/raid rounding Several fixes for the recent changes that treat allocation percentages as upper limits. Improve messages to make it easier to see what is happening. Fix some cases that failed with errors when they didn't need to. Fix crashes when first_seg() returns NULL. Remove a couple of log_errors that were actually debugging messages.
2014-02-22 04:26:01 +04:00
parallel_area_size -= (ah->alloc_and_split_meta && !ah->split_metadata_is_allocated) ? ah->log_len : 0;
avoid multi-line calc with incorrect intermediate var contents
2011-08-19 20:41:26 +04:00
parallel_areas_count = ah->area_count + ah->parity_count;
Add support for m-way to n-way up-convert in RAID1 (no linear to n-way yet) This patch adds the ability to upconvert a raid1 array - say from 2-way to 3-way. It does not yet support upconverting linear to n-way. The 'raid' device-mapper target allows for individual components (images) of an array to be specified for rebuild. This mechanism is used when adding new images to the array so that the new images can be resync'ed while the rest of the images in the array can remain 'in-sync'. (There is no mirror-on-mirror layering required.)
2011-08-18 23:41:21 +04:00
metadata_size = ah->log_len;
if (ah->alloc_and_split_meta) {
cache: Allocation code changes necessary to support cache_pool Cache pools require a data and metadata area (like thin pools). Unlike thin pool, if 'cache_pool_metadata_require_separate_pvs' is not set to '1', the metadata and data area will be allocated from the same device. It is also done in a manner similar to RAID, where a single chunk of space is allocated and then split to form the metadata and data device - ensuring that they are together.
2014-01-28 22:25:02 +04:00
metadata_type = "metadata area";
avoid multi-line calc with incorrect intermediate var contents
2011-08-19 20:41:26 +04:00
metadata_count = parallel_areas_count;
allocation: misc fixes for percent/raid rounding Several fixes for the recent changes that treat allocation percentages as upper limits. Improve messages to make it easier to see what is happening. Fix some cases that failed with errors when they didn't need to. Fix crashes when first_seg() returns NULL. Remove a couple of log_errors that were actually debugging messages.
2014-02-22 04:26:01 +04:00
if (ah->split_metadata_is_allocated)
metadata_size = 0;
Add support for m-way to n-way up-convert in RAID1 (no linear to n-way yet) This patch adds the ability to upconvert a raid1 array - say from 2-way to 3-way. It does not yet support upconverting linear to n-way. The 'raid' device-mapper target allows for individual components (images) of an array to be specified for rebuild. This mechanism is used when adding new images to the array so that the new images can be resync'ed while the rest of the images in the array can remain 'in-sync'. (There is no mirror-on-mirror layering required.)
2011-08-18 23:41:21 +04:00
} else {
metadata_type = "mirror log";
metadata_count = alloc_state->log_area_count_still_needed;
}
alloc: Fix lvextend failure when varying stripes. A segfault was reported when extending an LV with a smaller number of stripes than originally used. Under unusual circumstances, the cling detection code could successfully find a match against the excess stripe positions and think it had finished prematurely leading to an allocation being pursued with a length of zero. Rename ix_offset to num_positional_areas and move it to struct alloc_state so that _is_condition() can obtain access to it. In _is_condition(), areas_size can no longer be assumed to match the number of positional slots being filled so check this newly-exposed num_positional_areas directly instead. If the slot is outside the range we are trying to fill, just ignore the match for now. (Also note that the code still only performs cling detection against the first segment of the LV.)
2015-07-16 01:12:54 +03:00
log_debug_alloc("Still need %s%" PRIu32 " total extents from %" PRIu32 " remaining (%" PRIu32 " positional slots):",
allocation: Allow approximate allocation when specifying size in percent Introduce a new parameter called "approx_alloc" that is set when the desired size of a new LV is specified in percentage terms. If set, the allocation code tries to get as much space as it can but does not fail if can at least get some. One of the practical implications is that users can now specify 100%FREE when creating RAID LVs, like this: ~> lvcreate --type raid5 -i 2 -l 100%FREE -n lv vg
2014-02-14 07:10:28 +04:00
ah->approx_alloc ? "up to " : "",
alloc: Fix lvextend failure when varying stripes. A segfault was reported when extending an LV with a smaller number of stripes than originally used. Under unusual circumstances, the cling detection code could successfully find a match against the excess stripe positions and think it had finished prematurely leading to an allocation being pursued with a length of zero. Rename ix_offset to num_positional_areas and move it to struct alloc_state so that _is_condition() can obtain access to it. In _is_condition(), areas_size can no longer be assumed to match the number of positional slots being filled so check this newly-exposed num_positional_areas directly instead. If the slot is outside the range we are trying to fill, just ignore the match for now. (Also note that the code still only performs cling detection against the first segment of the LV.)
2015-07-16 01:12:54 +03:00
parallel_area_size * parallel_areas_count + metadata_size * metadata_count, pv_maps_size(pvms),
alloc_state->num_positional_areas);
logging: classify log_debug messages Place most log_debug() messages into a class.
2013-01-08 02:30:29 +04:00
log_debug_alloc(" %" PRIu32 " (%" PRIu32 " data/%" PRIu32
" parity) parallel areas of %" PRIu32 " extents each",
parallel_areas_count, ah->area_count, ah->parity_count, parallel_area_size);
cache: Allocation code changes necessary to support cache_pool Cache pools require a data and metadata area (like thin pools). Unlike thin pool, if 'cache_pool_metadata_require_separate_pvs' is not set to '1', the metadata and data area will be allocated from the same device. It is also done in a manner similar to RAID, where a single chunk of space is allocated and then split to form the metadata and data device - ensuring that they are together.
2014-01-28 22:25:02 +04:00
log_debug_alloc(" %" PRIu32 " %s%s of %" PRIu32 " extents each",
metadata_count, metadata_type,
(metadata_count == 1) ? "" : "s",
metadata_size);
Add support for m-way to n-way up-convert in RAID1 (no linear to n-way yet) This patch adds the ability to upconvert a raid1 array - say from 2-way to 3-way. It does not yet support upconverting linear to n-way. The 'raid' device-mapper target allows for individual components (images) of an array to be specified for rebuild. This mechanism is used when adding new images to the array so that the new images can be resync'ed while the rest of the images in the array can remain 'in-sync'. (There is no mirror-on-mirror layering required.)
2011-08-18 23:41:21 +04:00
}
alloc: Respect cling_tag_list in contig alloc. When performing initial allocation (so there is nothing yet to cling to), use the list of tags in allocation/cling_tag_list to partition the PVs. We implement this by maintaining a list of tags that have been "used up" as we proceed and ignoring further devices that have a tag on the list. https://bugzilla.redhat.com/983600
2015-04-11 03:55:24 +03:00
/* Work through the array, removing any entries with tags already used by previous areas. */
static int _limit_to_one_area_per_tag(struct alloc_handle *ah, struct alloc_state *alloc_state,
uint32_t ix_log_offset, unsigned *ix)
{
uint32_t s = 0, u = 0;
DM_LIST_INIT(pv_tags);
while (s < alloc_state->areas_size && alloc_state->areas[s].pva) {
/* Start again with an empty tag list when we reach the log devices */
if (u == ix_log_offset)
dm_list_init(&pv_tags);
if (!_pv_has_matching_tag(ah->cling_tag_list_cn, alloc_state->areas[s].pva->map->pv, alloc_state->areas[s].pva->start, s, &pv_tags)) {
/* The comparison fn will ignore any non-cling tags so just add everything */
if (!str_list_add_list(ah->mem, &pv_tags, &alloc_state->areas[s].pva->map->pv->tags))
return_0;
if (s != u)
alloc_state->areas[u] = alloc_state->areas[s];
u++;
} else
(*ix)--; /* One area removed */
s++;
}
allocation: Avoid exceeding array bounds in allocation tag code If _limit_to_one_area_per_tag() changes nothing it writes beyond the array.
2018-01-10 05:03:32 +03:00
if (u < alloc_state->areas_size)
alloc_state->areas[u].pva = NULL;
alloc: Respect cling_tag_list in contig alloc. When performing initial allocation (so there is nothing yet to cling to), use the list of tags in allocation/cling_tag_list to partition the PVs. We implement this by maintaining a list of tags that have been "used up" as we proceed and ignoring further devices that have a tag on the list. https://bugzilla.redhat.com/983600
2015-04-11 03:55:24 +03:00
return 1;
}
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
/*
* Returns 1 regardless of whether any space was found, except on error.
*/
alloc: Access alloc_parms from alloc_state. alloc_parms is constant while allocating.
2014-04-15 04:05:34 +04:00
static int _find_some_parallel_space(struct alloc_handle *ah,
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
struct dm_list *pvms, struct alloc_state *alloc_state,
struct dm_list *parallel_pvs, uint32_t max_to_allocate)
{
alloc: Access alloc_parms from alloc_state. alloc_parms is constant while allocating.
2014-04-15 04:05:34 +04:00
const struct alloc_parms *alloc_parms = alloc_state->alloc_parms;
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
unsigned ix = 0;
unsigned last_ix;
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
struct pv_map *pvm;
struct pv_area *pva;
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
unsigned preferred_count = 0;
unsigned already_found_one;
Extend core allocation code in preparation for mirrored log areas.
2010-03-01 23:00:20 +03:00
unsigned ix_log_offset; /* Offset to start of areas to use for log */
Handle multi-extent mirror log allocation when smallest PV has only 1 extent.
2009-05-30 04:09:27 +04:00
unsigned too_small_for_log_count; /* How many too small for log? */
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
unsigned iteration_count = 0; /* cling_to_alloced may need 2 iterations */
unsigned log_iteration_count = 0; /* extra iteration for logs on data devices */
Extend core allocation code in preparation for mirrored log areas.
2010-03-01 23:00:20 +03:00
struct alloced_area *aa;
uint32_t s;
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
uint32_t devices_needed = ah->area_count + ah->parity_count;
alloc: Refactor area reservation code. No functional changes intended to be included in this patch.
2014-04-10 23:48:59 +04:00
uint32_t required;
Perform high-level free space check before each allocation attempt.
2006-10-23 19:54:51 +04:00
alloc: Fix lvextend failure when varying stripes. A segfault was reported when extending an LV with a smaller number of stripes than originally used. Under unusual circumstances, the cling detection code could successfully find a match against the excess stripe positions and think it had finished prematurely leading to an allocation being pursued with a length of zero. Rename ix_offset to num_positional_areas and move it to struct alloc_state so that _is_condition() can obtain access to it. In _is_condition(), areas_size can no longer be assumed to match the number of positional slots being filled so check this newly-exposed num_positional_areas directly instead. If the slot is outside the range we are trying to fill, just ignore the match for now. (Also note that the code still only performs cling detection against the first segment of the LV.)
2015-07-16 01:12:54 +03:00
_clear_areas(alloc_state);
_reset_unreserved(pvms);
/* num_positional_areas holds the number of parallel allocations that must be contiguous/cling */
/* These appear first in the array, so it is also the offset to the non-preferred allocations */
Fix cling policy not to behave like normal policy if no previous LV seg. Fix alloc cling to cling to PVs already found with contiguous policy.
2012-05-12 02:53:13 +04:00
/* At most one of A_CONTIGUOUS_TO_LVSEG, A_CLING_TO_LVSEG or A_CLING_TO_ALLOCED may be set */
alloc: Correct existing use of positional fill. Perform two allocation attempts with cling if maximise_cling is set, first with then without positional fill. Avoid segfaults from confusion between positional and sorted sequential allocation when number of stripes varies as reported here: https://www.redhat.com/archives/linux-lvm/2014-March/msg00001.html
2014-04-15 05:34:35 +04:00
if (!(alloc_parms->flags & A_POSITIONAL_FILL))
alloc: Fix lvextend failure when varying stripes. A segfault was reported when extending an LV with a smaller number of stripes than originally used. Under unusual circumstances, the cling detection code could successfully find a match against the excess stripe positions and think it had finished prematurely leading to an allocation being pursued with a length of zero. Rename ix_offset to num_positional_areas and move it to struct alloc_state so that _is_condition() can obtain access to it. In _is_condition(), areas_size can no longer be assumed to match the number of positional slots being filled so check this newly-exposed num_positional_areas directly instead. If the slot is outside the range we are trying to fill, just ignore the match for now. (Also note that the code still only performs cling detection against the first segment of the LV.)
2015-07-16 01:12:54 +03:00
alloc_state->num_positional_areas = 0;
alloc: Correct existing use of positional fill. Perform two allocation attempts with cling if maximise_cling is set, first with then without positional fill. Avoid segfaults from confusion between positional and sorted sequential allocation when number of stripes varies as reported here: https://www.redhat.com/archives/linux-lvm/2014-March/msg00001.html
2014-04-15 05:34:35 +04:00
else if (alloc_parms->flags & (A_CONTIGUOUS_TO_LVSEG | A_CLING_TO_LVSEG))
alloc: Fix lvextend failure when varying stripes. A segfault was reported when extending an LV with a smaller number of stripes than originally used. Under unusual circumstances, the cling detection code could successfully find a match against the excess stripe positions and think it had finished prematurely leading to an allocation being pursued with a length of zero. Rename ix_offset to num_positional_areas and move it to struct alloc_state so that _is_condition() can obtain access to it. In _is_condition(), areas_size can no longer be assumed to match the number of positional slots being filled so check this newly-exposed num_positional_areas directly instead. If the slot is outside the range we are trying to fill, just ignore the match for now. (Also note that the code still only performs cling detection against the first segment of the LV.)
2015-07-16 01:12:54 +03:00
alloc_state->num_positional_areas = _stripes_per_mimage(alloc_parms->prev_lvseg) * alloc_parms->prev_lvseg->area_count;
alloc: Correct existing use of positional fill. Perform two allocation attempts with cling if maximise_cling is set, first with then without positional fill. Avoid segfaults from confusion between positional and sorted sequential allocation when number of stripes varies as reported here: https://www.redhat.com/archives/linux-lvm/2014-March/msg00001.html
2014-04-15 05:34:35 +04:00
else if (alloc_parms->flags & A_CLING_TO_ALLOCED)
alloc: Fix lvextend failure when varying stripes. A segfault was reported when extending an LV with a smaller number of stripes than originally used. Under unusual circumstances, the cling detection code could successfully find a match against the excess stripe positions and think it had finished prematurely leading to an allocation being pursued with a length of zero. Rename ix_offset to num_positional_areas and move it to struct alloc_state so that _is_condition() can obtain access to it. In _is_condition(), areas_size can no longer be assumed to match the number of positional slots being filled so check this newly-exposed num_positional_areas directly instead. If the slot is outside the range we are trying to fill, just ignore the match for now. (Also note that the code still only performs cling detection against the first segment of the LV.)
2015-07-16 01:12:54 +03:00
alloc_state->num_positional_areas = ah->area_count;
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
Always include debug mesg when cling to allocated is set.
2012-05-11 19:32:19 +04:00
if (alloc_parms->alloc == ALLOC_NORMAL || (alloc_parms->flags & A_CLING_TO_ALLOCED))
logging: classify log_debug messages Place most log_debug() messages into a class.
2013-01-08 02:30:29 +04:00
log_debug_alloc("Cling_to_allocated is %sset",
alloc_parms->flags & A_CLING_TO_ALLOCED ? "" : "not ");
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
alloc: Introduce A_POSITIONAL_FILL. Set A_POSITIONAL_FILL if the array of areas is being filled positionally (with a slot corresponding to each 'leg') rather than sequentially (with all suitable areas found, to be sorted and selected from).
2014-04-15 04:13:47 +04:00
if (alloc_parms->flags & A_POSITIONAL_FILL)
alloc: Fix lvextend failure when varying stripes. A segfault was reported when extending an LV with a smaller number of stripes than originally used. Under unusual circumstances, the cling detection code could successfully find a match against the excess stripe positions and think it had finished prematurely leading to an allocation being pursued with a length of zero. Rename ix_offset to num_positional_areas and move it to struct alloc_state so that _is_condition() can obtain access to it. In _is_condition(), areas_size can no longer be assumed to match the number of positional slots being filled so check this newly-exposed num_positional_areas directly instead. If the slot is outside the range we are trying to fill, just ignore the match for now. (Also note that the code still only performs cling detection against the first segment of the LV.)
2015-07-16 01:12:54 +03:00
log_debug_alloc("%u preferred area(s) to be filled positionally.", alloc_state->num_positional_areas);
alloc: Correct existing use of positional fill. Perform two allocation attempts with cling if maximise_cling is set, first with then without positional fill. Avoid segfaults from confusion between positional and sorted sequential allocation when number of stripes varies as reported here: https://www.redhat.com/archives/linux-lvm/2014-March/msg00001.html
2014-04-15 05:34:35 +04:00
else
log_debug_alloc("Areas to be sorted and filled sequentially.");
alloc: Introduce A_POSITIONAL_FILL. Set A_POSITIONAL_FILL if the array of areas is being filled positionally (with a slot corresponding to each 'leg') rather than sequentially (with all suitable areas found, to be sorted and selected from).
2014-04-15 04:13:47 +04:00
allocation: misc fixes for percent/raid rounding Several fixes for the recent changes that treat allocation percentages as upper limits. Improve messages to make it easier to see what is happening. Fix some cases that failed with errors when they didn't need to. Fix crashes when first_seg() returns NULL. Remove a couple of log_errors that were actually debugging messages.
2014-02-22 04:26:01 +04:00
_report_needed_allocation_space(ah, alloc_state, pvms);
o Striped allocator o Changed pv_map.c to maintain the list of free areas in size order, which is more helpful to the allocators. If you want to allocate a bit of an area call consume_area(area, size), this will adjust the area if there's some space left and shuffle it to the correct place in the list. Not tested.
2001-11-29 21:45:35 +03:00
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
/* ix holds the number of areas found on other PVs */
do {
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
if (log_iteration_count) {
logging: classify log_debug messages Place most log_debug() messages into a class.
2013-01-08 02:30:29 +04:00
log_debug_alloc("Found %u areas for %" PRIu32 " parallel areas and %" PRIu32 " log areas so far.", ix, devices_needed, alloc_state->log_area_count_still_needed);
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
} else if (iteration_count)
alloc: Fix lvextend failure when varying stripes. A segfault was reported when extending an LV with a smaller number of stripes than originally used. Under unusual circumstances, the cling detection code could successfully find a match against the excess stripe positions and think it had finished prematurely leading to an allocation being pursued with a length of zero. Rename ix_offset to num_positional_areas and move it to struct alloc_state so that _is_condition() can obtain access to it. In _is_condition(), areas_size can no longer be assumed to match the number of positional slots being filled so check this newly-exposed num_positional_areas directly instead. If the slot is outside the range we are trying to fill, just ignore the match for now. (Also note that the code still only performs cling detection against the first segment of the LV.)
2015-07-16 01:12:54 +03:00
log_debug_alloc("Filled %u out of %u preferred areas so far.", preferred_count, alloc_state->num_positional_areas);
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
/*
* Provide for escape from the loop if no progress is made.
* This should not happen: ALLOC_ANYWHERE should be able to use
* all available space. (If there aren't enough extents, the code
* should not reach this point.)
*/
last_ix = ix;
Determine parallel PVs to avoid with ALLOC_NORMAL allocation. (untested)
2005-11-28 23:01:00 +03:00
/*
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
* Put the smallest area of each PV that is at least the
* size we need into areas array. If there isn't one
* that fits completely and we're allowed more than one
* LV segment, then take the largest remaining instead.
Determine parallel PVs to avoid with ALLOC_NORMAL allocation. (untested)
2005-11-28 23:01:00 +03:00
*/
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
dm_list_iterate_items(pvm, pvms) {
/* PV-level checks */
if (dm_list_empty(&pvm->areas))
continue; /* Next PV */
if (alloc_parms->alloc != ALLOC_ANYWHERE) {
/* Don't allocate onto the log PVs */
if (ah->log_area_count)
dm_list_iterate_items(aa, &ah->alloced_areas[ah->area_count])
for (s = 0; s < ah->log_area_count; s++)
if (!aa[s].pv)
goto next_pv;
Fix several incorrect comparisons in parallel area avoidance code. Fix segment lengths when flattening existing parallel areas. Log existing parallel areas prior to allocation. Fix mirror log creation when activation disabled.
2006-09-11 18:24:58 +04:00
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
/* FIXME Split into log and non-log parallel_pvs and only check the log ones if log_iteration? */
/* (I've temporatily disabled the check.) */
/* Avoid PVs used by existing parallel areas */
alloc: Avoid PV tags too when avoiding parallel PV allocation. Also add debug messages for parallel PVs.
2016-08-24 21:37:50 +03:00
if (!log_iteration_count && parallel_pvs && _pv_is_parallel(pvm->pv, parallel_pvs, ah->cling_tag_list_cn))
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
goto next_pv;
/*
cleanup: spaces
2016-01-11 16:11:37 +03:00
* Avoid PVs already set aside for log.
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
* We only reach here if there were enough PVs for the main areas but
* not enough for the logs.
*/
if (log_iteration_count) {
alloc: Fix lvextend failure when varying stripes. A segfault was reported when extending an LV with a smaller number of stripes than originally used. Under unusual circumstances, the cling detection code could successfully find a match against the excess stripe positions and think it had finished prematurely leading to an allocation being pursued with a length of zero. Rename ix_offset to num_positional_areas and move it to struct alloc_state so that _is_condition() can obtain access to it. In _is_condition(), areas_size can no longer be assumed to match the number of positional slots being filled so check this newly-exposed num_positional_areas directly instead. If the slot is outside the range we are trying to fill, just ignore the match for now. (Also note that the code still only performs cling detection against the first segment of the LV.)
2015-07-16 01:12:54 +03:00
for (s = devices_needed; s < ix + alloc_state->num_positional_areas; s++)
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
if (alloc_state->areas[s].pva && alloc_state->areas[s].pva->map->pv == pvm->pv)
goto next_pv;
/* On a second pass, avoid PVs already used in an uncommitted area */
Start using 64-bit status flags - most of the code already handles them. tdata -> tpool remove commented out definitions from metadata.h formatting clean-ups
2011-09-06 22:49:31 +04:00
} else if (iteration_count)
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
for (s = 0; s < devices_needed; s++)
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
if (alloc_state->areas[s].pva && alloc_state->areas[s].pva->map->pv == pvm->pv)
goto next_pv;
Determine parallel PVs to avoid with ALLOC_NORMAL allocation. (untested)
2005-11-28 23:01:00 +03:00
}
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
already_found_one = 0;
/* First area in each list is the largest */
dm_list_iterate_items(pva, &pvm->areas) {
/*
alloc: fix lvextend when stripe number varies The PREFERRED allocation mechanism requires the number of areas in the previous LV segment to match the number in the new segment being allocated. If they do not match, the code may crash. E.g. https://bugzilla.redhat.com/989347 Introduce A_AREA_COUNT_MATCHES and when not set avoid referring to the previous segment with the contiguous and cling policies.
2013-07-29 22:35:45 +04:00
* There are two types of allocations, which can't be mixed at present:
*
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
* PREFERRED are stored immediately in a specific parallel slot.
alloc: Introduce A_POSITIONAL_FILL. Set A_POSITIONAL_FILL if the array of areas is being filled positionally (with a slot corresponding to each 'leg') rather than sequentially (with all suitable areas found, to be sorted and selected from).
2014-04-15 04:13:47 +04:00
* This is only used if the A_POSITIONAL_FILL flag is set.
alloc: fix lvextend when stripe number varies The PREFERRED allocation mechanism requires the number of areas in the previous LV segment to match the number in the new segment being allocated. If they do not match, the code may crash. E.g. https://bugzilla.redhat.com/989347 Introduce A_AREA_COUNT_MATCHES and when not set avoid referring to the previous segment with the contiguous and cling policies.
2013-07-29 22:35:45 +04:00
* This requires the number of slots to match, so if comparing with
* prev_lvseg then A_AREA_COUNT_MATCHES must be set.
*
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
* USE_AREA are stored for later, then sorted and chosen from.
*/
cleanup: spaces
2016-01-11 16:11:37 +03:00
switch(_check_pva(ah, pva, max_to_allocate,
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
alloc_state, already_found_one, iteration_count, log_iteration_count)) {
alloc avoids parallel pvs when supplied
2005-11-25 00:23:55 +03:00
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
case PREFERRED:
preferred_count++;
Add fall through comments Add comments to switch case construct.
2011-02-28 22:53:03 +03:00
/* Fall through */
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
case NEXT_PV:
goto next_pv;
o Striped allocator o Changed pv_map.c to maintain the list of free areas in size order, which is more helpful to the allocators. If you want to allocate a bit of an area call consume_area(area, size), this will adjust the area if there's some space left and shuffle it to the correct place in the list. Not tested.
2001-11-29 21:45:35 +03:00
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
case NEXT_AREA:
continue;
Introduce pv_area_used into allocation algorithm and add debug messages. This is the next preparatory step towards better --alloc anywhere support and is not intended to break anything that currently works so please report any problems - segfaults, bogus data in the new debug messages, or if the code now chooses bizarre allocation layouts.
2010-03-25 05:31:48 +03:00
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
case USE_AREA:
Allow ALLOC_ANYWHERE to split contiguous areas.
2010-03-26 00:19:26 +03:00
/*
* Except with ALLOC_ANYWHERE, replace first area with this
* one which is smaller but still big enough.
*/
if (!already_found_one ||
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
alloc_parms->alloc == ALLOC_ANYWHERE) {
Allow ALLOC_ANYWHERE to split contiguous areas.
2010-03-26 00:19:26 +03:00
ix++;
already_found_one = 1;
}
Introduce pv_area_used into allocation algorithm and add debug messages. This is the next preparatory step towards better --alloc anywhere support and is not intended to break anything that currently works so please report any problems - segfaults, bogus data in the new debug messages, or if the code now chooses bizarre allocation layouts.
2010-03-25 05:31:48 +03:00
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
/* Reserve required amount of pva */
alloc: Fix lvextend failure when varying stripes. A segfault was reported when extending an LV with a smaller number of stripes than originally used. Under unusual circumstances, the cling detection code could successfully find a match against the excess stripe positions and think it had finished prematurely leading to an allocation being pursued with a length of zero. Rename ix_offset to num_positional_areas and move it to struct alloc_state so that _is_condition() can obtain access to it. In _is_condition(), areas_size can no longer be assumed to match the number of positional slots being filled so check this newly-exposed num_positional_areas directly instead. If the slot is outside the range we are trying to fill, just ignore the match for now. (Also note that the code still only performs cling detection against the first segment of the LV.)
2015-07-16 01:12:54 +03:00
required = _calc_required_extents(ah, pva, ix + alloc_state->num_positional_areas - 1, max_to_allocate, alloc_parms->alloc);
if (!_reserve_required_area(ah, alloc_state, pva, required, ix + alloc_state->num_positional_areas - 1, pva->unreserved))
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
return_0;
Allow dynamic extension of array of areas selected as allocation candidates.
2010-03-23 18:07:55 +03:00
}
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
Start merging cloned allocation functions.
2005-05-17 17:49:45 +04:00
}
o Striped allocator o Changed pv_map.c to maintain the list of free areas in size order, which is more helpful to the allocators. If you want to allocate a bit of an area call consume_area(area, size), this will adjust the area if there's some space left and shuffle it to the correct place in the list. Not tested.
2001-11-29 21:45:35 +03:00
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
next_pv:
/* With ALLOC_ANYWHERE we ignore further PVs once we have at least enough areas */
/* With cling and contiguous we stop if we found a match for *all* the areas */
/* FIXME Rename these variables! */
if ((alloc_parms->alloc == ALLOC_ANYWHERE &&
alloc: Fix lvextend failure when varying stripes. A segfault was reported when extending an LV with a smaller number of stripes than originally used. Under unusual circumstances, the cling detection code could successfully find a match against the excess stripe positions and think it had finished prematurely leading to an allocation being pursued with a length of zero. Rename ix_offset to num_positional_areas and move it to struct alloc_state so that _is_condition() can obtain access to it. In _is_condition(), areas_size can no longer be assumed to match the number of positional slots being filled so check this newly-exposed num_positional_areas directly instead. If the slot is outside the range we are trying to fill, just ignore the match for now. (Also note that the code still only performs cling detection against the first segment of the LV.)
2015-07-16 01:12:54 +03:00
ix + alloc_state->num_positional_areas >= devices_needed + alloc_state->log_area_count_still_needed) ||
(preferred_count == alloc_state->num_positional_areas &&
(alloc_state->num_positional_areas == devices_needed + alloc_state->log_area_count_still_needed)))
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
break;
}
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
} while ((alloc_parms->alloc == ALLOC_ANYWHERE && last_ix != ix && ix < devices_needed + alloc_state->log_area_count_still_needed) ||
Fix cling policy not to behave like normal policy if no previous LV seg. Fix alloc cling to cling to PVs already found with contiguous policy.
2012-05-12 02:53:13 +04:00
/* With cling_to_alloced and normal, if there were gaps in the preferred areas, have a second iteration */
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
(alloc_parms->alloc == ALLOC_NORMAL && preferred_count &&
alloc: Fix lvextend failure when varying stripes. A segfault was reported when extending an LV with a smaller number of stripes than originally used. Under unusual circumstances, the cling detection code could successfully find a match against the excess stripe positions and think it had finished prematurely leading to an allocation being pursued with a length of zero. Rename ix_offset to num_positional_areas and move it to struct alloc_state so that _is_condition() can obtain access to it. In _is_condition(), areas_size can no longer be assumed to match the number of positional slots being filled so check this newly-exposed num_positional_areas directly instead. If the slot is outside the range we are trying to fill, just ignore the match for now. (Also note that the code still only performs cling detection against the first segment of the LV.)
2015-07-16 01:12:54 +03:00
(preferred_count < alloc_state->num_positional_areas || alloc_state->log_area_count_still_needed) &&
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
(alloc_parms->flags & A_CLING_TO_ALLOCED) && !iteration_count++) ||
/* Extra iteration needed to fill log areas on PVs already used? */
alloc: Fix lvextend failure when varying stripes. A segfault was reported when extending an LV with a smaller number of stripes than originally used. Under unusual circumstances, the cling detection code could successfully find a match against the excess stripe positions and think it had finished prematurely leading to an allocation being pursued with a length of zero. Rename ix_offset to num_positional_areas and move it to struct alloc_state so that _is_condition() can obtain access to it. In _is_condition(), areas_size can no longer be assumed to match the number of positional slots being filled so check this newly-exposed num_positional_areas directly instead. If the slot is outside the range we are trying to fill, just ignore the match for now. (Also note that the code still only performs cling detection against the first segment of the LV.)
2015-07-16 01:12:54 +03:00
(alloc_parms->alloc == ALLOC_NORMAL && preferred_count == alloc_state->num_positional_areas && !ah->mirror_logs_separate &&
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
(ix + preferred_count >= devices_needed) &&
(ix + preferred_count < devices_needed + alloc_state->log_area_count_still_needed) && !log_iteration_count++));
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
alloc: Correct existing use of positional fill. Perform two allocation attempts with cling if maximise_cling is set, first with then without positional fill. Avoid segfaults from confusion between positional and sorted sequential allocation when number of stripes varies as reported here: https://www.redhat.com/archives/linux-lvm/2014-March/msg00001.html
2014-04-15 05:34:35 +04:00
/* Non-zero ix means at least one USE_AREA was returned */
alloc: Fix lvextend failure when varying stripes. A segfault was reported when extending an LV with a smaller number of stripes than originally used. Under unusual circumstances, the cling detection code could successfully find a match against the excess stripe positions and think it had finished prematurely leading to an allocation being pursued with a length of zero. Rename ix_offset to num_positional_areas and move it to struct alloc_state so that _is_condition() can obtain access to it. In _is_condition(), areas_size can no longer be assumed to match the number of positional slots being filled so check this newly-exposed num_positional_areas directly instead. If the slot is outside the range we are trying to fill, just ignore the match for now. (Also note that the code still only performs cling detection against the first segment of the LV.)
2015-07-16 01:12:54 +03:00
if (preferred_count < alloc_state->num_positional_areas && !(alloc_parms->flags & A_CLING_TO_ALLOCED) && !ix)
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
return 1;
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
if (ix + preferred_count < devices_needed + alloc_state->log_area_count_still_needed)
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
return 1;
/* Sort the areas so we allocate from the biggest */
if (log_iteration_count) {
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
if (ix > devices_needed + 1) {
logging: classify log_debug messages Place most log_debug() messages into a class.
2013-01-08 02:30:29 +04:00
log_debug_alloc("Sorting %u log areas", ix - devices_needed);
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
qsort(alloc_state->areas + devices_needed, ix - devices_needed, sizeof(*alloc_state->areas),
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
_comp_area);
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
}
} else if (ix > 1) {
logging: classify log_debug messages Place most log_debug() messages into a class.
2013-01-08 02:30:29 +04:00
log_debug_alloc("Sorting %u areas", ix);
alloc: Fix lvextend failure when varying stripes. A segfault was reported when extending an LV with a smaller number of stripes than originally used. Under unusual circumstances, the cling detection code could successfully find a match against the excess stripe positions and think it had finished prematurely leading to an allocation being pursued with a length of zero. Rename ix_offset to num_positional_areas and move it to struct alloc_state so that _is_condition() can obtain access to it. In _is_condition(), areas_size can no longer be assumed to match the number of positional slots being filled so check this newly-exposed num_positional_areas directly instead. If the slot is outside the range we are trying to fill, just ignore the match for now. (Also note that the code still only performs cling detection against the first segment of the LV.)
2015-07-16 01:12:54 +03:00
qsort(alloc_state->areas + alloc_state->num_positional_areas, ix, sizeof(*alloc_state->areas),
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
_comp_area);
}
alloc: Add A_PARTITION_BY_TAGS to avoid sharing. Add A_PARTITION_BY_TAGS set when allocated areas should not share tags with each other and allow _match_pv_tags to accept an alternative list of tags. (Not used yet.)
2015-04-10 23:57:52 +03:00
/* If there are gaps in our preferred areas, fill them from the sorted part of the array */
alloc: Fix lvextend failure when varying stripes. A segfault was reported when extending an LV with a smaller number of stripes than originally used. Under unusual circumstances, the cling detection code could successfully find a match against the excess stripe positions and think it had finished prematurely leading to an allocation being pursued with a length of zero. Rename ix_offset to num_positional_areas and move it to struct alloc_state so that _is_condition() can obtain access to it. In _is_condition(), areas_size can no longer be assumed to match the number of positional slots being filled so check this newly-exposed num_positional_areas directly instead. If the slot is outside the range we are trying to fill, just ignore the match for now. (Also note that the code still only performs cling detection against the first segment of the LV.)
2015-07-16 01:12:54 +03:00
if (preferred_count && preferred_count != alloc_state->num_positional_areas) {
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
for (s = 0; s < devices_needed; s++)
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
if (!alloc_state->areas[s].pva) {
alloc: Fix lvextend failure when varying stripes. A segfault was reported when extending an LV with a smaller number of stripes than originally used. Under unusual circumstances, the cling detection code could successfully find a match against the excess stripe positions and think it had finished prematurely leading to an allocation being pursued with a length of zero. Rename ix_offset to num_positional_areas and move it to struct alloc_state so that _is_condition() can obtain access to it. In _is_condition(), areas_size can no longer be assumed to match the number of positional slots being filled so check this newly-exposed num_positional_areas directly instead. If the slot is outside the range we are trying to fill, just ignore the match for now. (Also note that the code still only performs cling detection against the first segment of the LV.)
2015-07-16 01:12:54 +03:00
alloc_state->areas[s].pva = alloc_state->areas[alloc_state->num_positional_areas].pva;
alloc_state->areas[s].used = alloc_state->areas[alloc_state->num_positional_areas].used;
alloc_state->areas[alloc_state->num_positional_areas++].pva = NULL;
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
}
}
lvresize: separate validation from action Start separating the validation from the action in the basic lvresize code moved to the library. Remove incorrect use of command line error codes from lvresize library functions. Move errors.h to tools directory to reinforce this, exporting public versions of the error codes in lvm2cmd.h for dmeventd plugins to use.
2013-07-06 06:28:21 +04:00
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
/*
* First time around, if there's a log, allocate it on the
* smallest device that has space for it.
*/
too_small_for_log_count = 0;
ix_log_offset = 0;
/* FIXME This logic is due to its heritage and can be simplified! */
if (alloc_state->log_area_count_still_needed) {
/* How many areas are too small for the log? */
alloc: Fix lvextend failure when varying stripes. A segfault was reported when extending an LV with a smaller number of stripes than originally used. Under unusual circumstances, the cling detection code could successfully find a match against the excess stripe positions and think it had finished prematurely leading to an allocation being pursued with a length of zero. Rename ix_offset to num_positional_areas and move it to struct alloc_state so that _is_condition() can obtain access to it. In _is_condition(), areas_size can no longer be assumed to match the number of positional slots being filled so check this newly-exposed num_positional_areas directly instead. If the slot is outside the range we are trying to fill, just ignore the match for now. (Also note that the code still only performs cling detection against the first segment of the LV.)
2015-07-16 01:12:54 +03:00
while (too_small_for_log_count < alloc_state->num_positional_areas + ix &&
(*(alloc_state->areas + alloc_state->num_positional_areas + ix - 1 -
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
too_small_for_log_count)).used < ah->log_len)
too_small_for_log_count++;
allocation: add check for passing log allocation Updates previous commit.
2018-07-09 01:54:16 +03:00
if (ah->mirror_logs_separate &&
too_small_for_log_count &&
(too_small_for_log_count >= devices_needed))
allocator: fix thin-pool allocation When allocating thin-pool with more then 1 device - try to allocate 'metadataLV' with reuse of log-type allocation for mirror LV. It should be naturally place on other device then 'dataLV'. However due to somewhat hard to follow allocation logic code, it's been rejected allocation in cases where there was not enough space for data or metadata on single PV, thus to successed, usage of segments was mandatory. While user may use: allocation/thin_pool_metadata_require_separate_pvs=1 to enforce separe meta and data LV - on default settings, this is not enable thus segment allocation is meant to work. NOTE: As already said - the original intention of this whole 'if()' is unclear, so try to split this test into multiple more simple tests that are more readable. TODO: more validation.
2018-07-08 19:34:38 +03:00
return 1;
if ((alloc_state->num_positional_areas + ix) < (too_small_for_log_count + ah->log_area_count))
return 1;
ix_log_offset = alloc_state->num_positional_areas + ix - (too_small_for_log_count + ah->log_area_count);
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
}
allocator: fix thin-pool allocation When allocating thin-pool with more then 1 device - try to allocate 'metadataLV' with reuse of log-type allocation for mirror LV. It should be naturally place on other device then 'dataLV'. However due to somewhat hard to follow allocation logic code, it's been rejected allocation in cases where there was not enough space for data or metadata on single PV, thus to successed, usage of segments was mandatory. While user may use: allocation/thin_pool_metadata_require_separate_pvs=1 to enforce separe meta and data LV - on default settings, this is not enable thus segment allocation is meant to work. NOTE: As already said - the original intention of this whole 'if()' is unclear, so try to split this test into multiple more simple tests that are more readable. TODO: more validation.
2018-07-08 19:34:38 +03:00
if (ix + alloc_state->num_positional_areas < devices_needed)
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
return 1;
alloc: Respect cling_tag_list in contig alloc. When performing initial allocation (so there is nothing yet to cling to), use the list of tags in allocation/cling_tag_list to partition the PVs. We implement this by maintaining a list of tags that have been "used up" as we proceed and ignoring further devices that have a tag on the list. https://bugzilla.redhat.com/983600
2015-04-11 03:55:24 +03:00
/*
cleanup: spaces
2016-01-11 16:11:37 +03:00
* FIXME We should change the code to do separate calls for the log allocation
alloc: Respect cling_tag_list in contig alloc. When performing initial allocation (so there is nothing yet to cling to), use the list of tags in allocation/cling_tag_list to partition the PVs. We implement this by maintaining a list of tags that have been "used up" as we proceed and ignoring further devices that have a tag on the list. https://bugzilla.redhat.com/983600
2015-04-11 03:55:24 +03:00
* and the data allocation so that _limit_to_one_area_per_tag doesn't have to guess
* where the split is going to occur.
*/
/*
* This code covers the initial allocation - after that there is something to 'cling' to
* and we shouldn't get this far.
alloc: Fix lvextend failure when varying stripes. A segfault was reported when extending an LV with a smaller number of stripes than originally used. Under unusual circumstances, the cling detection code could successfully find a match against the excess stripe positions and think it had finished prematurely leading to an allocation being pursued with a length of zero. Rename ix_offset to num_positional_areas and move it to struct alloc_state so that _is_condition() can obtain access to it. In _is_condition(), areas_size can no longer be assumed to match the number of positional slots being filled so check this newly-exposed num_positional_areas directly instead. If the slot is outside the range we are trying to fill, just ignore the match for now. (Also note that the code still only performs cling detection against the first segment of the LV.)
2015-07-16 01:12:54 +03:00
* alloc_state->num_positional_areas is assumed to be 0 with A_PARTITION_BY_TAGS.
alloc: Respect cling_tag_list in contig alloc. When performing initial allocation (so there is nothing yet to cling to), use the list of tags in allocation/cling_tag_list to partition the PVs. We implement this by maintaining a list of tags that have been "used up" as we proceed and ignoring further devices that have a tag on the list. https://bugzilla.redhat.com/983600
2015-04-11 03:55:24 +03:00
*
* FIXME Consider a second attempt with A_PARTITION_BY_TAGS if, for example, the largest area
* had all the tags set, but other areas don't.
*/
alloc: Fix lvextend failure when varying stripes. A segfault was reported when extending an LV with a smaller number of stripes than originally used. Under unusual circumstances, the cling detection code could successfully find a match against the excess stripe positions and think it had finished prematurely leading to an allocation being pursued with a length of zero. Rename ix_offset to num_positional_areas and move it to struct alloc_state so that _is_condition() can obtain access to it. In _is_condition(), areas_size can no longer be assumed to match the number of positional slots being filled so check this newly-exposed num_positional_areas directly instead. If the slot is outside the range we are trying to fill, just ignore the match for now. (Also note that the code still only performs cling detection against the first segment of the LV.)
2015-07-16 01:12:54 +03:00
if ((alloc_parms->flags & A_PARTITION_BY_TAGS) && !alloc_state->num_positional_areas) {
alloc: Respect cling_tag_list in contig alloc. When performing initial allocation (so there is nothing yet to cling to), use the list of tags in allocation/cling_tag_list to partition the PVs. We implement this by maintaining a list of tags that have been "used up" as we proceed and ignoring further devices that have a tag on the list. https://bugzilla.redhat.com/983600
2015-04-11 03:55:24 +03:00
if (!_limit_to_one_area_per_tag(ah, alloc_state, ix_log_offset, &ix))
return_0;
/* Recalculate log position because we might have removed some areas from consideration */
if (alloc_state->log_area_count_still_needed) {
/* How many areas are too small for the log? */
too_small_for_log_count = 0;
while (too_small_for_log_count < ix &&
(*(alloc_state->areas + ix - 1 - too_small_for_log_count)).pva &&
(*(alloc_state->areas + ix - 1 - too_small_for_log_count)).used < ah->log_len)
too_small_for_log_count++;
if (ix < too_small_for_log_count + ah->log_area_count)
return 1;
ix_log_offset = ix - too_small_for_log_count - ah->log_area_count;
}
if (ix < devices_needed +
(alloc_state->log_area_count_still_needed ? alloc_state->log_area_count_still_needed +
too_small_for_log_count : 0))
return 1;
}
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
/*
* Finally add the space identified to the list of areas to be used.
*/
if (!_alloc_parallel_area(ah, max_to_allocate, alloc_state, ix_log_offset))
return_0;
/*
* Log is always allocated first time.
*/
alloc_state->log_area_count_still_needed = 0;
return 1;
}
/*
cleanup: spaces
2016-01-11 16:11:37 +03:00
* Choose sets of parallel areas to use, respecting any constraints
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
* supplied in alloc_parms.
*/
static int _find_max_parallel_space_for_one_policy(struct alloc_handle *ah, struct alloc_parms *alloc_parms,
struct dm_list *pvms, struct alloc_state *alloc_state)
{
Add support for m-way to n-way up-convert in RAID1 (no linear to n-way yet) This patch adds the ability to upconvert a raid1 array - say from 2-way to 3-way. It does not yet support upconverting linear to n-way. The 'raid' device-mapper target allows for individual components (images) of an array to be specified for rebuild. This mechanism is used when adding new images to the array so that the new images can be resync'ed while the rest of the images in the array can remain 'in-sync'. (There is no mirror-on-mirror layering required.)
2011-08-18 23:41:21 +04:00
uint32_t max_tmp;
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
uint32_t max_to_allocate; /* Maximum extents to allocate this time */
uint32_t old_allocated;
uint32_t next_le;
struct seg_pvs *spvs;
struct dm_list *parallel_pvs;
alloc: Access alloc_parms from alloc_state. alloc_parms is constant while allocating.
2014-04-15 04:05:34 +04:00
alloc_state->alloc_parms = alloc_parms;
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
/* FIXME This algorithm needs a lot of cleaning up! */
/* FIXME anywhere doesn't find all space yet */
do {
parallel_pvs = NULL;
max_to_allocate = alloc_parms->extents_still_needed - alloc_state->allocated;
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
Handle multi-extent mirror log allocation when smallest PV has only 1 extent.
2009-05-30 04:09:27 +04:00
/*
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
* If there are existing parallel PVs, avoid them and reduce
* the maximum we can allocate in one go accordingly.
Handle multi-extent mirror log allocation when smallest PV has only 1 extent.
2009-05-30 04:09:27 +04:00
*/
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
if (ah->parallel_areas) {
next_le = (alloc_parms->prev_lvseg ? alloc_parms->prev_lvseg->le + alloc_parms->prev_lvseg->len : 0) + alloc_state->allocated / ah->area_multiple;
dm_list_iterate_items(spvs, ah->parallel_areas) {
if (next_le >= spvs->le + spvs->len)
continue;
Add support for m-way to n-way up-convert in RAID1 (no linear to n-way yet) This patch adds the ability to upconvert a raid1 array - say from 2-way to 3-way. It does not yet support upconverting linear to n-way. The 'raid' device-mapper target allows for individual components (images) of an array to be specified for rebuild. This mechanism is used when adding new images to the array so that the new images can be resync'ed while the rest of the images in the array can remain 'in-sync'. (There is no mirror-on-mirror layering required.)
2011-08-18 23:41:21 +04:00
max_tmp = max_to_allocate +
alloc_state->allocated;
/*
* Because a request that groups metadata and
* data together will be split, we must adjust
* the comparison accordingly.
*/
allocation: misc fixes for percent/raid rounding Several fixes for the recent changes that treat allocation percentages as upper limits. Improve messages to make it easier to see what is happening. Fix some cases that failed with errors when they didn't need to. Fix crashes when first_seg() returns NULL. Remove a couple of log_errors that were actually debugging messages.
2014-02-22 04:26:01 +04:00
if (ah->alloc_and_split_meta && !ah->split_metadata_is_allocated)
Add support for m-way to n-way up-convert in RAID1 (no linear to n-way yet) This patch adds the ability to upconvert a raid1 array - say from 2-way to 3-way. It does not yet support upconverting linear to n-way. The 'raid' device-mapper target allows for individual components (images) of an array to be specified for rebuild. This mechanism is used when adding new images to the array so that the new images can be resync'ed while the rest of the images in the array can remain 'in-sync'. (There is no mirror-on-mirror layering required.)
2011-08-18 23:41:21 +04:00
max_tmp -= ah->log_len;
if (max_tmp > (spvs->le + spvs->len) * ah->area_multiple) {
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
max_to_allocate = (spvs->le + spvs->len) * ah->area_multiple - alloc_state->allocated;
allocation: misc fixes for percent/raid rounding Several fixes for the recent changes that treat allocation percentages as upper limits. Improve messages to make it easier to see what is happening. Fix some cases that failed with errors when they didn't need to. Fix crashes when first_seg() returns NULL. Remove a couple of log_errors that were actually debugging messages.
2014-02-22 04:26:01 +04:00
max_to_allocate += (ah->alloc_and_split_meta && !ah->split_metadata_is_allocated) ? ah->log_len : 0;
Add support for m-way to n-way up-convert in RAID1 (no linear to n-way yet) This patch adds the ability to upconvert a raid1 array - say from 2-way to 3-way. It does not yet support upconverting linear to n-way. The 'raid' device-mapper target allows for individual components (images) of an array to be specified for rebuild. This mechanism is used when adding new images to the array so that the new images can be resync'ed while the rest of the images in the array can remain 'in-sync'. (There is no mirror-on-mirror layering required.)
2011-08-18 23:41:21 +04:00
}
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
parallel_pvs = &spvs->pvs;
break;
}
Handle multi-extent mirror log allocation when smallest PV has only 1 extent.
2009-05-30 04:09:27 +04:00
}
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
old_allocated = alloc_state->allocated;
Handle multi-extent mirror log allocation when smallest PV has only 1 extent.
2009-05-30 04:09:27 +04:00
alloc: Access alloc_parms from alloc_state. alloc_parms is constant while allocating.
2014-04-15 04:05:34 +04:00
if (!_find_some_parallel_space(ah, pvms, alloc_state, parallel_pvs, max_to_allocate))
Use stack return macros throughout.
2008-01-30 16:19:47 +03:00
return_0;
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
/*
alloc: Correct existing use of positional fill. Perform two allocation attempts with cling if maximise_cling is set, first with then without positional fill. Avoid segfaults from confusion between positional and sorted sequential allocation when number of stripes varies as reported here: https://www.redhat.com/archives/linux-lvm/2014-March/msg00001.html
2014-04-15 05:34:35 +04:00
* For ALLOC_CLING, if the number of areas matches and maximise_cling is
* set we allow two passes, first with A_POSITIONAL_FILL then without.
*
Fix cling policy not to behave like normal policy if no previous LV seg. Fix alloc cling to cling to PVs already found with contiguous policy.
2012-05-12 02:53:13 +04:00
* If we didn't allocate anything this time with ALLOC_NORMAL and had
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
* A_CLING_TO_ALLOCED set, try again without it.
*
* For ALLOC_NORMAL, if we did allocate something without the
* flag set, set it and continue so that further allocations
* remain on the same disks where possible.
*/
if (old_allocated == alloc_state->allocated) {
alloc: Correct existing use of positional fill. Perform two allocation attempts with cling if maximise_cling is set, first with then without positional fill. Avoid segfaults from confusion between positional and sorted sequential allocation when number of stripes varies as reported here: https://www.redhat.com/archives/linux-lvm/2014-March/msg00001.html
2014-04-15 05:34:35 +04:00
if (ah->maximise_cling && ((alloc_parms->alloc == ALLOC_CLING) || (alloc_parms->alloc == ALLOC_CLING_BY_TAGS)) &&
(alloc_parms->flags & A_CLING_TO_LVSEG) && (alloc_parms->flags & A_POSITIONAL_FILL))
alloc_parms->flags &= ~A_POSITIONAL_FILL;
else if ((alloc_parms->alloc == ALLOC_NORMAL) && (alloc_parms->flags & A_CLING_TO_ALLOCED))
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
alloc_parms->flags &= ~A_CLING_TO_ALLOCED;
else
break; /* Give up */
} else if (ah->maximise_cling && alloc_parms->alloc == ALLOC_NORMAL &&
!(alloc_parms->flags & A_CLING_TO_ALLOCED))
alloc_parms->flags |= A_CLING_TO_ALLOCED;
allocation: misc fixes for percent/raid rounding Several fixes for the recent changes that treat allocation percentages as upper limits. Improve messages to make it easier to see what is happening. Fix some cases that failed with errors when they didn't need to. Fix crashes when first_seg() returns NULL. Remove a couple of log_errors that were actually debugging messages.
2014-02-22 04:26:01 +04:00
} while ((alloc_parms->alloc != ALLOC_CONTIGUOUS) && alloc_state->allocated != alloc_parms->extents_still_needed && (alloc_parms->flags & A_CAN_SPLIT) && (!ah->approx_alloc || pv_maps_size(pvms)));
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
return 1;
}
/*
* Allocate several segments, each the same size, in parallel.
* If mirrored_pv and mirrored_pe are supplied, it is used as
* the first area, and additional areas are allocated parallel to it.
*/
static int _allocate(struct alloc_handle *ah,
struct volume_group *vg,
Clean up numerous compiler warnings that crept in recently. Remove several unused parameters from _allocate().
2007-08-22 18:38:18 +04:00
struct logical_volume *lv,
export can_split parameter until rest of pvmove allocation restructuring gets done
2007-12-06 01:11:20 +03:00
unsigned can_split,
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
struct dm_list *allocatable_pvs)
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
{
uint32_t old_allocated;
struct lv_segment *prev_lvseg = NULL;
int r = 0;
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
struct dm_list *pvms;
When lvconvert allocates a mirror log, respect parallel area constraints. Use loop to iterate through the now-ordered policy list in _allocate(). Check for failure to allocate just the mirror log. Introduce calc_area_multiple(). Support mirror log allocation when there is only one PV: area_count now 0. (See lvm-devel list archives for further details.)
2006-12-13 06:39:58 +03:00
alloc_policy_t alloc;
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
struct alloc_parms alloc_parms;
struct alloc_state alloc_state;
alloc_state.allocated = lv ? lv->le_count : 0;
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
if (alloc_state.allocated >= ah->new_extents && !ah->log_area_count) {
cleanup: switch log_error to log_warn Use log_warn to print non-fatal warning messages. Use of log_error would confuse checker for testing whether proper error has been reported for some real error.
2012-10-16 12:14:41 +04:00
log_warn("_allocate called with no work to do!");
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
return 1;
}
Fix the divisibility check in the allocator for the mirror+stripe case (require divisibility by stripe count alone, not by (mirror*stripe)).
2011-09-16 13:59:42 +04:00
if (ah->area_multiple > 1 &&
(ah->new_extents - alloc_state.allocated) % ah->area_multiple) {
style: Miscellaneous tidying up of metadata/lv*
2015-09-23 16:37:52 +03:00
log_error("Number of extents requested (" FMTu32 ") needs to be divisible by " FMTu32 ".",
Fix the divisibility check in the allocator for the mirror+stripe case (require divisibility by stripe count alone, not by (mirror*stripe)).
2011-09-16 13:59:42 +04:00
ah->new_extents - alloc_state.allocated,
ah->area_multiple);
Fail allocation if number of extents not divisible by area count Allocation should fail early if this condition is not met. Quick fix for https://bugzilla.redhat.com/show_bug.cgi?id=707779
2011-06-23 14:53:24 +04:00
return 0;
}
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
alloc_state.log_area_count_still_needed = ah->log_area_count;
Introduce pv_area_used into allocation algorithm and add debug messages. This is the next preparatory step towards better --alloc anywhere support and is not intended to break anything that currently works so please report any problems - segfaults, bogus data in the new debug messages, or if the code now chooses bizarre allocation layouts.
2010-03-25 05:31:48 +03:00
drop mirrored_pv/mirrored_pe from alloc handle
2007-11-22 17:54:35 +03:00
if (ah->alloc == ALLOC_CONTIGUOUS)
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
can_split = 0;
cleanup: use last_seg More readable code.
2018-07-07 22:35:07 +03:00
if (lv)
prev_lvseg = last_seg(lv);
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
/*
* Build the sets of available areas on the pv's.
*/
Use stack return macros throughout.
2008-01-30 16:19:47 +03:00
if (!(pvms = create_pv_maps(ah->mem, vg, allocatable_pvs)))
return_0;
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
alloc: Record PV tags of parallel PVs in log.
2016-08-24 17:49:34 +03:00
if (!_log_parallel_areas(ah->mem, ah->parallel_areas, ah->cling_tag_list_cn))
Fix several incorrect comparisons in parallel area avoidance code. Fix segment lengths when flattening existing parallel areas. Log existing parallel areas prior to allocation. Fix mirror log creation when activation disabled.
2006-09-11 18:24:58 +04:00
stack;
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
alloc_state.areas_size = dm_list_size(pvms);
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
if (alloc_state.areas_size &&
alloc_state.areas_size < (ah->area_count + ah->parity_count + ah->log_area_count)) {
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
if (ah->alloc != ALLOC_ANYWHERE && ah->mirror_logs_separate) {
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
log_error("Not enough PVs with free space available "
"for parallel allocation.");
log_error("Consider --alloc anywhere if desperate.");
return 0;
}
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
alloc_state.areas_size = ah->area_count + ah->parity_count + ah->log_area_count;
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
}
Extend allocation areas to avoid overflow with contiguous with other PVs. Another pvmove fix.
2005-11-10 17:45:39 +03:00
/* Upper bound if none of the PVs in prev_lvseg is in pvms */
/* FIXME Work size out properly */
if (prev_lvseg)
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
alloc_state.areas_size += _stripes_per_mimage(prev_lvseg) * prev_lvseg->area_count;
Extend allocation areas to avoid overflow with contiguous with other PVs. Another pvmove fix.
2005-11-10 17:45:39 +03:00
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
/* Allocate an array of pv_areas to hold the largest space on each PV */
device_mapper: remove dbg_malloc. I wrote dbg_malloc before we had valgrind. These days there's just no need.
2018-06-08 15:40:53 +03:00
if (!(alloc_state.areas = malloc(sizeof(*alloc_state.areas) * alloc_state.areas_size))) {
Use log_error macro consistently throughout in place of log_err.
2009-07-16 00:02:46 +04:00
log_error("Couldn't allocate areas array.");
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
return 0;
}
Extend cling allocation policy to recognise PV tags (cling_by_tags). Add allocation/cling_tag_list to lvm.conf.
2010-11-09 15:34:40 +03:00
/*
* cling includes implicit cling_by_tags
* but it does nothing unless the lvm.conf setting is present.
*/
if (ah->alloc == ALLOC_CLING)
ah->alloc = ALLOC_CLING_BY_TAGS;
When lvconvert allocates a mirror log, respect parallel area constraints. Use loop to iterate through the now-ordered policy list in _allocate(). Check for failure to allocate just the mirror log. Introduce calc_area_multiple(). Support mirror log allocation when there is only one PV: area_count now 0. (See lvm-devel list archives for further details.)
2006-12-13 06:39:58 +03:00
/* Attempt each defined allocation policy in turn */
Fix allocation policy loop so it doesn't continue beyond cling using later policies it shouldn't be using when --alloc cling is specified but no tags are defined.
2012-05-12 02:19:12 +04:00
for (alloc = ALLOC_CONTIGUOUS; alloc <= ah->alloc; alloc++) {
Extend cling allocation policy to recognise PV tags (cling_by_tags). Add allocation/cling_tag_list to lvm.conf.
2010-11-09 15:34:40 +03:00
/* Skip cling_by_tags if no list defined */
if (alloc == ALLOC_CLING_BY_TAGS && !ah->cling_tag_list_cn)
continue;
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
old_allocated = alloc_state.allocated;
logging: classify log_debug messages Place most log_debug() messages into a class.
2013-01-08 02:30:29 +04:00
log_debug_alloc("Trying allocation using %s policy.", get_alloc_string(alloc));
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
alloc: enhance estimation of sufficient_pes_free Since commit 77fdc17d70e62cab75efaaf0dad02493b948610d always include log_len size into needed extents - however now we may need sometimes more extents then necessary - mainly when multiple PVs are involved into allocation. Add logs_still_needed into calculation of sufficient_pes_free()
2021-01-12 17:58:07 +03:00
if (!ah->approx_alloc && !_sufficient_pes_free(ah, pvms, alloc_state.allocated,
alloc_state.log_area_count_still_needed,
ah->new_extents))
When lvconvert allocates a mirror log, respect parallel area constraints. Use loop to iterate through the now-ordered policy list in _allocate(). Check for failure to allocate just the mirror log. Introduce calc_area_multiple(). Support mirror log allocation when there is only one PV: area_count now 0. (See lvm-devel list archives for further details.)
2006-12-13 06:39:58 +03:00
goto_out;
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
_init_alloc_parms(ah, &alloc_parms, alloc, prev_lvseg,
can_split, alloc_state.allocated,
ah->new_extents);
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
if (!_find_max_parallel_space_for_one_policy(ah, &alloc_parms, pvms, &alloc_state))
goto_out;
alloc: Use --alloc normal for mirror logs. The existing code doesn't understand that mirror logs should cling to parallel LVs (like extending them) instead of avoiding them. As a quick workaround to avoid lvcreate failures, hard-code --alloc normal for mirror logs even if the rest of the allocation used a stricter policy. https://bugzilla.redhat.com/show_bug.cgi?id=1376532
2016-09-16 04:11:58 +03:00
/* As a workaround, if only the log is missing now, fall through and try later policies up to normal. */
/* FIXME Change the core algorithm so the log extents cling to parallel LVs instead of avoiding them. */
if (alloc_state.allocated == ah->new_extents &&
alloc_state.log_area_count_still_needed &&
ah->alloc < ALLOC_NORMAL) {
ah->alloc = ALLOC_NORMAL;
continue;
}
allocation: Allow approximate allocation when specifying size in percent Introduce a new parameter called "approx_alloc" that is set when the desired size of a new LV is specified in percentage terms. If set, the allocation code tries to get as much space as it can but does not fail if can at least get some. One of the practical implications is that users can now specify 100%FREE when creating RAID LVs, like this: ~> lvcreate --type raid5 -i 2 -l 100%FREE -n lv vg
2014-02-14 07:10:28 +04:00
if ((alloc_state.allocated == ah->new_extents &&
!alloc_state.log_area_count_still_needed) ||
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
(!can_split && (alloc_state.allocated != old_allocated)))
When lvconvert allocates a mirror log, respect parallel area constraints. Use loop to iterate through the now-ordered policy list in _allocate(). Check for failure to allocate just the mirror log. Introduce calc_area_multiple(). Support mirror log allocation when there is only one PV: area_count now 0. (See lvm-devel list archives for further details.)
2006-12-13 06:39:58 +03:00
break;
basic pvmove support
2003-04-30 19:23:43 +04:00
}
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
if (alloc_state.allocated != ah->new_extents) {
allocation: Allow approximate allocation when specifying size in percent Introduce a new parameter called "approx_alloc" that is set when the desired size of a new LV is specified in percentage terms. If set, the allocation code tries to get as much space as it can but does not fail if can at least get some. One of the practical implications is that users can now specify 100%FREE when creating RAID LVs, like this: ~> lvcreate --type raid5 -i 2 -l 100%FREE -n lv vg
2014-02-14 07:10:28 +04:00
if (!ah->approx_alloc) {
log_error("Insufficient suitable %sallocatable extents "
"for logical volume %s: %u more required",
can_split ? "" : "contiguous ",
lv ? lv->name : "",
(ah->new_extents - alloc_state.allocated) *
ah->area_count / ah->area_multiple);
goto out;
}
allocation: misc fixes for percent/raid rounding Several fixes for the recent changes that treat allocation percentages as upper limits. Improve messages to make it easier to see what is happening. Fix some cases that failed with errors when they didn't need to. Fix crashes when first_seg() returns NULL. Remove a couple of log_errors that were actually debugging messages.
2014-02-22 04:26:01 +04:00
if (!alloc_state.allocated) {
log_error("Insufficient suitable %sallocatable extents "
"found for logical volume %s.",
can_split ? "" : "contiguous ",
lv ? lv->name : "");
goto out;
}
log_verbose("Found fewer %sallocatable extents "
"for logical volume %s than requested: using %" PRIu32 " extents (reduced by %u).",
allocation: Allow approximate allocation when specifying size in percent Introduce a new parameter called "approx_alloc" that is set when the desired size of a new LV is specified in percentage terms. If set, the allocation code tries to get as much space as it can but does not fail if can at least get some. One of the practical implications is that users can now specify 100%FREE when creating RAID LVs, like this: ~> lvcreate --type raid5 -i 2 -l 100%FREE -n lv vg
2014-02-14 07:10:28 +04:00
can_split ? "" : "contiguous ",
lv ? lv->name : "",
allocation: misc fixes for percent/raid rounding Several fixes for the recent changes that treat allocation percentages as upper limits. Improve messages to make it easier to see what is happening. Fix some cases that failed with errors when they didn't need to. Fix crashes when first_seg() returns NULL. Remove a couple of log_errors that were actually debugging messages.
2014-02-22 04:26:01 +04:00
alloc_state.allocated,
(ah->new_extents - alloc_state.allocated) * ah->area_count / ah->area_multiple);
allocation: Allow approximate allocation when specifying size in percent Introduce a new parameter called "approx_alloc" that is set when the desired size of a new LV is specified in percentage terms. If set, the allocation code tries to get as much space as it can but does not fail if can at least get some. One of the practical implications is that users can now specify 100%FREE when creating RAID LVs, like this: ~> lvcreate --type raid5 -i 2 -l 100%FREE -n lv vg
2014-02-14 07:10:28 +04:00
ah->new_extents = alloc_state.allocated;
Reinstate full PV size when removing from VG. Support loopfiles for testing. Complete the pv_segment support.
2005-05-03 21:28:23 +04:00
}
extend alloc_lv_segment
2005-04-22 19:44:00 +04:00
Various changes to the allocation algorithms: Expect some fallout. There is a lot to test. Two new config settings added that are intended to make the code behave closely to the way it did before - worth a try if you find problems.
2011-02-27 03:38:31 +03:00
if (alloc_state.log_area_count_still_needed) {
Improve lvcreate "insufficient extents" errors to "insufficient free space".
2011-01-28 05:58:00 +03:00
log_error("Insufficient free space for log allocation "
Try to fix tracking of whether or not log extents need allocating.
2010-04-01 17:58:13 +04:00
"for logical volume %s.",
lv ? lv->name : "");
goto out;
}
When lvconvert allocates a mirror log, respect parallel area constraints. Use loop to iterate through the now-ordered policy list in _allocate(). Check for failure to allocate just the mirror log. Introduce calc_area_multiple(). Support mirror log allocation when there is only one PV: area_count now 0. (See lvm-devel list archives for further details.)
2006-12-13 06:39:58 +03:00
Start merging cloned allocation functions.
2005-05-17 17:49:45 +04:00
r = 1;
extend alloc_lv_segment
2005-04-22 19:44:00 +04:00
Start merging cloned allocation functions.
2005-05-17 17:49:45 +04:00
out:
device_mapper: remove dbg_malloc. I wrote dbg_malloc before we had valgrind. These days there's just no need.
2018-06-08 15:40:53 +03:00
free(alloc_state.areas);
Start merging cloned allocation functions.
2005-05-17 17:49:45 +04:00
return r;
basic pvmove support
2003-04-30 19:23:43 +04:00
}
vdo: introduce segment types and manip functions Core functionality introducing lvm VDO support.
2018-06-29 12:11:14 +03:00
/*
* FIXME: Add proper allocation function for VDO segment on top
* of VDO pool with virtual size.
*
* Note: ATM lvm2 can't resize VDO device so it can add only a single segment.
*/
static int _lv_add_vdo_segment(struct logical_volume *lv, uint64_t status,
uint32_t extents, const struct segment_type *segtype)
{
struct lv_segment *seg;
if (!dm_list_empty(&lv->segments) &&
(seg = last_seg(lv)) && (seg->segtype == segtype)) {
seg->area_len += extents;
seg->len += extents;
} else {
if (!(seg = alloc_lv_segment(segtype, lv, lv->le_count, extents, 0,
status, 0, NULL, 1,
extents, 0, 0, 0, 0, NULL))) {
log_error("Couldn't allocate new %s segment.", segtype->name);
return 0;
}
lv->status |= LV_VDO;
dm_list_add(&lv->segments, &seg->list);
}
lv->le_count += extents;
lv->size += (uint64_t) extents * lv->vg->extent_size;
vdo: estimate virtual size after resize
2019-01-16 17:35:07 +03:00
if (seg_lv(seg, 0) &&
!update_vdo_pool_virtual_size(first_seg(seg_lv(seg, 0))))
return_0;
vdo: introduce segment types and manip functions Core functionality introducing lvm VDO support.
2018-06-29 12:11:14 +03:00
return 1;
}
Switch status from 32-bit to 64-bit The physical_volume, volume_group, logical_volume and lv_segment structures' 'status' member is now uint64_t. The alignment of these structures was also audited to remove holes. The movement of some members in 'volume_group' and 'lv_segment' eliminates holes. The 'physical_volume' structure still has one 4-byte hole after 'pe_size'; the other structures no longer have any holes. Each structures' size has not changed.
2009-11-25 01:55:55 +03:00
int lv_add_virtual_segment(struct logical_volume *lv, uint64_t status,
thin: simplify thin volume creation Move code for creation of thin volume into a single place out of lv_extend(). This allows to drop extra pool arg for alloc_lv_segment() && lv_extend() and makes code more easier to read and follow.
2014-10-26 10:13:59 +03:00
uint32_t extents, const struct segment_type *segtype)
o lv_manip.c will contain the code for lv_create, lv_extend and lv_reduce.
2001-11-06 13:29:56 +03:00
{
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
struct lv_segment *seg;
Start merging cloned allocation functions.
2005-05-17 17:49:45 +04:00
vdo: introduce segment types and manip functions Core functionality introducing lvm VDO support.
2018-06-29 12:11:14 +03:00
if (segtype_is_vdo(segtype))
return _lv_add_vdo_segment(lv, 0u, extents, segtype);
Explicitely check list size of segments instead of checking for NULL from last_seg and first_seg.
2012-02-28 14:08:20 +04:00
if (!dm_list_empty(&lv->segments) &&
(seg = last_seg(lv)) && (seg->segtype == segtype)) {
Extend virtual segment instead of adding new one Before adding a new virtual segment to LV, check first whether the last segment isn't already of the same type. In this case extend last segment instead of creating the new one. Thin volumes should have always only 1 virtual segment, but it helps also to virtual snapshot or error segtype..
2011-10-29 00:17:55 +04:00
seg->area_len += extents;
seg->len += extents;
} else {
lvconvert: add infrastructure for RaidLV reshaping support In order to support striped raid5/6/10 LV reshaping (change of LV type, stripesize or number of legs), this patch introduces infrastructure prerequisites to be used by raid_manip.c extensions in followup patches. This base is needed for allocation of out-of-place reshape space required by the MD raid personalities to avoid writing over data in-place when reading off the current RAID layout or number of legs and writing out the new layout or to a different number of legs (i.e. restripe) Changes: - add members reshape_len to 'struct lv_segment' to store out-of-place reshape length per component rimage - add member data_copies to struct lv_segment to support more than 2 raid10 data copies - make alloc_lv_segment() aware of both reshape_len and data_copies - adjust all alloc_lv_segment() callers to the new API - add functions to retrieve the current data offset (needed for out-of-place reshaping space allocation) and the devices count from the kernel - make libdm deptree code aware of reshape_len - add LV flags for disk add/remove reshaping - support import/export of the new 'struct lv_segment' members - enhance lv_extend/_lv_reduce to cope with reshape_len - add seg_is_*/segtype_is_* macros related to reshaping - add target version check for reshaping - grow rebuilds/writemostly bitmaps to 246 bit to support kernel maximal - enhance libdm deptree code to support data_offset (out-of-place reshaping) and delta_disk (legs add/remove reshaping) target arguments Related: rhbz834579 Related: rhbz1191935 Related: rhbz1191978
2017-02-24 02:50:00 +03:00
if (!(seg = alloc_lv_segment(segtype, lv, lv->le_count, extents, 0,
thin: simplify thin volume creation Move code for creation of thin volume into a single place out of lv_extend(). This allows to drop extra pool arg for alloc_lv_segment() && lv_extend() and makes code more easier to read and follow.
2014-10-26 10:13:59 +03:00
status, 0, NULL, 0,
lvconvert: add infrastructure for RaidLV reshaping support In order to support striped raid5/6/10 LV reshaping (change of LV type, stripesize or number of legs), this patch introduces infrastructure prerequisites to be used by raid_manip.c extensions in followup patches. This base is needed for allocation of out-of-place reshape space required by the MD raid personalities to avoid writing over data in-place when reading off the current RAID layout or number of legs and writing out the new layout or to a different number of legs (i.e. restripe) Changes: - add members reshape_len to 'struct lv_segment' to store out-of-place reshape length per component rimage - add member data_copies to struct lv_segment to support more than 2 raid10 data copies - make alloc_lv_segment() aware of both reshape_len and data_copies - adjust all alloc_lv_segment() callers to the new API - add functions to retrieve the current data offset (needed for out-of-place reshaping space allocation) and the devices count from the kernel - make libdm deptree code aware of reshape_len - add LV flags for disk add/remove reshaping - support import/export of the new 'struct lv_segment' members - enhance lv_extend/_lv_reduce to cope with reshape_len - add seg_is_*/segtype_is_* macros related to reshaping - add target version check for reshaping - grow rebuilds/writemostly bitmaps to 246 bit to support kernel maximal - enhance libdm deptree code to support data_offset (out-of-place reshaping) and delta_disk (legs add/remove reshaping) target arguments Related: rhbz834579 Related: rhbz1191935 Related: rhbz1191978
2017-02-24 02:50:00 +03:00
extents, 0, 0, 0, 0, NULL))) {
thin: simplify thin volume creation Move code for creation of thin volume into a single place out of lv_extend(). This allows to drop extra pool arg for alloc_lv_segment() && lv_extend() and makes code more easier to read and follow.
2014-10-26 10:13:59 +03:00
log_error("Couldn't allocate new %s segment.", segtype->name);
Extend virtual segment instead of adding new one Before adding a new virtual segment to LV, check first whether the last segment isn't already of the same type. In this case extend last segment instead of creating the new one. Thin volumes should have always only 1 virtual segment, but it helps also to virtual snapshot or error segtype..
2011-10-29 00:17:55 +04:00
return 0;
}
lv->status |= VIRTUAL;
dm_list_add(&lv->segments, &seg->list);
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
}
Fix contiguous allocations with linear.
2005-05-11 20:46:59 +04:00
lvresize: support resize of stacked virtual LV Update the LV stack with the size also for virtual LVs.
2021-03-18 15:14:13 +03:00
if (!_setup_lv_size(lv, lv->le_count + extents))
return_0;
o Contiguous allocation
2001-11-06 13:55:01 +03:00
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
return 1;
}
o Contiguous allocation
2001-11-06 13:55:01 +03:00
metadata: Move alloc_handle init/destroy fns.
2015-03-26 21:44:24 +03:00
/*
* Preparation for a specific allocation attempt
* stripes and mirrors refer to the parallel areas used for data.
* If log_area_count > 1 it is always mirrored (not striped).
*/
static struct alloc_handle *_alloc_init(struct cmd_context *cmd,
const struct segment_type *segtype,
alloc_policy_t alloc, int approx_alloc,
uint32_t existing_extents,
uint32_t new_extents,
uint32_t mirrors,
uint32_t stripes,
uint32_t metadata_area_count,
uint32_t extent_size,
uint32_t region_size,
struct dm_list *parallel_areas)
{
alloc: use own mem pool for alloc_handle Keep alloc_handle's data in a single mempool and do not spread them into vgmem pool.
2015-11-04 16:54:07 +03:00
struct dm_pool *mem;
metadata: Move alloc_handle init/destroy fns.
2015-03-26 21:44:24 +03:00
struct alloc_handle *ah;
uint32_t s, area_count, alloc_count, parity_count, total_extents;
size_t size = 0;
cleanup: explicit prohibition for virtual segs Internal _alloc_init() is only called from allocate_extents(), which already does prevent usage of virtual segments. So mark as internal error early and do not process it any further.
2016-01-06 15:54:15 +03:00
if (segtype_is_virtual(segtype)) {
log_error(INTERNAL_ERROR "_alloc_init called for virtual segment.");
return NULL;
}
metadata: Move alloc_handle init/destroy fns.
2015-03-26 21:44:24 +03:00
/* FIXME Caller should ensure this */
if (mirrors && !stripes)
stripes = 1;
lvmanip: fix last commit and drop else In last commit when removing if() branch this 'else' now has to be dropped.
2016-01-14 13:54:37 +03:00
if (mirrors > 1)
metadata: Move alloc_handle init/destroy fns.
2015-03-26 21:44:24 +03:00
area_count = mirrors * stripes;
else
area_count = stripes;
cleanup: explicit prohibition for virtual segs Internal _alloc_init() is only called from allocate_extents(), which already does prevent usage of virtual segments. So mark as internal error early and do not process it any further.
2016-01-06 15:54:15 +03:00
if (!(area_count + metadata_area_count)) {
cleanup: relocate error capture Capture internal error before allocation anything.
2015-11-04 16:53:25 +03:00
log_error(INTERNAL_ERROR "_alloc_init called for non-virtual segment with no disk space.");
return NULL;
}
metadata: Move alloc_handle init/destroy fns.
2015-03-26 21:44:24 +03:00
size = sizeof(*ah);
/*
* It is a requirement that RAID 4/5/6 are created with a number of
* stripes that is greater than the number of parity devices. (e.g
* RAID4/5 must have at least 2 stripes and RAID6 must have at least
* 3.) It is also a constraint that, when replacing individual devices
* in a RAID 4/5/6 array, no more devices can be replaced than
* there are parity devices. (Otherwise, there would not be enough
* redundancy to maintain the array.) Understanding these two
* constraints allows us to infer whether the caller of this function
* is intending to allocate an entire array or just replacement
* component devices. In the former case, we must account for the
* necessary parity_count. In the later case, we do not need to
* account for the extra parity devices because the array already
* exists and they only want replacement drives.
*/
parity_count = (area_count <= segtype->parity_devs) ? 0 : segtype->parity_devs;
alloc_count = area_count + parity_count;
if (segtype_is_raid(segtype) && metadata_area_count)
/* RAID has a meta area for each device */
alloc_count *= 2;
else
/* mirrors specify their exact log count */
alloc_count += metadata_area_count;
size += sizeof(ah->alloced_areas[0]) * alloc_count;
alloc: use own mem pool for alloc_handle Keep alloc_handle's data in a single mempool and do not spread them into vgmem pool.
2015-11-04 16:54:07 +03:00
if (!(mem = dm_pool_create("allocation", 1024))) {
log_error("allocation pool creation failed");
return NULL;
}
metadata: Move alloc_handle init/destroy fns.
2015-03-26 21:44:24 +03:00
if (!(ah = dm_pool_zalloc(mem, size))) {
log_error("allocation handle allocation failed");
alloc: use own mem pool for alloc_handle Keep alloc_handle's data in a single mempool and do not spread them into vgmem pool.
2015-11-04 16:54:07 +03:00
dm_pool_destroy(mem);
metadata: Move alloc_handle init/destroy fns.
2015-03-26 21:44:24 +03:00
return NULL;
}
ah->cmd = cmd;
alloc: use own mem pool for alloc_handle Keep alloc_handle's data in a single mempool and do not spread them into vgmem pool.
2015-11-04 16:54:07 +03:00
ah->mem = mem;
metadata: Move alloc_handle init/destroy fns.
2015-03-26 21:44:24 +03:00
ah->area_count = area_count;
ah->parity_count = parity_count;
ah->region_size = region_size;
ah->alloc = alloc;
/*
* For the purposes of allocation, area_count and parity_count are
* kept separately. However, the 'area_count' field in an
* lv_segment includes both; and this is what '_calc_area_multiple'
* is calculated from. So, we must pass in the total count to get
* a correct area_multiple.
*/
ah->area_multiple = _calc_area_multiple(segtype, area_count + parity_count, stripes);
//FIXME: s/mirror_logs_separate/metadata_separate/ so it can be used by others?
ah->mirror_logs_separate = find_config_tree_bool(cmd, allocation_mirror_logs_require_separate_pvs_CFG, NULL);
if (mirrors || stripes)
total_extents = new_extents;
else
total_extents = 0;
if (segtype_is_raid(segtype)) {
if (metadata_area_count) {
lvreduce/lvresize: add ability to reduce the size of a RaidLV - support shrinking of raid0/1/4/5/6/10 LVs - enhance lvresize-raid.sh tests: add raid0* and raid10 - fix have_raid4 in aux.sh to allow lv_resize-raid.sh and other scripts to test raid4 Resolves: rhbz1394048
2017-02-10 00:41:28 +03:00
uint32_t cur_rimage_extents, new_rimage_extents;
metadata: Move alloc_handle init/destroy fns.
2015-03-26 21:44:24 +03:00
if (metadata_area_count != area_count)
log_error(INTERNAL_ERROR
"Bad metadata_area_count");
lvreduce/lvresize: add ability to reduce the size of a RaidLV - support shrinking of raid0/1/4/5/6/10 LVs - enhance lvresize-raid.sh tests: add raid0* and raid10 - fix have_raid4 in aux.sh to allow lv_resize-raid.sh and other scripts to test raid4 Resolves: rhbz1394048
2017-02-10 00:41:28 +03:00
/* Calculate log_len (i.e. length of each rmeta device) for RAID */
cur_rimage_extents = raid_rimage_extents(segtype, existing_extents, stripes, mirrors);
new_rimage_extents = raid_rimage_extents(segtype, existing_extents + new_extents, stripes, mirrors),
ah->log_len = raid_rmeta_extents_delta(cmd, cur_rimage_extents, new_rimage_extents,
region_size, extent_size);
ah->metadata_area_count = metadata_area_count;
ah->alloc_and_split_meta = !!ah->log_len;
metadata: Move alloc_handle init/destroy fns.
2015-03-26 21:44:24 +03:00
/*
* We need 'log_len' extents for each
* RAID device's metadata_area
*/
lvreduce/lvresize: add ability to reduce the size of a RaidLV - support shrinking of raid0/1/4/5/6/10 LVs - enhance lvresize-raid.sh tests: add raid0* and raid10 - fix have_raid4 in aux.sh to allow lv_resize-raid.sh and other scripts to test raid4 Resolves: rhbz1394048
2017-02-10 00:41:28 +03:00
total_extents += ah->log_len * (segtype_is_raid1(segtype) ? 1 : ah->area_multiple);
metadata: Move alloc_handle init/destroy fns.
2015-03-26 21:44:24 +03:00
} else {
ah->log_area_count = 0;
ah->log_len = 0;
}
} else if (segtype_is_thin_pool(segtype)) {
/*
* thin_pool uses ah->region_size to
* pass metadata size in extents
*/
ah->log_len = ah->region_size;
ah->log_area_count = metadata_area_count;
ah->region_size = 0;
ah->mirror_logs_separate =
find_config_tree_bool(cmd, allocation_thin_pool_metadata_require_separate_pvs_CFG, NULL);
} else if (segtype_is_cache_pool(segtype)) {
/*
* Like thin_pool, cache_pool uses ah->region_size to
* pass metadata size in extents
*/
ah->log_len = ah->region_size;
/* use metadata_area_count, not log_area_count */
ah->metadata_area_count = metadata_area_count;
ah->region_size = 0;
ah->mirror_logs_separate =
find_config_tree_bool(cmd, allocation_cache_pool_metadata_require_separate_pvs_CFG, NULL);
if (!ah->mirror_logs_separate) {
ah->alloc_and_split_meta = 1;
total_extents += ah->log_len;
}
} else {
ah->log_area_count = metadata_area_count;
ah->log_len = !metadata_area_count ? 0 :
mirror: Fix log size calc when more than 1 extent. Currently the code creates the log separately after allocating space for the data and as no data allocation is needed this second time, total_extents ends up holding zero so use new_extents directly instead.
2015-11-06 02:40:47 +03:00
_mirror_log_extents(ah->region_size, extent_size,
(existing_extents + new_extents) / ah->area_multiple);
metadata: Move alloc_handle init/destroy fns.
2015-03-26 21:44:24 +03:00
}
cleanup: enhance debug message
2018-04-19 13:32:01 +03:00
if (total_extents || existing_extents)
log_debug("Adjusted allocation request to " FMTu32 " logical extents. Existing size " FMTu32 ". New size " FMTu32 ".",
total_extents, existing_extents, total_extents + existing_extents);
mirror: Fix log size calc when more than 1 extent. Currently the code creates the log separately after allocating space for the data and as no data allocation is needed this second time, total_extents ends up holding zero so use new_extents directly instead.
2015-11-06 02:40:47 +03:00
if (ah->log_len)
cleanup: enhance debug message
2018-04-19 13:32:01 +03:00
log_debug("Mirror log of " FMTu32 " extents of size " FMTu32 " sectors needed for region size %s.",
ah->log_len, extent_size, display_size(cmd, (uint64_t)ah->region_size));
metadata: Move alloc_handle init/destroy fns.
2015-03-26 21:44:24 +03:00
if (mirrors || stripes)
total_extents += existing_extents;
ah->new_extents = total_extents;
for (s = 0; s < alloc_count; s++)
dm_list_init(&ah->alloced_areas[s]);
ah->parallel_areas = parallel_areas;
config: replace find_config_tree_node with find_config_tree_array where appropriate
2015-07-08 12:22:24 +03:00
if ((ah->cling_tag_list_cn = find_config_tree_array(cmd, allocation_cling_tag_list_CFG, NULL)))
alloc: Only report cling tag errors once.
2015-03-26 22:43:51 +03:00
(void) _validate_tag_list(ah->cling_tag_list_cn);
metadata: Move alloc_handle init/destroy fns.
2015-03-26 21:44:24 +03:00
ah->maximise_cling = find_config_tree_bool(cmd, allocation_maximise_cling_CFG, NULL);
ah->approx_alloc = approx_alloc;
return ah;
}
void alloc_destroy(struct alloc_handle *ah)
{
lvconvert: Conversions between striped and raid0.
2016-06-29 01:44:15 +03:00
if (ah)
dm_pool_destroy(ah->mem);
metadata: Move alloc_handle init/destroy fns.
2015-03-26 21:44:24 +03:00
}
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
/*
* Entry point for all extent allocations.
*/
struct alloc_handle *allocate_extents(struct volume_group *vg,
struct logical_volume *lv,
Make SIZE_SHORT the default for display_size(). Fix some memory leaks in error paths found by coverity. Use C99 struct initialisers. Move DEFS into configure.h. Clean-ups to remove miscellaneous compiler warnings.
2006-05-10 01:23:51 +04:00
const struct segment_type *segtype,
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
uint32_t stripes,
uint32_t mirrors, uint32_t log_count,
Extend core allocation code in preparation for mirrored log areas.
2010-03-01 23:00:20 +03:00
uint32_t region_size, uint32_t extents,
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
struct dm_list *allocatable_pvs,
allocation: Allow approximate allocation when specifying size in percent Introduce a new parameter called "approx_alloc" that is set when the desired size of a new LV is specified in percentage terms. If set, the allocation code tries to get as much space as it can but does not fail if can at least get some. One of the practical implications is that users can now specify 100%FREE when creating RAID LVs, like this: ~> lvcreate --type raid5 -i 2 -l 100%FREE -n lv vg
2014-02-14 07:10:28 +04:00
alloc_policy_t alloc, int approx_alloc,
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
struct dm_list *parallel_areas)
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
{
struct alloc_handle *ah;
Fix contiguous allocations with linear.
2005-05-11 20:46:59 +04:00
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
if (segtype_is_virtual(segtype)) {
log_error("allocate_extents does not handle virtual segments");
return NULL;
}
Add internal error for unsupported code paths Patch mainly helps static analyzers to better work with code paths lvm code should never trigger.
2012-02-13 15:25:56 +04:00
if (!allocatable_pvs) {
log_error(INTERNAL_ERROR "Missing allocatable pvs.");
return NULL;
}
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
if (vg->fid->fmt->ops->segtype_supported &&
!vg->fid->fmt->ops->segtype_supported(vg->fid, segtype)) {
log_error("Metadata format (%s) does not support required "
"LV segment type (%s).", vg->fid->fmt->name,
segtype->name);
log_error("Consider changing the metadata format by running "
"vgconvert.");
return NULL;
}
Fix allocation policy loop so it doesn't continue beyond cling using later policies it shouldn't be using when --alloc cling is specified but no tags are defined.
2012-05-12 02:19:12 +04:00
if (alloc >= ALLOC_INHERIT)
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
alloc = vg->alloc;
o Sync up todays work on converting to the segmented representation of logical volumes. It includes: format1 changes. metadata.h changes. lv_manip.c changed (striped allocation still not done though). activate.c changes. Nothing has been near a compiler as yet. Alasdair can you look at changing display.c to use to output the mappings in a more segment oriented format please ? I haven't put the span list into struct physical_volume to represent allocated extents. I think the burden of maintaining it for things like lv_extend may out weigh it's uses.
2001-11-27 19:37:33 +03:00
alloc: use own mem pool for alloc_handle Keep alloc_handle's data in a single mempool and do not spread them into vgmem pool.
2015-11-04 16:54:07 +03:00
if (!(ah = _alloc_init(vg->cmd, segtype, alloc, approx_alloc,
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
lv ? lv->le_count : 0, extents, mirrors, stripes, log_count,
Extend core allocation code in preparation for mirrored log areas.
2010-03-01 23:00:20 +03:00
vg->extent_size, region_size,
parallel_areas)))
drop mirrored_pv/mirrored_pe from alloc handle
2007-11-22 17:54:35 +03:00
return_NULL;
o Contiguous allocation
2001-11-06 13:55:01 +03:00
Add disk to mirrored log type conversion.
2011-01-11 20:05:08 +03:00
if (!_allocate(ah, vg, lv, 1, allocatable_pvs)) {
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
alloc_destroy(ah);
Use stack return macros throughout.
2008-01-30 16:19:47 +03:00
return_NULL;
o lv_manip.c will contain the code for lv_create, lv_extend and lv_reduce.
2001-11-06 13:29:56 +03:00
}
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
return ah;
o lv_manip.c will contain the code for lv_create, lv_extend and lv_reduce.
2001-11-06 13:29:56 +03:00
}
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
/*
* Add new segments to an LV from supplied list of areas.
*/
int lv_add_segment(struct alloc_handle *ah,
uint32_t first_area, uint32_t num_areas,
struct logical_volume *lv,
Make SIZE_SHORT the default for display_size(). Fix some memory leaks in error paths found by coverity. Use C99 struct initialisers. Move DEFS into configure.h. Clean-ups to remove miscellaneous compiler warnings.
2006-05-10 01:23:51 +04:00
const struct segment_type *segtype,
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
uint32_t stripe_size,
Switch status from 32-bit to 64-bit The physical_volume, volume_group, logical_volume and lv_segment structures' 'status' member is now uint64_t. The alignment of these structures was also audited to remove holes. The movement of some members in 'volume_group' and 'lv_segment' eliminates holes. The 'physical_volume' structure still has one 4-byte hole after 'pe_size'; the other structures no longer have any holes. Each structures' size has not changed.
2009-11-25 01:55:55 +03:00
uint64_t status,
Extend core allocation code in preparation for mirrored log areas.
2010-03-01 23:00:20 +03:00
uint32_t region_size)
Add --type to lvcreate/resize. Add virtual segment types, zero and error. A large sparse device can be constructed as a writeable snapshot of a large zero device.
2004-05-11 20:01:58 +04:00
{
Always insert an intermediate layer for mirrors. Suppress hidden LVs from reports unless --all is given. Use square brackets for hidden LVs in reports. Centralise restrictions on LV names.
2005-06-03 18:49:51 +04:00
if (!segtype) {
log_error("Missing segtype in lv_add_segment().");
return 0;
}
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
if (segtype_is_virtual(segtype)) {
log_error("lv_add_segment cannot handle virtual segments");
return 0;
}
Add --type to lvcreate/resize. Add virtual segment types, zero and error. A large sparse device can be constructed as a writeable snapshot of a large zero device.
2004-05-11 20:01:58 +04:00
cleanup: use dm_list_empty Check for empty list directly.
2013-07-17 16:49:21 +04:00
if ((status & MIRROR_LOG) && !dm_list_empty(&lv->segments)) {
Extend core allocation code in preparation for mirrored log areas.
2010-03-01 23:00:20 +03:00
log_error("Log segments can only be added to an empty LV");
return 0;
}
Revert so-called "redundant" log until after next release.
2010-01-12 17:00:51 +03:00
if (!_setup_alloced_segments(lv, &ah->alloced_areas[first_area],
num_areas, status,
stripe_size, segtype,
Extend core allocation code in preparation for mirrored log areas.
2010-03-01 23:00:20 +03:00
region_size))
Use stack return macros throughout.
2008-01-30 16:19:47 +03:00
return_0;
Add --type to lvcreate/resize. Add virtual segment types, zero and error. A large sparse device can be constructed as a writeable snapshot of a large zero device.
2004-05-11 20:01:58 +04:00
cleanup: use macros
2016-12-25 01:46:47 +03:00
if (segtype_can_split(segtype) && !lv_merge_segments(lv)) {
Use log_error macro consistently throughout in place of log_err.
2009-07-16 00:02:46 +04:00
log_error("Couldn't merge segments after extending "
"logical volume.");
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
return 0;
}
if (lv->vg->fid->fmt->ops->lv_setup &&
Use stack return macros throughout.
2008-01-30 16:19:47 +03:00
!lv->vg->fid->fmt->ops->lv_setup(lv->vg->fid, lv))
return_0;
Add --type to lvcreate/resize. Add virtual segment types, zero and error. A large sparse device can be constructed as a writeable snapshot of a large zero device.
2004-05-11 20:01:58 +04:00
return 1;
}
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
/*
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
* "mirror" segment type doesn't support split.
* So, when adding mirrors to linear LV segment, first split it,
* then convert it to "mirror" and add areas.
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
*/
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
static struct lv_segment *_convert_seg_to_mirror(struct lv_segment *seg,
uint32_t region_size,
struct logical_volume *log_lv)
Internal snapshot code restructuring.
2005-04-07 16:39:44 +04:00
{
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
struct lv_segment *newseg;
uint32_t s;
Internal snapshot code restructuring.
2005-04-07 16:39:44 +04:00
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
if (!seg_is_striped(seg)) {
log_error("Can't convert non-striped segment to mirrored.");
return NULL;
Internal snapshot code restructuring.
2005-04-07 16:39:44 +04:00
}
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
if (seg->area_count > 1) {
log_error("Can't convert striped segment with multiple areas "
"to mirrored.");
return NULL;
Internal snapshot code restructuring.
2005-04-07 16:39:44 +04:00
}
extend alloc_lv_segment
2005-04-22 19:44:00 +04:00
segtypes: Use SEG_TYPE_NAME_ string constants.
2015-09-22 21:04:12 +03:00
if (!(newseg = alloc_lv_segment(get_segtype_from_string(seg->lv->vg->cmd, SEG_TYPE_NAME_MIRROR),
lvconvert: add infrastructure for RaidLV reshaping support In order to support striped raid5/6/10 LV reshaping (change of LV type, stripesize or number of legs), this patch introduces infrastructure prerequisites to be used by raid_manip.c extensions in followup patches. This base is needed for allocation of out-of-place reshape space required by the MD raid personalities to avoid writing over data in-place when reading off the current RAID layout or number of legs and writing out the new layout or to a different number of legs (i.e. restripe) Changes: - add members reshape_len to 'struct lv_segment' to store out-of-place reshape length per component rimage - add member data_copies to struct lv_segment to support more than 2 raid10 data copies - make alloc_lv_segment() aware of both reshape_len and data_copies - adjust all alloc_lv_segment() callers to the new API - add functions to retrieve the current data offset (needed for out-of-place reshaping space allocation) and the devices count from the kernel - make libdm deptree code aware of reshape_len - add LV flags for disk add/remove reshaping - support import/export of the new 'struct lv_segment' members - enhance lv_extend/_lv_reduce to cope with reshape_len - add seg_is_*/segtype_is_* macros related to reshaping - add target version check for reshaping - grow rebuilds/writemostly bitmaps to 246 bit to support kernel maximal - enhance libdm deptree code to support data_offset (out-of-place reshaping) and delta_disk (legs add/remove reshaping) target arguments Related: rhbz834579 Related: rhbz1191935 Related: rhbz1191978
2017-02-24 02:50:00 +03:00
seg->lv, seg->le, seg->len, 0,
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
seg->status, seg->stripe_size,
thin: simplify thin volume creation Move code for creation of thin volume into a single place out of lv_extend(). This allows to drop extra pool arg for alloc_lv_segment() && lv_extend() and makes code more easier to read and follow.
2014-10-26 10:13:59 +03:00
log_lv,
lvconvert: add infrastructure for RaidLV reshaping support In order to support striped raid5/6/10 LV reshaping (change of LV type, stripesize or number of legs), this patch introduces infrastructure prerequisites to be used by raid_manip.c extensions in followup patches. This base is needed for allocation of out-of-place reshape space required by the MD raid personalities to avoid writing over data in-place when reading off the current RAID layout or number of legs and writing out the new layout or to a different number of legs (i.e. restripe) Changes: - add members reshape_len to 'struct lv_segment' to store out-of-place reshape length per component rimage - add member data_copies to struct lv_segment to support more than 2 raid10 data copies - make alloc_lv_segment() aware of both reshape_len and data_copies - adjust all alloc_lv_segment() callers to the new API - add functions to retrieve the current data offset (needed for out-of-place reshaping space allocation) and the devices count from the kernel - make libdm deptree code aware of reshape_len - add LV flags for disk add/remove reshaping - support import/export of the new 'struct lv_segment' members - enhance lv_extend/_lv_reduce to cope with reshape_len - add seg_is_*/segtype_is_* macros related to reshaping - add target version check for reshaping - grow rebuilds/writemostly bitmaps to 246 bit to support kernel maximal - enhance libdm deptree code to support data_offset (out-of-place reshaping) and delta_disk (legs add/remove reshaping) target arguments Related: rhbz834579 Related: rhbz1191935 Related: rhbz1191978
2017-02-24 02:50:00 +03:00
seg->area_count, seg->area_len, 0,
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
seg->chunk_size, region_size,
Fix pvmove allocation to take existing parallel stripes into account. When moving parts of striped LVs, pvmove wouldn't care about leaving you with two stripes on the same disk. Now --alloc anywhere is needed for that. (Tried and gave up on two alternative approaches before the one committed here.)
2010-04-08 04:28:57 +04:00
seg->extents_copied, NULL))) {
cleanup: add some dots and use display_lvname Just some more VG/LV printing.
2016-11-25 16:08:39 +03:00
log_error("Couldn't allocate converted LV segment.");
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
return NULL;
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
}
Internal snapshot code restructuring.
2005-04-07 16:39:44 +04:00
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
for (s = 0; s < seg->area_count; s++)
if (!move_lv_segment_area(newseg, s, seg, s))
return_NULL;
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
Fix pvmove allocation to take existing parallel stripes into account. When moving parts of striped LVs, pvmove wouldn't care about leaving you with two stripes on the same disk. Now --alloc anywhere is needed for that. (Tried and gave up on two alternative approaches before the one committed here.)
2010-04-08 04:28:57 +04:00
seg->pvmove_source_seg = NULL; /* Not maintained after allocation */
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
dm_list_add(&seg->list, &newseg->list);
dm_list_del(&seg->list);
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
return newseg;
Internal snapshot code restructuring.
2005-04-07 16:39:44 +04:00
}
pvmove: Enable all-or-nothing (atomic) pvmoves pvmove can be used to move single LVs by name or multiple LVs that lie within the specified PV range (e.g. /dev/sdb1:0-1000). When moving more than one LV, the portions of those LVs that are in the range to be moved are added to a new temporary pvmove LV. The LVs then point to the range in the pvmove LV, rather than the PV range. Example 1: We have two LVs in this example. After they were created, the first LV was grown, yeilding two segments in LV1. So, there are two LVs with a total of three segments. Before pvmove: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- After pvmove inserts the temporary pvmove LV: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- Each of the affected LV segments now point to a range of blocks in the pvmove LV, which purposefully corresponds to the segments moved from the original LVs into the temporary pvmove LV. The current implementation goes on from here to mirror the temporary pvmove LV by segment. Further, as the pvmove LV is activated, only one of its segments is actually mirrored (i.e. "moving") at a time. The rest are either complete or not addressed yet. If the pvmove is aborted, those segments that are completed will remain on the destination and those that are not yet addressed or in the process of moving will stay on the source PV. Thus, it is possible to have a partially completed move - some LVs (or certain segments of LVs) on the source PV and some on the destination. Example 2: What 'example 1' might look if it was half-way through the move. --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | | ------------------------- source PV | | 256 - 511 | 512 - 767 | | ------------------------- | || ------------------------- dest PV | 000 - 255 | 256 - 511 | ------------------------- This update allows the user to specify that they would like the pvmove mirror created "by LV" rather than "by segment". That is, the pvmove LV becomes an image in an encapsulating mirror along with the allocated copy image. Example 3: A pvmove that is performed "by LV" rather than "by segment". --------- --------- | LV1s0 | | LV2s0 | --------- --------- | | ------------------------- pvmove0 | * LV-level mirror * | ------------------------- / \ pvmove_mimage0 / pvmove_mimage1 ------------------------- ------------------------- | seg 0 | seg 1 | | seg 0 | seg 1 | ------------------------- ------------------------- | | | | ------------------------- ------------------------- | 000 - 255 | 256 - 511 | | 000 - 255 | 256 - 511 | ------------------------- ------------------------- source PV dest PV The thing that differentiates a pvmove done in this way and a simple "up-convert" from linear to mirror is the preservation of the distinct segments. A normal up-convert would simply allocate the necessary space with no regard for segment boundaries. The pvmove operation must preserve the segments because they are the critical boundary between the segments of the LVs being moved. So, when the pvmove copy image is allocated, all corresponding segments must be allocated. The code that merges ajoining segments that are part of the same LV when the metadata is written must also be avoided in this case. This method of mirroring is unique enough to warrant its own definitional macro, MIRROR_BY_SEGMENTED_LV. This joins the two existing macros: MIRROR_BY_SEG (for original pvmove) and MIRROR_BY_LV (for user created mirrors). The advantages of performing pvmove in this way is that all of the LVs affected can be moved together. It is an all-or-nothing approach that leaves all LV segments on the source PV if the move is aborted. Additionally, a mirror log can be used (in the future) to provide tracking of progress; allowing the copy to continue where it left off in the event there is a deactivation.
2014-06-18 07:59:36 +04:00
/*
* Add new areas to mirrored segments
*/
int lv_add_segmented_mirror_image(struct alloc_handle *ah,
struct logical_volume *lv, uint32_t le,
uint32_t region_size)
{
char *image_name;
struct alloced_area *aa;
struct lv_segment *seg, *new_seg;
uint32_t current_le = le;
uint32_t s;
struct segment_type *segtype;
struct logical_volume *orig_lv, *copy_lv;
cleanup: Use lv_is_ macros. Use lv_is_* macros throughout the code base, introducing lv_is_pvmove, lv_is_locked, lv_is_converting and lv_is_merging. lv_is_mirror_type no longer includes pvmove.
2014-09-16 00:33:53 +04:00
if (!lv_is_pvmove(lv)) {
pvmove: Enable all-or-nothing (atomic) pvmoves pvmove can be used to move single LVs by name or multiple LVs that lie within the specified PV range (e.g. /dev/sdb1:0-1000). When moving more than one LV, the portions of those LVs that are in the range to be moved are added to a new temporary pvmove LV. The LVs then point to the range in the pvmove LV, rather than the PV range. Example 1: We have two LVs in this example. After they were created, the first LV was grown, yeilding two segments in LV1. So, there are two LVs with a total of three segments. Before pvmove: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- After pvmove inserts the temporary pvmove LV: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- Each of the affected LV segments now point to a range of blocks in the pvmove LV, which purposefully corresponds to the segments moved from the original LVs into the temporary pvmove LV. The current implementation goes on from here to mirror the temporary pvmove LV by segment. Further, as the pvmove LV is activated, only one of its segments is actually mirrored (i.e. "moving") at a time. The rest are either complete or not addressed yet. If the pvmove is aborted, those segments that are completed will remain on the destination and those that are not yet addressed or in the process of moving will stay on the source PV. Thus, it is possible to have a partially completed move - some LVs (or certain segments of LVs) on the source PV and some on the destination. Example 2: What 'example 1' might look if it was half-way through the move. --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | | ------------------------- source PV | | 256 - 511 | 512 - 767 | | ------------------------- | || ------------------------- dest PV | 000 - 255 | 256 - 511 | ------------------------- This update allows the user to specify that they would like the pvmove mirror created "by LV" rather than "by segment". That is, the pvmove LV becomes an image in an encapsulating mirror along with the allocated copy image. Example 3: A pvmove that is performed "by LV" rather than "by segment". --------- --------- | LV1s0 | | LV2s0 | --------- --------- | | ------------------------- pvmove0 | * LV-level mirror * | ------------------------- / \ pvmove_mimage0 / pvmove_mimage1 ------------------------- ------------------------- | seg 0 | seg 1 | | seg 0 | seg 1 | ------------------------- ------------------------- | | | | ------------------------- ------------------------- | 000 - 255 | 256 - 511 | | 000 - 255 | 256 - 511 | ------------------------- ------------------------- source PV dest PV The thing that differentiates a pvmove done in this way and a simple "up-convert" from linear to mirror is the preservation of the distinct segments. A normal up-convert would simply allocate the necessary space with no regard for segment boundaries. The pvmove operation must preserve the segments because they are the critical boundary between the segments of the LVs being moved. So, when the pvmove copy image is allocated, all corresponding segments must be allocated. The code that merges ajoining segments that are part of the same LV when the metadata is written must also be avoided in this case. This method of mirroring is unique enough to warrant its own definitional macro, MIRROR_BY_SEGMENTED_LV. This joins the two existing macros: MIRROR_BY_SEG (for original pvmove) and MIRROR_BY_LV (for user created mirrors). The advantages of performing pvmove in this way is that all of the LVs affected can be moved together. It is an all-or-nothing approach that leaves all LV segments on the source PV if the move is aborted. Additionally, a mirror log can be used (in the future) to provide tracking of progress; allowing the copy to continue where it left off in the event there is a deactivation.
2014-06-18 07:59:36 +04:00
log_error(INTERNAL_ERROR
cleanup: add some dots and use display_lvname Just some more VG/LV printing.
2016-11-25 16:08:39 +03:00
"Non-pvmove LV, %s, passed as argument.",
display_lvname(lv));
pvmove: Enable all-or-nothing (atomic) pvmoves pvmove can be used to move single LVs by name or multiple LVs that lie within the specified PV range (e.g. /dev/sdb1:0-1000). When moving more than one LV, the portions of those LVs that are in the range to be moved are added to a new temporary pvmove LV. The LVs then point to the range in the pvmove LV, rather than the PV range. Example 1: We have two LVs in this example. After they were created, the first LV was grown, yeilding two segments in LV1. So, there are two LVs with a total of three segments. Before pvmove: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- After pvmove inserts the temporary pvmove LV: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- Each of the affected LV segments now point to a range of blocks in the pvmove LV, which purposefully corresponds to the segments moved from the original LVs into the temporary pvmove LV. The current implementation goes on from here to mirror the temporary pvmove LV by segment. Further, as the pvmove LV is activated, only one of its segments is actually mirrored (i.e. "moving") at a time. The rest are either complete or not addressed yet. If the pvmove is aborted, those segments that are completed will remain on the destination and those that are not yet addressed or in the process of moving will stay on the source PV. Thus, it is possible to have a partially completed move - some LVs (or certain segments of LVs) on the source PV and some on the destination. Example 2: What 'example 1' might look if it was half-way through the move. --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | | ------------------------- source PV | | 256 - 511 | 512 - 767 | | ------------------------- | || ------------------------- dest PV | 000 - 255 | 256 - 511 | ------------------------- This update allows the user to specify that they would like the pvmove mirror created "by LV" rather than "by segment". That is, the pvmove LV becomes an image in an encapsulating mirror along with the allocated copy image. Example 3: A pvmove that is performed "by LV" rather than "by segment". --------- --------- | LV1s0 | | LV2s0 | --------- --------- | | ------------------------- pvmove0 | * LV-level mirror * | ------------------------- / \ pvmove_mimage0 / pvmove_mimage1 ------------------------- ------------------------- | seg 0 | seg 1 | | seg 0 | seg 1 | ------------------------- ------------------------- | | | | ------------------------- ------------------------- | 000 - 255 | 256 - 511 | | 000 - 255 | 256 - 511 | ------------------------- ------------------------- source PV dest PV The thing that differentiates a pvmove done in this way and a simple "up-convert" from linear to mirror is the preservation of the distinct segments. A normal up-convert would simply allocate the necessary space with no regard for segment boundaries. The pvmove operation must preserve the segments because they are the critical boundary between the segments of the LVs being moved. So, when the pvmove copy image is allocated, all corresponding segments must be allocated. The code that merges ajoining segments that are part of the same LV when the metadata is written must also be avoided in this case. This method of mirroring is unique enough to warrant its own definitional macro, MIRROR_BY_SEGMENTED_LV. This joins the two existing macros: MIRROR_BY_SEG (for original pvmove) and MIRROR_BY_LV (for user created mirrors). The advantages of performing pvmove in this way is that all of the LVs affected can be moved together. It is an all-or-nothing approach that leaves all LV segments on the source PV if the move is aborted. Additionally, a mirror log can be used (in the future) to provide tracking of progress; allowing the copy to continue where it left off in the event there is a deactivation.
2014-06-18 07:59:36 +04:00
return 0;
}
if (seg_type(first_seg(lv), 0) != AREA_PV) {
log_error(INTERNAL_ERROR
cleanup: add some dots and use display_lvname Just some more VG/LV printing.
2016-11-25 16:08:39 +03:00
"Bad segment type for first segment area.");
pvmove: Enable all-or-nothing (atomic) pvmoves pvmove can be used to move single LVs by name or multiple LVs that lie within the specified PV range (e.g. /dev/sdb1:0-1000). When moving more than one LV, the portions of those LVs that are in the range to be moved are added to a new temporary pvmove LV. The LVs then point to the range in the pvmove LV, rather than the PV range. Example 1: We have two LVs in this example. After they were created, the first LV was grown, yeilding two segments in LV1. So, there are two LVs with a total of three segments. Before pvmove: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- After pvmove inserts the temporary pvmove LV: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- Each of the affected LV segments now point to a range of blocks in the pvmove LV, which purposefully corresponds to the segments moved from the original LVs into the temporary pvmove LV. The current implementation goes on from here to mirror the temporary pvmove LV by segment. Further, as the pvmove LV is activated, only one of its segments is actually mirrored (i.e. "moving") at a time. The rest are either complete or not addressed yet. If the pvmove is aborted, those segments that are completed will remain on the destination and those that are not yet addressed or in the process of moving will stay on the source PV. Thus, it is possible to have a partially completed move - some LVs (or certain segments of LVs) on the source PV and some on the destination. Example 2: What 'example 1' might look if it was half-way through the move. --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | | ------------------------- source PV | | 256 - 511 | 512 - 767 | | ------------------------- | || ------------------------- dest PV | 000 - 255 | 256 - 511 | ------------------------- This update allows the user to specify that they would like the pvmove mirror created "by LV" rather than "by segment". That is, the pvmove LV becomes an image in an encapsulating mirror along with the allocated copy image. Example 3: A pvmove that is performed "by LV" rather than "by segment". --------- --------- | LV1s0 | | LV2s0 | --------- --------- | | ------------------------- pvmove0 | * LV-level mirror * | ------------------------- / \ pvmove_mimage0 / pvmove_mimage1 ------------------------- ------------------------- | seg 0 | seg 1 | | seg 0 | seg 1 | ------------------------- ------------------------- | | | | ------------------------- ------------------------- | 000 - 255 | 256 - 511 | | 000 - 255 | 256 - 511 | ------------------------- ------------------------- source PV dest PV The thing that differentiates a pvmove done in this way and a simple "up-convert" from linear to mirror is the preservation of the distinct segments. A normal up-convert would simply allocate the necessary space with no regard for segment boundaries. The pvmove operation must preserve the segments because they are the critical boundary between the segments of the LVs being moved. So, when the pvmove copy image is allocated, all corresponding segments must be allocated. The code that merges ajoining segments that are part of the same LV when the metadata is written must also be avoided in this case. This method of mirroring is unique enough to warrant its own definitional macro, MIRROR_BY_SEGMENTED_LV. This joins the two existing macros: MIRROR_BY_SEG (for original pvmove) and MIRROR_BY_LV (for user created mirrors). The advantages of performing pvmove in this way is that all of the LVs affected can be moved together. It is an all-or-nothing approach that leaves all LV segments on the source PV if the move is aborted. Additionally, a mirror log can be used (in the future) to provide tracking of progress; allowing the copy to continue where it left off in the event there is a deactivation.
2014-06-18 07:59:36 +04:00
return 0;
}
/*
pvvmove: add a few comments
2014-06-20 14:41:20 +04:00
* If the allocator provided two or more PV allocations for any
* single segment of the original LV, that LV segment must be
* split up to match.
pvmove: Enable all-or-nothing (atomic) pvmoves pvmove can be used to move single LVs by name or multiple LVs that lie within the specified PV range (e.g. /dev/sdb1:0-1000). When moving more than one LV, the portions of those LVs that are in the range to be moved are added to a new temporary pvmove LV. The LVs then point to the range in the pvmove LV, rather than the PV range. Example 1: We have two LVs in this example. After they were created, the first LV was grown, yeilding two segments in LV1. So, there are two LVs with a total of three segments. Before pvmove: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- After pvmove inserts the temporary pvmove LV: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- Each of the affected LV segments now point to a range of blocks in the pvmove LV, which purposefully corresponds to the segments moved from the original LVs into the temporary pvmove LV. The current implementation goes on from here to mirror the temporary pvmove LV by segment. Further, as the pvmove LV is activated, only one of its segments is actually mirrored (i.e. "moving") at a time. The rest are either complete or not addressed yet. If the pvmove is aborted, those segments that are completed will remain on the destination and those that are not yet addressed or in the process of moving will stay on the source PV. Thus, it is possible to have a partially completed move - some LVs (or certain segments of LVs) on the source PV and some on the destination. Example 2: What 'example 1' might look if it was half-way through the move. --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | | ------------------------- source PV | | 256 - 511 | 512 - 767 | | ------------------------- | || ------------------------- dest PV | 000 - 255 | 256 - 511 | ------------------------- This update allows the user to specify that they would like the pvmove mirror created "by LV" rather than "by segment". That is, the pvmove LV becomes an image in an encapsulating mirror along with the allocated copy image. Example 3: A pvmove that is performed "by LV" rather than "by segment". --------- --------- | LV1s0 | | LV2s0 | --------- --------- | | ------------------------- pvmove0 | * LV-level mirror * | ------------------------- / \ pvmove_mimage0 / pvmove_mimage1 ------------------------- ------------------------- | seg 0 | seg 1 | | seg 0 | seg 1 | ------------------------- ------------------------- | | | | ------------------------- ------------------------- | 000 - 255 | 256 - 511 | | 000 - 255 | 256 - 511 | ------------------------- ------------------------- source PV dest PV The thing that differentiates a pvmove done in this way and a simple "up-convert" from linear to mirror is the preservation of the distinct segments. A normal up-convert would simply allocate the necessary space with no regard for segment boundaries. The pvmove operation must preserve the segments because they are the critical boundary between the segments of the LVs being moved. So, when the pvmove copy image is allocated, all corresponding segments must be allocated. The code that merges ajoining segments that are part of the same LV when the metadata is written must also be avoided in this case. This method of mirroring is unique enough to warrant its own definitional macro, MIRROR_BY_SEGMENTED_LV. This joins the two existing macros: MIRROR_BY_SEG (for original pvmove) and MIRROR_BY_LV (for user created mirrors). The advantages of performing pvmove in this way is that all of the LVs affected can be moved together. It is an all-or-nothing approach that leaves all LV segments on the source PV if the move is aborted. Additionally, a mirror log can be used (in the future) to provide tracking of progress; allowing the copy to continue where it left off in the event there is a deactivation.
2014-06-18 07:59:36 +04:00
*/
dm_list_iterate_items(aa, &ah->alloced_areas[0]) {
if (!(seg = find_seg_by_le(lv, current_le))) {
cleanup: add some dots and use display_lvname Just some more VG/LV printing.
2016-11-25 16:08:39 +03:00
log_error("Failed to find segment for %s extent " FMTu32 ".",
display_lvname(lv), current_le);
pvmove: Enable all-or-nothing (atomic) pvmoves pvmove can be used to move single LVs by name or multiple LVs that lie within the specified PV range (e.g. /dev/sdb1:0-1000). When moving more than one LV, the portions of those LVs that are in the range to be moved are added to a new temporary pvmove LV. The LVs then point to the range in the pvmove LV, rather than the PV range. Example 1: We have two LVs in this example. After they were created, the first LV was grown, yeilding two segments in LV1. So, there are two LVs with a total of three segments. Before pvmove: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- After pvmove inserts the temporary pvmove LV: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- Each of the affected LV segments now point to a range of blocks in the pvmove LV, which purposefully corresponds to the segments moved from the original LVs into the temporary pvmove LV. The current implementation goes on from here to mirror the temporary pvmove LV by segment. Further, as the pvmove LV is activated, only one of its segments is actually mirrored (i.e. "moving") at a time. The rest are either complete or not addressed yet. If the pvmove is aborted, those segments that are completed will remain on the destination and those that are not yet addressed or in the process of moving will stay on the source PV. Thus, it is possible to have a partially completed move - some LVs (or certain segments of LVs) on the source PV and some on the destination. Example 2: What 'example 1' might look if it was half-way through the move. --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | | ------------------------- source PV | | 256 - 511 | 512 - 767 | | ------------------------- | || ------------------------- dest PV | 000 - 255 | 256 - 511 | ------------------------- This update allows the user to specify that they would like the pvmove mirror created "by LV" rather than "by segment". That is, the pvmove LV becomes an image in an encapsulating mirror along with the allocated copy image. Example 3: A pvmove that is performed "by LV" rather than "by segment". --------- --------- | LV1s0 | | LV2s0 | --------- --------- | | ------------------------- pvmove0 | * LV-level mirror * | ------------------------- / \ pvmove_mimage0 / pvmove_mimage1 ------------------------- ------------------------- | seg 0 | seg 1 | | seg 0 | seg 1 | ------------------------- ------------------------- | | | | ------------------------- ------------------------- | 000 - 255 | 256 - 511 | | 000 - 255 | 256 - 511 | ------------------------- ------------------------- source PV dest PV The thing that differentiates a pvmove done in this way and a simple "up-convert" from linear to mirror is the preservation of the distinct segments. A normal up-convert would simply allocate the necessary space with no regard for segment boundaries. The pvmove operation must preserve the segments because they are the critical boundary between the segments of the LVs being moved. So, when the pvmove copy image is allocated, all corresponding segments must be allocated. The code that merges ajoining segments that are part of the same LV when the metadata is written must also be avoided in this case. This method of mirroring is unique enough to warrant its own definitional macro, MIRROR_BY_SEGMENTED_LV. This joins the two existing macros: MIRROR_BY_SEG (for original pvmove) and MIRROR_BY_LV (for user created mirrors). The advantages of performing pvmove in this way is that all of the LVs affected can be moved together. It is an all-or-nothing approach that leaves all LV segments on the source PV if the move is aborted. Additionally, a mirror log can be used (in the future) to provide tracking of progress; allowing the copy to continue where it left off in the event there is a deactivation.
2014-06-18 07:59:36 +04:00
return 0;
}
/* Allocator assures aa[0].len <= seg->area_len */
if (aa[0].len < seg->area_len) {
if (!lv_split_segment(lv, seg->le + aa[0].len)) {
log_error("Failed to split segment at %s "
cleanup: add some dots and use display_lvname Just some more VG/LV printing.
2016-11-25 16:08:39 +03:00
"extent " FMTu32 ".",
display_lvname(lv), le);
pvmove: Enable all-or-nothing (atomic) pvmoves pvmove can be used to move single LVs by name or multiple LVs that lie within the specified PV range (e.g. /dev/sdb1:0-1000). When moving more than one LV, the portions of those LVs that are in the range to be moved are added to a new temporary pvmove LV. The LVs then point to the range in the pvmove LV, rather than the PV range. Example 1: We have two LVs in this example. After they were created, the first LV was grown, yeilding two segments in LV1. So, there are two LVs with a total of three segments. Before pvmove: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- After pvmove inserts the temporary pvmove LV: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- Each of the affected LV segments now point to a range of blocks in the pvmove LV, which purposefully corresponds to the segments moved from the original LVs into the temporary pvmove LV. The current implementation goes on from here to mirror the temporary pvmove LV by segment. Further, as the pvmove LV is activated, only one of its segments is actually mirrored (i.e. "moving") at a time. The rest are either complete or not addressed yet. If the pvmove is aborted, those segments that are completed will remain on the destination and those that are not yet addressed or in the process of moving will stay on the source PV. Thus, it is possible to have a partially completed move - some LVs (or certain segments of LVs) on the source PV and some on the destination. Example 2: What 'example 1' might look if it was half-way through the move. --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | | ------------------------- source PV | | 256 - 511 | 512 - 767 | | ------------------------- | || ------------------------- dest PV | 000 - 255 | 256 - 511 | ------------------------- This update allows the user to specify that they would like the pvmove mirror created "by LV" rather than "by segment". That is, the pvmove LV becomes an image in an encapsulating mirror along with the allocated copy image. Example 3: A pvmove that is performed "by LV" rather than "by segment". --------- --------- | LV1s0 | | LV2s0 | --------- --------- | | ------------------------- pvmove0 | * LV-level mirror * | ------------------------- / \ pvmove_mimage0 / pvmove_mimage1 ------------------------- ------------------------- | seg 0 | seg 1 | | seg 0 | seg 1 | ------------------------- ------------------------- | | | | ------------------------- ------------------------- | 000 - 255 | 256 - 511 | | 000 - 255 | 256 - 511 | ------------------------- ------------------------- source PV dest PV The thing that differentiates a pvmove done in this way and a simple "up-convert" from linear to mirror is the preservation of the distinct segments. A normal up-convert would simply allocate the necessary space with no regard for segment boundaries. The pvmove operation must preserve the segments because they are the critical boundary between the segments of the LVs being moved. So, when the pvmove copy image is allocated, all corresponding segments must be allocated. The code that merges ajoining segments that are part of the same LV when the metadata is written must also be avoided in this case. This method of mirroring is unique enough to warrant its own definitional macro, MIRROR_BY_SEGMENTED_LV. This joins the two existing macros: MIRROR_BY_SEG (for original pvmove) and MIRROR_BY_LV (for user created mirrors). The advantages of performing pvmove in this way is that all of the LVs affected can be moved together. It is an all-or-nothing approach that leaves all LV segments on the source PV if the move is aborted. Additionally, a mirror log can be used (in the future) to provide tracking of progress; allowing the copy to continue where it left off in the event there is a deactivation.
2014-06-18 07:59:36 +04:00
return 0;
}
}
current_le += seg->area_len;
}
pvvmove: add a few comments
2014-06-20 14:41:20 +04:00
pvmove: Enable all-or-nothing (atomic) pvmoves pvmove can be used to move single LVs by name or multiple LVs that lie within the specified PV range (e.g. /dev/sdb1:0-1000). When moving more than one LV, the portions of those LVs that are in the range to be moved are added to a new temporary pvmove LV. The LVs then point to the range in the pvmove LV, rather than the PV range. Example 1: We have two LVs in this example. After they were created, the first LV was grown, yeilding two segments in LV1. So, there are two LVs with a total of three segments. Before pvmove: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- After pvmove inserts the temporary pvmove LV: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- Each of the affected LV segments now point to a range of blocks in the pvmove LV, which purposefully corresponds to the segments moved from the original LVs into the temporary pvmove LV. The current implementation goes on from here to mirror the temporary pvmove LV by segment. Further, as the pvmove LV is activated, only one of its segments is actually mirrored (i.e. "moving") at a time. The rest are either complete or not addressed yet. If the pvmove is aborted, those segments that are completed will remain on the destination and those that are not yet addressed or in the process of moving will stay on the source PV. Thus, it is possible to have a partially completed move - some LVs (or certain segments of LVs) on the source PV and some on the destination. Example 2: What 'example 1' might look if it was half-way through the move. --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | | ------------------------- source PV | | 256 - 511 | 512 - 767 | | ------------------------- | || ------------------------- dest PV | 000 - 255 | 256 - 511 | ------------------------- This update allows the user to specify that they would like the pvmove mirror created "by LV" rather than "by segment". That is, the pvmove LV becomes an image in an encapsulating mirror along with the allocated copy image. Example 3: A pvmove that is performed "by LV" rather than "by segment". --------- --------- | LV1s0 | | LV2s0 | --------- --------- | | ------------------------- pvmove0 | * LV-level mirror * | ------------------------- / \ pvmove_mimage0 / pvmove_mimage1 ------------------------- ------------------------- | seg 0 | seg 1 | | seg 0 | seg 1 | ------------------------- ------------------------- | | | | ------------------------- ------------------------- | 000 - 255 | 256 - 511 | | 000 - 255 | 256 - 511 | ------------------------- ------------------------- source PV dest PV The thing that differentiates a pvmove done in this way and a simple "up-convert" from linear to mirror is the preservation of the distinct segments. A normal up-convert would simply allocate the necessary space with no regard for segment boundaries. The pvmove operation must preserve the segments because they are the critical boundary between the segments of the LVs being moved. So, when the pvmove copy image is allocated, all corresponding segments must be allocated. The code that merges ajoining segments that are part of the same LV when the metadata is written must also be avoided in this case. This method of mirroring is unique enough to warrant its own definitional macro, MIRROR_BY_SEGMENTED_LV. This joins the two existing macros: MIRROR_BY_SEG (for original pvmove) and MIRROR_BY_LV (for user created mirrors). The advantages of performing pvmove in this way is that all of the LVs affected can be moved together. It is an all-or-nothing approach that leaves all LV segments on the source PV if the move is aborted. Additionally, a mirror log can be used (in the future) to provide tracking of progress; allowing the copy to continue where it left off in the event there is a deactivation.
2014-06-18 07:59:36 +04:00
current_le = le;
if (!insert_layer_for_lv(lv->vg->cmd, lv, PVMOVE, "_mimage_0")) {
cleanup: add some dots and use display_lvname Just some more VG/LV printing.
2016-11-25 16:08:39 +03:00
log_error("Failed to build pvmove LV-type mirror %s.",
display_lvname(lv));
pvmove: Enable all-or-nothing (atomic) pvmoves pvmove can be used to move single LVs by name or multiple LVs that lie within the specified PV range (e.g. /dev/sdb1:0-1000). When moving more than one LV, the portions of those LVs that are in the range to be moved are added to a new temporary pvmove LV. The LVs then point to the range in the pvmove LV, rather than the PV range. Example 1: We have two LVs in this example. After they were created, the first LV was grown, yeilding two segments in LV1. So, there are two LVs with a total of three segments. Before pvmove: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- After pvmove inserts the temporary pvmove LV: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- Each of the affected LV segments now point to a range of blocks in the pvmove LV, which purposefully corresponds to the segments moved from the original LVs into the temporary pvmove LV. The current implementation goes on from here to mirror the temporary pvmove LV by segment. Further, as the pvmove LV is activated, only one of its segments is actually mirrored (i.e. "moving") at a time. The rest are either complete or not addressed yet. If the pvmove is aborted, those segments that are completed will remain on the destination and those that are not yet addressed or in the process of moving will stay on the source PV. Thus, it is possible to have a partially completed move - some LVs (or certain segments of LVs) on the source PV and some on the destination. Example 2: What 'example 1' might look if it was half-way through the move. --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | | ------------------------- source PV | | 256 - 511 | 512 - 767 | | ------------------------- | || ------------------------- dest PV | 000 - 255 | 256 - 511 | ------------------------- This update allows the user to specify that they would like the pvmove mirror created "by LV" rather than "by segment". That is, the pvmove LV becomes an image in an encapsulating mirror along with the allocated copy image. Example 3: A pvmove that is performed "by LV" rather than "by segment". --------- --------- | LV1s0 | | LV2s0 | --------- --------- | | ------------------------- pvmove0 | * LV-level mirror * | ------------------------- / \ pvmove_mimage0 / pvmove_mimage1 ------------------------- ------------------------- | seg 0 | seg 1 | | seg 0 | seg 1 | ------------------------- ------------------------- | | | | ------------------------- ------------------------- | 000 - 255 | 256 - 511 | | 000 - 255 | 256 - 511 | ------------------------- ------------------------- source PV dest PV The thing that differentiates a pvmove done in this way and a simple "up-convert" from linear to mirror is the preservation of the distinct segments. A normal up-convert would simply allocate the necessary space with no regard for segment boundaries. The pvmove operation must preserve the segments because they are the critical boundary between the segments of the LVs being moved. So, when the pvmove copy image is allocated, all corresponding segments must be allocated. The code that merges ajoining segments that are part of the same LV when the metadata is written must also be avoided in this case. This method of mirroring is unique enough to warrant its own definitional macro, MIRROR_BY_SEGMENTED_LV. This joins the two existing macros: MIRROR_BY_SEG (for original pvmove) and MIRROR_BY_LV (for user created mirrors). The advantages of performing pvmove in this way is that all of the LVs affected can be moved together. It is an all-or-nothing approach that leaves all LV segments on the source PV if the move is aborted. Additionally, a mirror log can be used (in the future) to provide tracking of progress; allowing the copy to continue where it left off in the event there is a deactivation.
2014-06-18 07:59:36 +04:00
return 0;
}
orig_lv = seg_lv(first_seg(lv), 0);
if (!(image_name = dm_pool_strdup(lv->vg->vgmem, orig_lv->name)))
return_0;
image_name[strlen(image_name) - 1] = '1';
if (!(copy_lv = lv_create_empty(image_name, NULL,
orig_lv->status,
ALLOC_INHERIT, lv->vg)))
return_0;
if (!lv_add_mirror_lvs(lv, &copy_lv, 1, MIRROR_IMAGE, region_size))
return_0;
segtypes: Use SEG_TYPE_NAME_ string constants.
2015-09-22 21:04:12 +03:00
if (!(segtype = get_segtype_from_string(lv->vg->cmd, SEG_TYPE_NAME_STRIPED)))
pvmove: Enable all-or-nothing (atomic) pvmoves pvmove can be used to move single LVs by name or multiple LVs that lie within the specified PV range (e.g. /dev/sdb1:0-1000). When moving more than one LV, the portions of those LVs that are in the range to be moved are added to a new temporary pvmove LV. The LVs then point to the range in the pvmove LV, rather than the PV range. Example 1: We have two LVs in this example. After they were created, the first LV was grown, yeilding two segments in LV1. So, there are two LVs with a total of three segments. Before pvmove: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- After pvmove inserts the temporary pvmove LV: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- Each of the affected LV segments now point to a range of blocks in the pvmove LV, which purposefully corresponds to the segments moved from the original LVs into the temporary pvmove LV. The current implementation goes on from here to mirror the temporary pvmove LV by segment. Further, as the pvmove LV is activated, only one of its segments is actually mirrored (i.e. "moving") at a time. The rest are either complete or not addressed yet. If the pvmove is aborted, those segments that are completed will remain on the destination and those that are not yet addressed or in the process of moving will stay on the source PV. Thus, it is possible to have a partially completed move - some LVs (or certain segments of LVs) on the source PV and some on the destination. Example 2: What 'example 1' might look if it was half-way through the move. --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | | ------------------------- source PV | | 256 - 511 | 512 - 767 | | ------------------------- | || ------------------------- dest PV | 000 - 255 | 256 - 511 | ------------------------- This update allows the user to specify that they would like the pvmove mirror created "by LV" rather than "by segment". That is, the pvmove LV becomes an image in an encapsulating mirror along with the allocated copy image. Example 3: A pvmove that is performed "by LV" rather than "by segment". --------- --------- | LV1s0 | | LV2s0 | --------- --------- | | ------------------------- pvmove0 | * LV-level mirror * | ------------------------- / \ pvmove_mimage0 / pvmove_mimage1 ------------------------- ------------------------- | seg 0 | seg 1 | | seg 0 | seg 1 | ------------------------- ------------------------- | | | | ------------------------- ------------------------- | 000 - 255 | 256 - 511 | | 000 - 255 | 256 - 511 | ------------------------- ------------------------- source PV dest PV The thing that differentiates a pvmove done in this way and a simple "up-convert" from linear to mirror is the preservation of the distinct segments. A normal up-convert would simply allocate the necessary space with no regard for segment boundaries. The pvmove operation must preserve the segments because they are the critical boundary between the segments of the LVs being moved. So, when the pvmove copy image is allocated, all corresponding segments must be allocated. The code that merges ajoining segments that are part of the same LV when the metadata is written must also be avoided in this case. This method of mirroring is unique enough to warrant its own definitional macro, MIRROR_BY_SEGMENTED_LV. This joins the two existing macros: MIRROR_BY_SEG (for original pvmove) and MIRROR_BY_LV (for user created mirrors). The advantages of performing pvmove in this way is that all of the LVs affected can be moved together. It is an all-or-nothing approach that leaves all LV segments on the source PV if the move is aborted. Additionally, a mirror log can be used (in the future) to provide tracking of progress; allowing the copy to continue where it left off in the event there is a deactivation.
2014-06-18 07:59:36 +04:00
return_0;
dm_list_iterate_items(aa, &ah->alloced_areas[0]) {
if (!(seg = find_seg_by_le(orig_lv, current_le))) {
cleanup: add some dots and use display_lvname Just some more VG/LV printing.
2016-11-25 16:08:39 +03:00
log_error("Failed to find segment for %s extent " FMTu32 ".",
display_lvname(lv), current_le);
pvmove: Enable all-or-nothing (atomic) pvmoves pvmove can be used to move single LVs by name or multiple LVs that lie within the specified PV range (e.g. /dev/sdb1:0-1000). When moving more than one LV, the portions of those LVs that are in the range to be moved are added to a new temporary pvmove LV. The LVs then point to the range in the pvmove LV, rather than the PV range. Example 1: We have two LVs in this example. After they were created, the first LV was grown, yeilding two segments in LV1. So, there are two LVs with a total of three segments. Before pvmove: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- After pvmove inserts the temporary pvmove LV: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- Each of the affected LV segments now point to a range of blocks in the pvmove LV, which purposefully corresponds to the segments moved from the original LVs into the temporary pvmove LV. The current implementation goes on from here to mirror the temporary pvmove LV by segment. Further, as the pvmove LV is activated, only one of its segments is actually mirrored (i.e. "moving") at a time. The rest are either complete or not addressed yet. If the pvmove is aborted, those segments that are completed will remain on the destination and those that are not yet addressed or in the process of moving will stay on the source PV. Thus, it is possible to have a partially completed move - some LVs (or certain segments of LVs) on the source PV and some on the destination. Example 2: What 'example 1' might look if it was half-way through the move. --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | | ------------------------- source PV | | 256 - 511 | 512 - 767 | | ------------------------- | || ------------------------- dest PV | 000 - 255 | 256 - 511 | ------------------------- This update allows the user to specify that they would like the pvmove mirror created "by LV" rather than "by segment". That is, the pvmove LV becomes an image in an encapsulating mirror along with the allocated copy image. Example 3: A pvmove that is performed "by LV" rather than "by segment". --------- --------- | LV1s0 | | LV2s0 | --------- --------- | | ------------------------- pvmove0 | * LV-level mirror * | ------------------------- / \ pvmove_mimage0 / pvmove_mimage1 ------------------------- ------------------------- | seg 0 | seg 1 | | seg 0 | seg 1 | ------------------------- ------------------------- | | | | ------------------------- ------------------------- | 000 - 255 | 256 - 511 | | 000 - 255 | 256 - 511 | ------------------------- ------------------------- source PV dest PV The thing that differentiates a pvmove done in this way and a simple "up-convert" from linear to mirror is the preservation of the distinct segments. A normal up-convert would simply allocate the necessary space with no regard for segment boundaries. The pvmove operation must preserve the segments because they are the critical boundary between the segments of the LVs being moved. So, when the pvmove copy image is allocated, all corresponding segments must be allocated. The code that merges ajoining segments that are part of the same LV when the metadata is written must also be avoided in this case. This method of mirroring is unique enough to warrant its own definitional macro, MIRROR_BY_SEGMENTED_LV. This joins the two existing macros: MIRROR_BY_SEG (for original pvmove) and MIRROR_BY_LV (for user created mirrors). The advantages of performing pvmove in this way is that all of the LVs affected can be moved together. It is an all-or-nothing approach that leaves all LV segments on the source PV if the move is aborted. Additionally, a mirror log can be used (in the future) to provide tracking of progress; allowing the copy to continue where it left off in the event there is a deactivation.
2014-06-18 07:59:36 +04:00
return 0;
}
if (!(new_seg = alloc_lv_segment(segtype, copy_lv,
lvconvert: add infrastructure for RaidLV reshaping support In order to support striped raid5/6/10 LV reshaping (change of LV type, stripesize or number of legs), this patch introduces infrastructure prerequisites to be used by raid_manip.c extensions in followup patches. This base is needed for allocation of out-of-place reshape space required by the MD raid personalities to avoid writing over data in-place when reading off the current RAID layout or number of legs and writing out the new layout or to a different number of legs (i.e. restripe) Changes: - add members reshape_len to 'struct lv_segment' to store out-of-place reshape length per component rimage - add member data_copies to struct lv_segment to support more than 2 raid10 data copies - make alloc_lv_segment() aware of both reshape_len and data_copies - adjust all alloc_lv_segment() callers to the new API - add functions to retrieve the current data offset (needed for out-of-place reshaping space allocation) and the devices count from the kernel - make libdm deptree code aware of reshape_len - add LV flags for disk add/remove reshaping - support import/export of the new 'struct lv_segment' members - enhance lv_extend/_lv_reduce to cope with reshape_len - add seg_is_*/segtype_is_* macros related to reshaping - add target version check for reshaping - grow rebuilds/writemostly bitmaps to 246 bit to support kernel maximal - enhance libdm deptree code to support data_offset (out-of-place reshaping) and delta_disk (legs add/remove reshaping) target arguments Related: rhbz834579 Related: rhbz1191935 Related: rhbz1191978
2017-02-24 02:50:00 +03:00
seg->le, seg->len, 0, PVMOVE, 0,
NULL, 1, seg->len, 0,
pvmove: Enable all-or-nothing (atomic) pvmoves pvmove can be used to move single LVs by name or multiple LVs that lie within the specified PV range (e.g. /dev/sdb1:0-1000). When moving more than one LV, the portions of those LVs that are in the range to be moved are added to a new temporary pvmove LV. The LVs then point to the range in the pvmove LV, rather than the PV range. Example 1: We have two LVs in this example. After they were created, the first LV was grown, yeilding two segments in LV1. So, there are two LVs with a total of three segments. Before pvmove: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- After pvmove inserts the temporary pvmove LV: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- Each of the affected LV segments now point to a range of blocks in the pvmove LV, which purposefully corresponds to the segments moved from the original LVs into the temporary pvmove LV. The current implementation goes on from here to mirror the temporary pvmove LV by segment. Further, as the pvmove LV is activated, only one of its segments is actually mirrored (i.e. "moving") at a time. The rest are either complete or not addressed yet. If the pvmove is aborted, those segments that are completed will remain on the destination and those that are not yet addressed or in the process of moving will stay on the source PV. Thus, it is possible to have a partially completed move - some LVs (or certain segments of LVs) on the source PV and some on the destination. Example 2: What 'example 1' might look if it was half-way through the move. --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | | ------------------------- source PV | | 256 - 511 | 512 - 767 | | ------------------------- | || ------------------------- dest PV | 000 - 255 | 256 - 511 | ------------------------- This update allows the user to specify that they would like the pvmove mirror created "by LV" rather than "by segment". That is, the pvmove LV becomes an image in an encapsulating mirror along with the allocated copy image. Example 3: A pvmove that is performed "by LV" rather than "by segment". --------- --------- | LV1s0 | | LV2s0 | --------- --------- | | ------------------------- pvmove0 | * LV-level mirror * | ------------------------- / \ pvmove_mimage0 / pvmove_mimage1 ------------------------- ------------------------- | seg 0 | seg 1 | | seg 0 | seg 1 | ------------------------- ------------------------- | | | | ------------------------- ------------------------- | 000 - 255 | 256 - 511 | | 000 - 255 | 256 - 511 | ------------------------- ------------------------- source PV dest PV The thing that differentiates a pvmove done in this way and a simple "up-convert" from linear to mirror is the preservation of the distinct segments. A normal up-convert would simply allocate the necessary space with no regard for segment boundaries. The pvmove operation must preserve the segments because they are the critical boundary between the segments of the LVs being moved. So, when the pvmove copy image is allocated, all corresponding segments must be allocated. The code that merges ajoining segments that are part of the same LV when the metadata is written must also be avoided in this case. This method of mirroring is unique enough to warrant its own definitional macro, MIRROR_BY_SEGMENTED_LV. This joins the two existing macros: MIRROR_BY_SEG (for original pvmove) and MIRROR_BY_LV (for user created mirrors). The advantages of performing pvmove in this way is that all of the LVs affected can be moved together. It is an all-or-nothing approach that leaves all LV segments on the source PV if the move is aborted. Additionally, a mirror log can be used (in the future) to provide tracking of progress; allowing the copy to continue where it left off in the event there is a deactivation.
2014-06-18 07:59:36 +04:00
0, 0, 0, NULL)))
return_0;
for (s = 0; s < ah->area_count; s++) {
if (!set_lv_segment_area_pv(new_seg, s,
aa[s].pv, aa[s].pe))
return_0;
}
dm_list_add(&copy_lv->segments, &new_seg->list);
current_le += seg->area_len;
copy_lv->le_count += seg->area_len;
}
lv->status |= MIRRORED;
/* FIXME: add log */
if (lv->vg->fid->fmt->ops->lv_setup &&
!lv->vg->fid->fmt->ops->lv_setup(lv->vg->fid, lv))
return_0;
return 1;
}
Always insert an intermediate layer for mirrors. Suppress hidden LVs from reports unless --all is given. Use square brackets for hidden LVs in reports. Centralise restrictions on LV names.
2005-06-03 18:49:51 +04:00
/*
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
* Add new areas to mirrored segments
Always insert an intermediate layer for mirrors. Suppress hidden LVs from reports unless --all is given. Use square brackets for hidden LVs in reports. Centralise restrictions on LV names.
2005-06-03 18:49:51 +04:00
*/
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
int lv_add_mirror_areas(struct alloc_handle *ah,
struct logical_volume *lv, uint32_t le,
uint32_t region_size)
Always insert an intermediate layer for mirrors. Suppress hidden LVs from reports unless --all is given. Use square brackets for hidden LVs in reports. Centralise restrictions on LV names.
2005-06-03 18:49:51 +04:00
{
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
struct alloced_area *aa;
Always insert an intermediate layer for mirrors. Suppress hidden LVs from reports unless --all is given. Use square brackets for hidden LVs in reports. Centralise restrictions on LV names.
2005-06-03 18:49:51 +04:00
struct lv_segment *seg;
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
uint32_t current_le = le;
uint32_t s, old_area_count, new_area_count;
Always insert an intermediate layer for mirrors. Suppress hidden LVs from reports unless --all is given. Use square brackets for hidden LVs in reports. Centralise restrictions on LV names.
2005-06-03 18:49:51 +04:00
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
dm_list_iterate_items(aa, &ah->alloced_areas[0]) {
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
if (!(seg = find_seg_by_le(lv, current_le))) {
cleanup: use display_lvname and msg cleanup Use display_lvname in tracing messages. Add some missing 'dots' to messages.
2016-11-16 17:11:07 +03:00
log_error("Failed to find segment for %s extent " FMTu32 ".",
display_lvname(lv), current_le);
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
return 0;
}
Always insert an intermediate layer for mirrors. Suppress hidden LVs from reports unless --all is given. Use square brackets for hidden LVs in reports. Centralise restrictions on LV names.
2005-06-03 18:49:51 +04:00
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
/* Allocator assures aa[0].len <= seg->area_len */
if (aa[0].len < seg->area_len) {
if (!lv_split_segment(lv, seg->le + aa[0].len)) {
cleanup: use display_lvname and msg cleanup Use display_lvname in tracing messages. Add some missing 'dots' to messages.
2016-11-16 17:11:07 +03:00
log_error("Failed to split segment at %s extent " FMTu32 ".",
display_lvname(lv), le);
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
return 0;
}
}
if (!seg_is_mirrored(seg) &&
(!(seg = _convert_seg_to_mirror(seg, region_size, NULL))))
pre-release review cleanups
2008-01-17 20:17:09 +03:00
return_0;
Always insert an intermediate layer for mirrors. Suppress hidden LVs from reports unless --all is given. Use square brackets for hidden LVs in reports. Centralise restrictions on LV names.
2005-06-03 18:49:51 +04:00
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
old_area_count = seg->area_count;
new_area_count = old_area_count + ah->area_count;
lv_manip: add new internal api function
2018-06-23 12:35:22 +03:00
if (!add_lv_segment_areas(seg, new_area_count))
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
return_0;
for (s = 0; s < ah->area_count; s++) {
if (!set_lv_segment_area_pv(seg, s + old_area_count,
aa[s].pv, aa[s].pe))
return_0;
}
current_le += seg->area_len;
Add mirror_seg pointer to lv_segment struct. (incomplete & untested)
2005-10-27 23:58:22 +04:00
}
Always insert an intermediate layer for mirrors. Suppress hidden LVs from reports unless --all is given. Use square brackets for hidden LVs in reports. Centralise restrictions on LV names.
2005-06-03 18:49:51 +04:00
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
lv->status |= MIRRORED;
Always insert an intermediate layer for mirrors. Suppress hidden LVs from reports unless --all is given. Use square brackets for hidden LVs in reports. Centralise restrictions on LV names.
2005-06-03 18:49:51 +04:00
if (lv->vg->fid->fmt->ops->lv_setup &&
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
!lv->vg->fid->fmt->ops->lv_setup(lv->vg->fid, lv))
return_0;
Always insert an intermediate layer for mirrors. Suppress hidden LVs from reports unless --all is given. Use square brackets for hidden LVs in reports. Centralise restrictions on LV names.
2005-06-03 18:49:51 +04:00
return 1;
}
more mirror library functions
2005-10-28 16:48:50 +04:00
/*
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
* Add mirror image LVs to mirrored segments
more mirror library functions
2005-10-28 16:48:50 +04:00
*/
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
int lv_add_mirror_lvs(struct logical_volume *lv,
struct logical_volume **sub_lvs,
uint32_t num_extra_areas,
Switch status from 32-bit to 64-bit The physical_volume, volume_group, logical_volume and lv_segment structures' 'status' member is now uint64_t. The alignment of these structures was also audited to remove holes. The movement of some members in 'volume_group' and 'lv_segment' eliminates holes. The 'physical_volume' structure still has one 4-byte hole after 'pe_size'; the other structures no longer have any holes. Each structures' size has not changed.
2009-11-25 01:55:55 +03:00
uint64_t status, uint32_t region_size)
more mirror library functions
2005-10-28 16:48:50 +04:00
{
uint32_t m;
cleanup: indent changes
2016-11-23 12:48:33 +03:00
uint32_t old_area_count, new_area_count;
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
struct segment_type *mirror_segtype;
cleanup: indent changes
2016-11-23 12:48:33 +03:00
struct lv_segment *seg = first_seg(lv);
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
if (dm_list_size(&lv->segments) != 1 || seg_type(seg, 0) != AREA_LV) {
cleanup: make this error an internal error We shouldn't get here with wrong type.
2016-11-23 19:15:10 +03:00
log_error(INTERNAL_ERROR "Mirror layer must be inserted before adding mirrors.");
Drop backtrace after log_error Just a minor change to not give backtrace when log_error has been just reported.
2012-02-24 02:24:47 +04:00
return 0;
more mirror library functions
2005-10-28 16:48:50 +04:00
}
segtypes: Use SEG_TYPE_NAME_ string constants.
2015-09-22 21:04:12 +03:00
mirror_segtype = get_segtype_from_string(lv->vg->cmd, SEG_TYPE_NAME_MIRROR);
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
if (seg->segtype != mirror_segtype)
if (!(seg = _convert_seg_to_mirror(seg, region_size, NULL)))
return_0;
if (region_size && region_size != seg->region_size) {
debug: more explanatory error message
2018-04-23 23:11:38 +03:00
log_error("Conflicting region_size %u != %u.", region_size, seg->region_size);
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
return 0;
}
more mirror library functions
2005-10-28 16:48:50 +04:00
old_area_count = seg->area_count;
new_area_count = old_area_count + num_extra_areas;
lv_manip: add new internal api function
2018-06-23 12:35:22 +03:00
if (!add_lv_segment_areas(seg, new_area_count))
return_0;
more mirror library functions
2005-10-28 16:48:50 +04:00
Maintain lists of stacked LV segments using each LV.
2008-01-16 22:00:59 +03:00
for (m = 0; m < old_area_count; m++)
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
seg_lv(seg, m)->status |= status;
more mirror library functions
2005-10-28 16:48:50 +04:00
for (m = old_area_count; m < new_area_count; m++) {
Maintain lists of stacked LV segments using each LV.
2008-01-16 22:00:59 +03:00
if (!set_lv_segment_area_lv(seg, m, sub_lvs[m - old_area_count],
0, status))
return_0;
Pre-release cleanups.
2009-05-21 07:04:52 +04:00
lv_set_hidden(sub_lvs[m - old_area_count]);
more mirror library functions
2005-10-28 16:48:50 +04:00
}
more fixes
2007-12-21 02:12:27 +03:00
lv->status |= MIRRORED;
more mirror library functions
2005-10-28 16:48:50 +04:00
return 1;
}
Always insert an intermediate layer for mirrors. Suppress hidden LVs from reports unless --all is given. Use square brackets for hidden LVs in reports. Centralise restrictions on LV names.
2005-06-03 18:49:51 +04:00
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
/*
* Turn an empty LV into a mirror log.
Add ability to create mirrored logs for mirror LVs. This check-in enables the 'mirrored' log type. It can be specified by using the '--mirrorlog' option as follows: #> lvcreate -m1 --mirrorlog mirrored -L 5G -n lv vg I've also included a couple updates to the testsuite. These updates include tests for the new log type, and some fixes to some of the *lvconvert* tests.
2010-03-27 01:15:43 +03:00
*
* FIXME: Mirrored logs are built inefficiently.
* A mirrored log currently uses the same layout that a mirror
* LV uses. The mirror layer sits on top of AREA_LVs which form the
* legs, rather on AREA_PVs. This is done to allow re-use of the
* various mirror functions to also handle the mirrored LV that makes
* up the log.
*
* If we used AREA_PVs under the mirror layer of a log, we could
* assemble it all at once by calling 'lv_add_segment' with the
* appropriate segtype (mirror/stripe), like this:
Start using 64-bit status flags - most of the code already handles them. tdata -> tpool remove commented out definitions from metadata.h formatting clean-ups
2011-09-06 22:49:31 +04:00
* lv_add_segment(ah, ah->area_count, ah->log_area_count,
Add ability to create mirrored logs for mirror LVs. This check-in enables the 'mirrored' log type. It can be specified by using the '--mirrorlog' option as follows: #> lvcreate -m1 --mirrorlog mirrored -L 5G -n lv vg I've also included a couple updates to the testsuite. These updates include tests for the new log type, and some fixes to some of the *lvconvert* tests.
2010-03-27 01:15:43 +03:00
* log_lv, segtype, 0, MIRROR_LOG, 0);
*
* For now, we use the same mechanism to build a mirrored log as we
* do for building a mirrored LV: 1) create initial LV, 2) add a
* mirror layer, and 3) add the remaining copy LVs
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
*/
Add ability to create mirrored logs for mirror LVs. This check-in enables the 'mirrored' log type. It can be specified by using the '--mirrorlog' option as follows: #> lvcreate -m1 --mirrorlog mirrored -L 5G -n lv vg I've also included a couple updates to the testsuite. These updates include tests for the new log type, and some fixes to some of the *lvconvert* tests.
2010-03-27 01:15:43 +03:00
int lv_add_log_segment(struct alloc_handle *ah, uint32_t first_area,
struct logical_volume *log_lv, uint64_t status)
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
{
Add ability to create mirrored logs for mirror LVs. This check-in enables the 'mirrored' log type. It can be specified by using the '--mirrorlog' option as follows: #> lvcreate -m1 --mirrorlog mirrored -L 5G -n lv vg I've also included a couple updates to the testsuite. These updates include tests for the new log type, and some fixes to some of the *lvconvert* tests.
2010-03-27 01:15:43 +03:00
return lv_add_segment(ah, ah->area_count + first_area, 1, log_lv,
segtypes: Add and use new segtype macros. Includes fixing an inverted raid10 segtype check in _raid_add_target_line.
2015-09-24 16:59:07 +03:00
get_segtype_from_string(log_lv->vg->cmd, SEG_TYPE_NAME_STRIPED),
Add ability to create mirrored logs for mirror LVs. This check-in enables the 'mirrored' log type. It can be specified by using the '--mirrorlog' option as follows: #> lvcreate -m1 --mirrorlog mirrored -L 5G -n lv vg I've also included a couple updates to the testsuite. These updates include tests for the new log type, and some fixes to some of the *lvconvert* tests.
2010-03-27 01:15:43 +03:00
0, status, 0);
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
}
This patch adds the ability to extend 0 length layered LVs. This allows us to allocate all images of a mirror (or RAID array) at one time during create. The current mirror implementation still requires a separate allocation for the log, however.
2011-04-07 01:32:20 +04:00
static int _lv_insert_empty_sublvs(struct logical_volume *lv,
const struct segment_type *segtype,
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
uint32_t stripe_size, uint32_t region_size,
This patch adds the ability to extend 0 length layered LVs. This allows us to allocate all images of a mirror (or RAID array) at one time during create. The current mirror implementation still requires a separate allocation for the log, however.
2011-04-07 01:32:20 +04:00
uint32_t devices)
stacked mirror support (incomplete)
2007-12-20 21:55:46 +03:00
{
This patch adds the ability to extend 0 length layered LVs. This allows us to allocate all images of a mirror (or RAID array) at one time during create. The current mirror implementation still requires a separate allocation for the log, however.
2011-04-07 01:32:20 +04:00
struct logical_volume *sub_lv;
uint32_t i;
lvcreate/remove thin_pool and thin volumes (--driverloaded n only)
2011-09-08 20:41:18 +04:00
uint64_t sub_lv_status = 0;
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
const char *layer_name;
cleanup: use NAME_LEN Let's have instant check for max name len when creating subLV name.
2015-11-05 13:58:03 +03:00
char img_name[NAME_LEN];
This patch adds the ability to extend 0 length layered LVs. This allows us to allocate all images of a mirror (or RAID array) at one time during create. The current mirror implementation still requires a separate allocation for the log, however.
2011-04-07 01:32:20 +04:00
struct lv_segment *mapseg;
Explicitely check list size of segments instead of checking for NULL from last_seg and first_seg.
2012-02-28 14:08:20 +04:00
if (lv->le_count || !dm_list_empty(&lv->segments)) {
This patch adds the ability to extend 0 length layered LVs. This allows us to allocate all images of a mirror (or RAID array) at one time during create. The current mirror implementation still requires a separate allocation for the log, however.
2011-04-07 01:32:20 +04:00
log_error(INTERNAL_ERROR
"Non-empty LV passed to _lv_insert_empty_sublv");
return 0;
}
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
if (segtype_is_raid(segtype)) {
lv->status |= RAID;
lvcreate/remove thin_pool and thin volumes (--driverloaded n only)
2011-09-08 20:41:18 +04:00
sub_lv_status = RAID_IMAGE;
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
layer_name = "rimage";
} else if (segtype_is_mirrored(segtype)) {
lv->status |= MIRRORED;
lvcreate/remove thin_pool and thin volumes (--driverloaded n only)
2011-09-08 20:41:18 +04:00
sub_lv_status = MIRROR_IMAGE;
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
layer_name = "mimage";
else
2011-09-06 19:39:46 +04:00
} else
This patch adds the ability to extend 0 length layered LVs. This allows us to allocate all images of a mirror (or RAID array) at one time during create. The current mirror implementation still requires a separate allocation for the log, however.
2011-04-07 01:32:20 +04:00
return_0;
/*
* First, create our top-level segment for our top-level LV
*/
lvconvert: add infrastructure for RaidLV reshaping support In order to support striped raid5/6/10 LV reshaping (change of LV type, stripesize or number of legs), this patch introduces infrastructure prerequisites to be used by raid_manip.c extensions in followup patches. This base is needed for allocation of out-of-place reshape space required by the MD raid personalities to avoid writing over data in-place when reading off the current RAID layout or number of legs and writing out the new layout or to a different number of legs (i.e. restripe) Changes: - add members reshape_len to 'struct lv_segment' to store out-of-place reshape length per component rimage - add member data_copies to struct lv_segment to support more than 2 raid10 data copies - make alloc_lv_segment() aware of both reshape_len and data_copies - adjust all alloc_lv_segment() callers to the new API - add functions to retrieve the current data offset (needed for out-of-place reshaping space allocation) and the devices count from the kernel - make libdm deptree code aware of reshape_len - add LV flags for disk add/remove reshaping - support import/export of the new 'struct lv_segment' members - enhance lv_extend/_lv_reduce to cope with reshape_len - add seg_is_*/segtype_is_* macros related to reshaping - add target version check for reshaping - grow rebuilds/writemostly bitmaps to 246 bit to support kernel maximal - enhance libdm deptree code to support data_offset (out-of-place reshaping) and delta_disk (legs add/remove reshaping) target arguments Related: rhbz834579 Related: rhbz1191935 Related: rhbz1191978
2017-02-24 02:50:00 +03:00
if (!(mapseg = alloc_lv_segment(segtype, lv, 0, 0, 0, lv->status,
thin: simplify thin volume creation Move code for creation of thin volume into a single place out of lv_extend(). This allows to drop extra pool arg for alloc_lv_segment() && lv_extend() and makes code more easier to read and follow.
2014-10-26 10:13:59 +03:00
stripe_size, NULL,
lvconvert: add infrastructure for RaidLV reshaping support In order to support striped raid5/6/10 LV reshaping (change of LV type, stripesize or number of legs), this patch introduces infrastructure prerequisites to be used by raid_manip.c extensions in followup patches. This base is needed for allocation of out-of-place reshape space required by the MD raid personalities to avoid writing over data in-place when reading off the current RAID layout or number of legs and writing out the new layout or to a different number of legs (i.e. restripe) Changes: - add members reshape_len to 'struct lv_segment' to store out-of-place reshape length per component rimage - add member data_copies to struct lv_segment to support more than 2 raid10 data copies - make alloc_lv_segment() aware of both reshape_len and data_copies - adjust all alloc_lv_segment() callers to the new API - add functions to retrieve the current data offset (needed for out-of-place reshaping space allocation) and the devices count from the kernel - make libdm deptree code aware of reshape_len - add LV flags for disk add/remove reshaping - support import/export of the new 'struct lv_segment' members - enhance lv_extend/_lv_reduce to cope with reshape_len - add seg_is_*/segtype_is_* macros related to reshaping - add target version check for reshaping - grow rebuilds/writemostly bitmaps to 246 bit to support kernel maximal - enhance libdm deptree code to support data_offset (out-of-place reshaping) and delta_disk (legs add/remove reshaping) target arguments Related: rhbz834579 Related: rhbz1191935 Related: rhbz1191978
2017-02-24 02:50:00 +03:00
devices, 0, 0, 0, region_size, 0, NULL))) {
cleanup: use NAME_LEN Let's have instant check for max name len when creating subLV name.
2015-11-05 13:58:03 +03:00
log_error("Failed to create mapping segment for %s.",
display_lvname(lv));
This patch adds the ability to extend 0 length layered LVs. This allows us to allocate all images of a mirror (or RAID array) at one time during create. The current mirror implementation still requires a separate allocation for the log, however.
2011-04-07 01:32:20 +04:00
return 0;
}
/*
* Next, create all of our sub_lv's and link them in.
*/
for (i = 0; i < devices; i++) {
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
/* Data LVs */
lvcreate/remove thin_pool and thin volumes (--driverloaded n only)
2011-09-08 20:41:18 +04:00
if (devices > 1) {
cleanup: use NAME_LEN Let's have instant check for max name len when creating subLV name.
2015-11-05 13:58:03 +03:00
if (dm_snprintf(img_name, sizeof(img_name), "%s_%s_%u",
lvcreate/remove thin_pool and thin volumes (--driverloaded n only)
2011-09-08 20:41:18 +04:00
lv->name, layer_name, i) < 0)
cleanup: use NAME_LEN Let's have instant check for max name len when creating subLV name.
2015-11-05 13:58:03 +03:00
goto_bad;
lvcreate/remove thin_pool and thin volumes (--driverloaded n only)
2011-09-08 20:41:18 +04:00
} else {
cleanup: use NAME_LEN Let's have instant check for max name len when creating subLV name.
2015-11-05 13:58:03 +03:00
if (dm_snprintf(img_name, sizeof(img_name), "%s_%s",
lvcreate/remove thin_pool and thin volumes (--driverloaded n only)
2011-09-08 20:41:18 +04:00
lv->name, layer_name) < 0)
cleanup: use NAME_LEN Let's have instant check for max name len when creating subLV name.
2015-11-05 13:58:03 +03:00
goto_bad;
lvcreate/remove thin_pool and thin volumes (--driverloaded n only)
2011-09-08 20:41:18 +04:00
}
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
lvcreate/remove thin_pool and thin volumes (--driverloaded n only)
2011-09-08 20:41:18 +04:00
/* FIXME Should use ALLOC_INHERIT here and inherit from parent LV */
if (!(sub_lv = lv_create_empty(img_name, NULL,
cleanup: use NAME_LEN Let's have instant check for max name len when creating subLV name.
2015-11-05 13:58:03 +03:00
LVM_READ | LVM_WRITE,
lv->alloc, lv->vg)))
This patch adds the ability to extend 0 length layered LVs. This allows us to allocate all images of a mirror (or RAID array) at one time during create. The current mirror implementation still requires a separate allocation for the log, however.
2011-04-07 01:32:20 +04:00
return_0;
lvcreate/remove thin_pool and thin volumes (--driverloaded n only)
2011-09-08 20:41:18 +04:00
Remove old thin code from _lv_insert_empty_sublvs Since thin is not able to use _lv_insert_empty_sublvs, remove its appearence from this function. Start to use extend_pool() function for desired functionality and modify lv_extend() for this.
2011-10-22 20:48:59 +04:00
if (!set_lv_segment_area_lv(mapseg, i, sub_lv, 0, sub_lv_status))
This patch adds the ability to extend 0 length layered LVs. This allows us to allocate all images of a mirror (or RAID array) at one time during create. The current mirror implementation still requires a separate allocation for the log, however.
2011-04-07 01:32:20 +04:00
return_0;
lvcreate/remove thin_pool and thin volumes (--driverloaded n only)
2011-09-08 20:41:18 +04:00
Remove old thin code from _lv_insert_empty_sublvs Since thin is not able to use _lv_insert_empty_sublvs, remove its appearence from this function. Start to use extend_pool() function for desired functionality and modify lv_extend() for this.
2011-10-22 20:48:59 +04:00
/* Metadata LVs for raid */
cleanup: use segtype_is_raid_with_meta Replace with common macro.
2017-11-01 01:16:13 +03:00
if (segtype_is_raid_with_meta(segtype)) {
cleanup: use NAME_LEN Let's have instant check for max name len when creating subLV name.
2015-11-05 13:58:03 +03:00
if (dm_snprintf(img_name, sizeof(img_name), "%s_rmeta_%u",
lv->name, i) < 0)
goto_bad;
/* FIXME Should use ALLOC_INHERIT here and inherit from parent LV */
if (!(sub_lv = lv_create_empty(img_name, NULL,
LVM_READ | LVM_WRITE,
lv->alloc, lv->vg)))
lvcreate/remove thin_pool and thin volumes (--driverloaded n only)
2011-09-08 20:41:18 +04:00
return_0;
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
cleanup: use NAME_LEN Let's have instant check for max name len when creating subLV name.
2015-11-05 13:58:03 +03:00
if (!set_lv_segment_area_lv(mapseg, i, sub_lv, 0, RAID_META))
lvcreate/remove thin_pool and thin volumes (--driverloaded n only)
2011-09-08 20:41:18 +04:00
return_0;
cleanup: use NAME_LEN Let's have instant check for max name len when creating subLV name.
2015-11-05 13:58:03 +03:00
}
This patch adds the ability to extend 0 length layered LVs. This allows us to allocate all images of a mirror (or RAID array) at one time during create. The current mirror implementation still requires a separate allocation for the log, however.
2011-04-07 01:32:20 +04:00
}
Remove old thin code from _lv_insert_empty_sublvs Since thin is not able to use _lv_insert_empty_sublvs, remove its appearence from this function. Start to use extend_pool() function for desired functionality and modify lv_extend() for this.
2011-10-22 20:48:59 +04:00
This patch adds the ability to extend 0 length layered LVs. This allows us to allocate all images of a mirror (or RAID array) at one time during create. The current mirror implementation still requires a separate allocation for the log, however.
2011-04-07 01:32:20 +04:00
dm_list_add(&lv->segments, &mapseg->list);
return 1;
cleanup: use NAME_LEN Let's have instant check for max name len when creating subLV name.
2015-11-05 13:58:03 +03:00
bad:
log_error("Failed to create sub LV name for LV %s.",
display_lvname(lv));
return 0;
This patch adds the ability to extend 0 length layered LVs. This allows us to allocate all images of a mirror (or RAID array) at one time during create. The current mirror implementation still requires a separate allocation for the log, however.
2011-04-07 01:32:20 +04:00
}
raid: fix (de)activation of RaidLVs with visible SubLVs There's a small window during creation of a new RaidLV when rmeta SubLVs are made visible to wipe them in order to prevent erroneous discovery of stale RAID metadata. In case a crash prevents the SubLVs from being committed hidden after such wiping, the RaidLV can still be activated with the SubLVs visible. During deactivation though, a deadlock occurs because the visible SubLVs are deactivated before the RaidLV. The patch adds _check_raid_sublvs to the raid validation in merge.c, an activation check to activate.c (paranoid, because the merge.c check will prevent activation in case of visible SubLVs) and shares the existing wiping function _clear_lvs in raid_manip.c moved to lv_manip.c and renamed to activate_and_wipe_lvlist to remove code duplication. Whilst on it, introduce activate_and_wipe_lv to share with (lvconvert|lvchange).c. Resolves: rhbz1633167
2018-11-01 01:05:08 +03:00
/* Add all rmeta SubLVs for @seg to @lvs and return allocated @lvl to free by caller. */
static struct lv_list *_raid_list_metalvs(struct lv_segment *seg, struct dm_list *lvs)
{
uint32_t s;
struct lv_list *lvl;
dm_list_init(lvs);
if (!(lvl = dm_pool_alloc(seg->lv->vg->vgmem, sizeof(*lvl) * seg->area_count)))
return_NULL;
for (s = 0; s < seg->area_count; s++) {
lvl[s].lv = seg_metalv(seg, s);
dm_list_add(lvs, &lvl[s].list);
}
return lvl;
}
This patch adds the ability to extend 0 length layered LVs. This allows us to allocate all images of a mirror (or RAID array) at one time during create. The current mirror implementation still requires a separate allocation for the log, however.
2011-04-07 01:32:20 +04:00
static int _lv_extend_layered_lv(struct alloc_handle *ah,
struct logical_volume *lv,
uint32_t extents, uint32_t first_area,
raid: fix raid LV resizing The lv_extend/_lv_reduce API doesn't cope with resizing RaidLVs with allocated reshape space and ongoing conversions. Prohibit resizing during conversions and remove the reshape space before processing resize. Add missing seg->data_copies initialisation. Fix typo/comment.
2017-03-08 00:05:23 +03:00
uint32_t mirrors, uint32_t stripes, uint32_t stripe_size)
This patch adds the ability to extend 0 length layered LVs. This allows us to allocate all images of a mirror (or RAID array) at one time during create. The current mirror implementation still requires a separate allocation for the log, however.
2011-04-07 01:32:20 +04:00
{
Allow dm-integrity to be used for raid images dm-integrity stores checksums of the data written to an LV, and returns an error if data read from the LV does not match the previously saved checksum. When used on raid images, dm-raid will correct the error by reading the block from another image, and the device user sees no error. The integrity metadata (checksums) are stored on an internal LV allocated by lvm for each linear image. The internal LV is allocated on the same PV as the image. Create a raid LV with an integrity layer over each raid image (for raid levels 1,4,5,6,10): lvcreate --type raidN --raidintegrity y [options] Add an integrity layer to images of an existing raid LV: lvconvert --raidintegrity y LV Remove the integrity layer from images of a raid LV: lvconvert --raidintegrity n LV Settings Use --raidintegritymode journal|bitmap (journal is default) to configure the method used by dm-integrity to ensure crash consistency. Initialization When integrity is added to an LV, the kernel needs to initialize the integrity metadata/checksums for all blocks in the LV. The data corruption checking performed by dm-integrity will only operate on areas of the LV that are already initialized. The progress of integrity initialization is reported by the "syncpercent" LV reporting field (and under the Cpy%Sync lvs column.) Example: create a raid1 LV with integrity: $ lvcreate --type raid1 -m1 --raidintegrity y -n rr -L1G foo Creating integrity metadata LV rr_rimage_0_imeta with size 12.00 MiB. Logical volume "rr_rimage_0_imeta" created. Creating integrity metadata LV rr_rimage_1_imeta with size 12.00 MiB. Logical volume "rr_rimage_1_imeta" created. Logical volume "rr" created. $ lvs -a foo LV VG Attr LSize Origin Cpy%Sync rr foo rwi-a-r--- 1.00g 4.93 [rr_rimage_0] foo gwi-aor--- 1.00g [rr_rimage_0_iorig] 41.02 [rr_rimage_0_imeta] foo ewi-ao---- 12.00m [rr_rimage_0_iorig] foo -wi-ao---- 1.00g [rr_rimage_1] foo gwi-aor--- 1.00g [rr_rimage_1_iorig] 39.45 [rr_rimage_1_imeta] foo ewi-ao---- 12.00m [rr_rimage_1_iorig] foo -wi-ao---- 1.00g [rr_rmeta_0] foo ewi-aor--- 4.00m [rr_rmeta_1] foo ewi-aor--- 4.00m
2019-11-21 01:07:27 +03:00
struct logical_volume *sub_lvs[DEFAULT_RAID_MAX_IMAGES];
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
const struct segment_type *segtype;
Allow dm-integrity to be used for raid images dm-integrity stores checksums of the data written to an LV, and returns an error if data read from the LV does not match the previously saved checksum. When used on raid images, dm-raid will correct the error by reading the block from another image, and the device user sees no error. The integrity metadata (checksums) are stored on an internal LV allocated by lvm for each linear image. The internal LV is allocated on the same PV as the image. Create a raid LV with an integrity layer over each raid image (for raid levels 1,4,5,6,10): lvcreate --type raidN --raidintegrity y [options] Add an integrity layer to images of an existing raid LV: lvconvert --raidintegrity y LV Remove the integrity layer from images of a raid LV: lvconvert --raidintegrity n LV Settings Use --raidintegritymode journal|bitmap (journal is default) to configure the method used by dm-integrity to ensure crash consistency. Initialization When integrity is added to an LV, the kernel needs to initialize the integrity metadata/checksums for all blocks in the LV. The data corruption checking performed by dm-integrity will only operate on areas of the LV that are already initialized. The progress of integrity initialization is reported by the "syncpercent" LV reporting field (and under the Cpy%Sync lvs column.) Example: create a raid1 LV with integrity: $ lvcreate --type raid1 -m1 --raidintegrity y -n rr -L1G foo Creating integrity metadata LV rr_rimage_0_imeta with size 12.00 MiB. Logical volume "rr_rimage_0_imeta" created. Creating integrity metadata LV rr_rimage_1_imeta with size 12.00 MiB. Logical volume "rr_rimage_1_imeta" created. Logical volume "rr" created. $ lvs -a foo LV VG Attr LSize Origin Cpy%Sync rr foo rwi-a-r--- 1.00g 4.93 [rr_rimage_0] foo gwi-aor--- 1.00g [rr_rimage_0_iorig] 41.02 [rr_rimage_0_imeta] foo ewi-ao---- 12.00m [rr_rimage_0_iorig] foo -wi-ao---- 1.00g [rr_rimage_1] foo gwi-aor--- 1.00g [rr_rimage_1_iorig] 39.45 [rr_rimage_1_imeta] foo ewi-ao---- 12.00m [rr_rimage_1_iorig] foo -wi-ao---- 1.00g [rr_rmeta_0] foo ewi-aor--- 4.00m [rr_rmeta_1] foo ewi-aor--- 4.00m
2019-11-21 01:07:27 +03:00
struct logical_volume *meta_lv, *sub_lv;
style: Miscellaneous tidying up of metadata/lv*
2015-09-23 16:37:52 +03:00
struct lv_segment *seg = first_seg(lv);
Allow dm-integrity to be used for raid images dm-integrity stores checksums of the data written to an LV, and returns an error if data read from the LV does not match the previously saved checksum. When used on raid images, dm-raid will correct the error by reading the block from another image, and the device user sees no error. The integrity metadata (checksums) are stored on an internal LV allocated by lvm for each linear image. The internal LV is allocated on the same PV as the image. Create a raid LV with an integrity layer over each raid image (for raid levels 1,4,5,6,10): lvcreate --type raidN --raidintegrity y [options] Add an integrity layer to images of an existing raid LV: lvconvert --raidintegrity y LV Remove the integrity layer from images of a raid LV: lvconvert --raidintegrity n LV Settings Use --raidintegritymode journal|bitmap (journal is default) to configure the method used by dm-integrity to ensure crash consistency. Initialization When integrity is added to an LV, the kernel needs to initialize the integrity metadata/checksums for all blocks in the LV. The data corruption checking performed by dm-integrity will only operate on areas of the LV that are already initialized. The progress of integrity initialization is reported by the "syncpercent" LV reporting field (and under the Cpy%Sync lvs column.) Example: create a raid1 LV with integrity: $ lvcreate --type raid1 -m1 --raidintegrity y -n rr -L1G foo Creating integrity metadata LV rr_rimage_0_imeta with size 12.00 MiB. Logical volume "rr_rimage_0_imeta" created. Creating integrity metadata LV rr_rimage_1_imeta with size 12.00 MiB. Logical volume "rr_rimage_1_imeta" created. Logical volume "rr" created. $ lvs -a foo LV VG Attr LSize Origin Cpy%Sync rr foo rwi-a-r--- 1.00g 4.93 [rr_rimage_0] foo gwi-aor--- 1.00g [rr_rimage_0_iorig] 41.02 [rr_rimage_0_imeta] foo ewi-ao---- 12.00m [rr_rimage_0_iorig] foo -wi-ao---- 1.00g [rr_rimage_1] foo gwi-aor--- 1.00g [rr_rimage_1_iorig] 39.45 [rr_rimage_1_imeta] foo ewi-ao---- 12.00m [rr_rimage_1_iorig] foo -wi-ao---- 1.00g [rr_rmeta_0] foo ewi-aor--- 4.00m [rr_rmeta_1] foo ewi-aor--- 4.00m
2019-11-21 01:07:27 +03:00
struct lv_segment *sub_lv_seg;
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
uint32_t fa, s;
int clear_metadata = 0;
Allow dm-integrity to be used for raid images dm-integrity stores checksums of the data written to an LV, and returns an error if data read from the LV does not match the previously saved checksum. When used on raid images, dm-raid will correct the error by reading the block from another image, and the device user sees no error. The integrity metadata (checksums) are stored on an internal LV allocated by lvm for each linear image. The internal LV is allocated on the same PV as the image. Create a raid LV with an integrity layer over each raid image (for raid levels 1,4,5,6,10): lvcreate --type raidN --raidintegrity y [options] Add an integrity layer to images of an existing raid LV: lvconvert --raidintegrity y LV Remove the integrity layer from images of a raid LV: lvconvert --raidintegrity n LV Settings Use --raidintegritymode journal|bitmap (journal is default) to configure the method used by dm-integrity to ensure crash consistency. Initialization When integrity is added to an LV, the kernel needs to initialize the integrity metadata/checksums for all blocks in the LV. The data corruption checking performed by dm-integrity will only operate on areas of the LV that are already initialized. The progress of integrity initialization is reported by the "syncpercent" LV reporting field (and under the Cpy%Sync lvs column.) Example: create a raid1 LV with integrity: $ lvcreate --type raid1 -m1 --raidintegrity y -n rr -L1G foo Creating integrity metadata LV rr_rimage_0_imeta with size 12.00 MiB. Logical volume "rr_rimage_0_imeta" created. Creating integrity metadata LV rr_rimage_1_imeta with size 12.00 MiB. Logical volume "rr_rimage_1_imeta" created. Logical volume "rr" created. $ lvs -a foo LV VG Attr LSize Origin Cpy%Sync rr foo rwi-a-r--- 1.00g 4.93 [rr_rimage_0] foo gwi-aor--- 1.00g [rr_rimage_0_iorig] 41.02 [rr_rimage_0_imeta] foo ewi-ao---- 12.00m [rr_rimage_0_iorig] foo -wi-ao---- 1.00g [rr_rimage_1] foo gwi-aor--- 1.00g [rr_rimage_1_iorig] 39.45 [rr_rimage_1_imeta] foo ewi-ao---- 12.00m [rr_rimage_1_iorig] foo -wi-ao---- 1.00g [rr_rmeta_0] foo ewi-aor--- 4.00m [rr_rmeta_1] foo ewi-aor--- 4.00m
2019-11-21 01:07:27 +03:00
int integrity_sub_lvs = 0;
raid0: Add raid0 segment type. This remains experimental and quite restrictive so should only be used for testing at this stage. (E.g. lvreduce is not supported.)
2016-05-23 18:46:38 +03:00
uint32_t area_multiple = 1;
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
style: Miscellaneous tidying up of metadata/lv*
2015-09-23 16:37:52 +03:00
if (!(segtype = get_segtype_from_string(lv->vg->cmd, SEG_TYPE_NAME_STRIPED)))
return_0;
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
/*
* The component devices of a "striped" LV all go in the same
* LV. However, RAID has an LV for each device - making the
* 'stripes' and 'stripe_size' parameters meaningless.
*/
style: Miscellaneous tidying up of metadata/lv*
2015-09-23 16:37:52 +03:00
if (seg_is_raid(seg)) {
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
stripes = 1;
stripe_size = 0;
raid0: Add raid0_meta segment type.
2016-07-02 00:20:54 +03:00
if (seg_is_any_raid0(seg))
raid: Revert _lv_extend_layered_lv non-raid0 area_multiple.
2016-05-24 16:27:05 +03:00
area_multiple = seg->area_count;
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
}
stacked mirror support (incomplete)
2007-12-20 21:55:46 +03:00
Allow dm-integrity to be used for raid images dm-integrity stores checksums of the data written to an LV, and returns an error if data read from the LV does not match the previously saved checksum. When used on raid images, dm-raid will correct the error by reading the block from another image, and the device user sees no error. The integrity metadata (checksums) are stored on an internal LV allocated by lvm for each linear image. The internal LV is allocated on the same PV as the image. Create a raid LV with an integrity layer over each raid image (for raid levels 1,4,5,6,10): lvcreate --type raidN --raidintegrity y [options] Add an integrity layer to images of an existing raid LV: lvconvert --raidintegrity y LV Remove the integrity layer from images of a raid LV: lvconvert --raidintegrity n LV Settings Use --raidintegritymode journal|bitmap (journal is default) to configure the method used by dm-integrity to ensure crash consistency. Initialization When integrity is added to an LV, the kernel needs to initialize the integrity metadata/checksums for all blocks in the LV. The data corruption checking performed by dm-integrity will only operate on areas of the LV that are already initialized. The progress of integrity initialization is reported by the "syncpercent" LV reporting field (and under the Cpy%Sync lvs column.) Example: create a raid1 LV with integrity: $ lvcreate --type raid1 -m1 --raidintegrity y -n rr -L1G foo Creating integrity metadata LV rr_rimage_0_imeta with size 12.00 MiB. Logical volume "rr_rimage_0_imeta" created. Creating integrity metadata LV rr_rimage_1_imeta with size 12.00 MiB. Logical volume "rr_rimage_1_imeta" created. Logical volume "rr" created. $ lvs -a foo LV VG Attr LSize Origin Cpy%Sync rr foo rwi-a-r--- 1.00g 4.93 [rr_rimage_0] foo gwi-aor--- 1.00g [rr_rimage_0_iorig] 41.02 [rr_rimage_0_imeta] foo ewi-ao---- 12.00m [rr_rimage_0_iorig] foo -wi-ao---- 1.00g [rr_rimage_1] foo gwi-aor--- 1.00g [rr_rimage_1_iorig] 39.45 [rr_rimage_1_imeta] foo ewi-ao---- 12.00m [rr_rimage_1_iorig] foo -wi-ao---- 1.00g [rr_rmeta_0] foo ewi-aor--- 4.00m [rr_rmeta_1] foo ewi-aor--- 4.00m
2019-11-21 01:07:27 +03:00
for (s = 0; s < seg->area_count; s++) {
sub_lv = seg_lv(seg, s);
sub_lv_seg = sub_lv ? first_seg(sub_lv) : NULL;
if (sub_lv_seg && seg_is_integrity(sub_lv_seg)) {
sub_lvs[s] = seg_lv(sub_lv_seg, 0);
integrity_sub_lvs = 1;
} else
sub_lvs[s] = sub_lv;
}
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
for (fa = first_area, s = 0; s < seg->area_count; s++) {
Allow dm-integrity to be used for raid images dm-integrity stores checksums of the data written to an LV, and returns an error if data read from the LV does not match the previously saved checksum. When used on raid images, dm-raid will correct the error by reading the block from another image, and the device user sees no error. The integrity metadata (checksums) are stored on an internal LV allocated by lvm for each linear image. The internal LV is allocated on the same PV as the image. Create a raid LV with an integrity layer over each raid image (for raid levels 1,4,5,6,10): lvcreate --type raidN --raidintegrity y [options] Add an integrity layer to images of an existing raid LV: lvconvert --raidintegrity y LV Remove the integrity layer from images of a raid LV: lvconvert --raidintegrity n LV Settings Use --raidintegritymode journal|bitmap (journal is default) to configure the method used by dm-integrity to ensure crash consistency. Initialization When integrity is added to an LV, the kernel needs to initialize the integrity metadata/checksums for all blocks in the LV. The data corruption checking performed by dm-integrity will only operate on areas of the LV that are already initialized. The progress of integrity initialization is reported by the "syncpercent" LV reporting field (and under the Cpy%Sync lvs column.) Example: create a raid1 LV with integrity: $ lvcreate --type raid1 -m1 --raidintegrity y -n rr -L1G foo Creating integrity metadata LV rr_rimage_0_imeta with size 12.00 MiB. Logical volume "rr_rimage_0_imeta" created. Creating integrity metadata LV rr_rimage_1_imeta with size 12.00 MiB. Logical volume "rr_rimage_1_imeta" created. Logical volume "rr" created. $ lvs -a foo LV VG Attr LSize Origin Cpy%Sync rr foo rwi-a-r--- 1.00g 4.93 [rr_rimage_0] foo gwi-aor--- 1.00g [rr_rimage_0_iorig] 41.02 [rr_rimage_0_imeta] foo ewi-ao---- 12.00m [rr_rimage_0_iorig] foo -wi-ao---- 1.00g [rr_rimage_1] foo gwi-aor--- 1.00g [rr_rimage_1_iorig] 39.45 [rr_rimage_1_imeta] foo ewi-ao---- 12.00m [rr_rimage_1_iorig] foo -wi-ao---- 1.00g [rr_rmeta_0] foo ewi-aor--- 4.00m [rr_rmeta_1] foo ewi-aor--- 4.00m
2019-11-21 01:07:27 +03:00
sub_lv = sub_lvs[s];
if (is_temporary_mirror_layer(sub_lv)) {
if (!_lv_extend_layered_lv(ah, sub_lv, extents / area_multiple,
raid: fix raid LV resizing The lv_extend/_lv_reduce API doesn't cope with resizing RaidLVs with allocated reshape space and ongoing conversions. Prohibit resizing during conversions and remove the reshape space before processing resize. Add missing seg->data_copies initialisation. Fix typo/comment.
2017-03-08 00:05:23 +03:00
fa, mirrors, stripes, stripe_size))
stacked mirror support (incomplete)
2007-12-20 21:55:46 +03:00
return_0;
Allow dm-integrity to be used for raid images dm-integrity stores checksums of the data written to an LV, and returns an error if data read from the LV does not match the previously saved checksum. When used on raid images, dm-raid will correct the error by reading the block from another image, and the device user sees no error. The integrity metadata (checksums) are stored on an internal LV allocated by lvm for each linear image. The internal LV is allocated on the same PV as the image. Create a raid LV with an integrity layer over each raid image (for raid levels 1,4,5,6,10): lvcreate --type raidN --raidintegrity y [options] Add an integrity layer to images of an existing raid LV: lvconvert --raidintegrity y LV Remove the integrity layer from images of a raid LV: lvconvert --raidintegrity n LV Settings Use --raidintegritymode journal|bitmap (journal is default) to configure the method used by dm-integrity to ensure crash consistency. Initialization When integrity is added to an LV, the kernel needs to initialize the integrity metadata/checksums for all blocks in the LV. The data corruption checking performed by dm-integrity will only operate on areas of the LV that are already initialized. The progress of integrity initialization is reported by the "syncpercent" LV reporting field (and under the Cpy%Sync lvs column.) Example: create a raid1 LV with integrity: $ lvcreate --type raid1 -m1 --raidintegrity y -n rr -L1G foo Creating integrity metadata LV rr_rimage_0_imeta with size 12.00 MiB. Logical volume "rr_rimage_0_imeta" created. Creating integrity metadata LV rr_rimage_1_imeta with size 12.00 MiB. Logical volume "rr_rimage_1_imeta" created. Logical volume "rr" created. $ lvs -a foo LV VG Attr LSize Origin Cpy%Sync rr foo rwi-a-r--- 1.00g 4.93 [rr_rimage_0] foo gwi-aor--- 1.00g [rr_rimage_0_iorig] 41.02 [rr_rimage_0_imeta] foo ewi-ao---- 12.00m [rr_rimage_0_iorig] foo -wi-ao---- 1.00g [rr_rimage_1] foo gwi-aor--- 1.00g [rr_rimage_1_iorig] 39.45 [rr_rimage_1_imeta] foo ewi-ao---- 12.00m [rr_rimage_1_iorig] foo -wi-ao---- 1.00g [rr_rmeta_0] foo ewi-aor--- 4.00m [rr_rmeta_1] foo ewi-aor--- 4.00m
2019-11-21 01:07:27 +03:00
fa += lv_mirror_count(sub_lv);
stacked mirror support (incomplete)
2007-12-20 21:55:46 +03:00
continue;
}
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
if (!lv_add_segment(ah, fa, stripes, sub_lv, segtype,
This patch adds the ability to extend 0 length layered LVs. This allows us to allocate all images of a mirror (or RAID array) at one time during create. The current mirror implementation still requires a separate allocation for the log, however.
2011-04-07 01:32:20 +04:00
stripe_size, sub_lv->status, 0)) {
log_error("Aborting. Failed to extend %s in %s.",
sub_lv->name, lv->name);
stacked mirror support (incomplete)
2007-12-20 21:55:46 +03:00
return 0;
}
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
raid: fix raid LV resizing The lv_extend/_lv_reduce API doesn't cope with resizing RaidLVs with allocated reshape space and ongoing conversions. Prohibit resizing during conversions and remove the reshape space before processing resize. Add missing seg->data_copies initialisation. Fix typo/comment.
2017-03-08 00:05:23 +03:00
last_seg(lv)->data_copies = mirrors;
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
/* Extend metadata LVs only on initial creation */
raid0: Standardise meta_areas checks before access.
2016-05-24 00:55:13 +03:00
if (seg_is_raid_with_meta(seg) && !lv->le_count) {
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
if (!seg->meta_areas) {
log_error("No meta_areas for RAID type");
return 0;
}
meta_lv = seg_metalv(seg, s);
if (!lv_add_segment(ah, fa + seg->area_count, 1,
meta_lv, segtype, 0,
meta_lv->status, 0)) {
log_error("Failed to extend %s in %s.",
meta_lv->name, lv->name);
return 0;
}
lv_set_visible(meta_lv);
raid: Use inherited tags when wiping rmeta. If there's an activation volume_filter, it might not be possible to activate the rmeta LVs to wipe them. At least inherit any LV tags from the parent LV while attempting this.
2016-04-29 21:49:21 +03:00
/*
* Copy any tags from the new LV to the metadata LV so
* it can be activated temporarily.
*/
if (!str_list_dup(meta_lv->vg->vgmem, &meta_lv->tags, &lv->tags)) {
log_error("Failed to copy tags onto LV %s to clear metadata.", display_lvname(meta_lv));
return 0;
}
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
clear_metadata = 1;
}
fa += stripes;
}
Allow dm-integrity to be used for raid images dm-integrity stores checksums of the data written to an LV, and returns an error if data read from the LV does not match the previously saved checksum. When used on raid images, dm-raid will correct the error by reading the block from another image, and the device user sees no error. The integrity metadata (checksums) are stored on an internal LV allocated by lvm for each linear image. The internal LV is allocated on the same PV as the image. Create a raid LV with an integrity layer over each raid image (for raid levels 1,4,5,6,10): lvcreate --type raidN --raidintegrity y [options] Add an integrity layer to images of an existing raid LV: lvconvert --raidintegrity y LV Remove the integrity layer from images of a raid LV: lvconvert --raidintegrity n LV Settings Use --raidintegritymode journal|bitmap (journal is default) to configure the method used by dm-integrity to ensure crash consistency. Initialization When integrity is added to an LV, the kernel needs to initialize the integrity metadata/checksums for all blocks in the LV. The data corruption checking performed by dm-integrity will only operate on areas of the LV that are already initialized. The progress of integrity initialization is reported by the "syncpercent" LV reporting field (and under the Cpy%Sync lvs column.) Example: create a raid1 LV with integrity: $ lvcreate --type raid1 -m1 --raidintegrity y -n rr -L1G foo Creating integrity metadata LV rr_rimage_0_imeta with size 12.00 MiB. Logical volume "rr_rimage_0_imeta" created. Creating integrity metadata LV rr_rimage_1_imeta with size 12.00 MiB. Logical volume "rr_rimage_1_imeta" created. Logical volume "rr" created. $ lvs -a foo LV VG Attr LSize Origin Cpy%Sync rr foo rwi-a-r--- 1.00g 4.93 [rr_rimage_0] foo gwi-aor--- 1.00g [rr_rimage_0_iorig] 41.02 [rr_rimage_0_imeta] foo ewi-ao---- 12.00m [rr_rimage_0_iorig] foo -wi-ao---- 1.00g [rr_rimage_1] foo gwi-aor--- 1.00g [rr_rimage_1_iorig] 39.45 [rr_rimage_1_imeta] foo ewi-ao---- 12.00m [rr_rimage_1_iorig] foo -wi-ao---- 1.00g [rr_rmeta_0] foo ewi-aor--- 4.00m [rr_rmeta_1] foo ewi-aor--- 4.00m
2019-11-21 01:07:27 +03:00
/*
* In raid+integrity, the lv_iorig raid images have been extended above.
* Now propagate the new lv_iorig sizes up to the integrity LV layers
* that are referencing the lv_iorig.
*/
if (integrity_sub_lvs) {
for (s = 0; s < seg->area_count; s++) {
struct logical_volume *lv_image;
struct logical_volume *lv_iorig;
struct lv_segment *seg_image;
lv_image = seg_lv(seg, s);
seg_image = first_seg(lv_image);
cov: remove unused but set variables
2023-04-26 17:32:23 +03:00
if (!seg_image->integrity_meta_dev) {
Allow dm-integrity to be used for raid images dm-integrity stores checksums of the data written to an LV, and returns an error if data read from the LV does not match the previously saved checksum. When used on raid images, dm-raid will correct the error by reading the block from another image, and the device user sees no error. The integrity metadata (checksums) are stored on an internal LV allocated by lvm for each linear image. The internal LV is allocated on the same PV as the image. Create a raid LV with an integrity layer over each raid image (for raid levels 1,4,5,6,10): lvcreate --type raidN --raidintegrity y [options] Add an integrity layer to images of an existing raid LV: lvconvert --raidintegrity y LV Remove the integrity layer from images of a raid LV: lvconvert --raidintegrity n LV Settings Use --raidintegritymode journal|bitmap (journal is default) to configure the method used by dm-integrity to ensure crash consistency. Initialization When integrity is added to an LV, the kernel needs to initialize the integrity metadata/checksums for all blocks in the LV. The data corruption checking performed by dm-integrity will only operate on areas of the LV that are already initialized. The progress of integrity initialization is reported by the "syncpercent" LV reporting field (and under the Cpy%Sync lvs column.) Example: create a raid1 LV with integrity: $ lvcreate --type raid1 -m1 --raidintegrity y -n rr -L1G foo Creating integrity metadata LV rr_rimage_0_imeta with size 12.00 MiB. Logical volume "rr_rimage_0_imeta" created. Creating integrity metadata LV rr_rimage_1_imeta with size 12.00 MiB. Logical volume "rr_rimage_1_imeta" created. Logical volume "rr" created. $ lvs -a foo LV VG Attr LSize Origin Cpy%Sync rr foo rwi-a-r--- 1.00g 4.93 [rr_rimage_0] foo gwi-aor--- 1.00g [rr_rimage_0_iorig] 41.02 [rr_rimage_0_imeta] foo ewi-ao---- 12.00m [rr_rimage_0_iorig] foo -wi-ao---- 1.00g [rr_rimage_1] foo gwi-aor--- 1.00g [rr_rimage_1_iorig] 39.45 [rr_rimage_1_imeta] foo ewi-ao---- 12.00m [rr_rimage_1_iorig] foo -wi-ao---- 1.00g [rr_rmeta_0] foo ewi-aor--- 4.00m [rr_rmeta_1] foo ewi-aor--- 4.00m
2019-11-21 01:07:27 +03:00
log_error("1");
cleanup: no backtraces needed after log_error Reduce double backtracing.
2021-03-09 13:42:29 +03:00
return 0;
Allow dm-integrity to be used for raid images dm-integrity stores checksums of the data written to an LV, and returns an error if data read from the LV does not match the previously saved checksum. When used on raid images, dm-raid will correct the error by reading the block from another image, and the device user sees no error. The integrity metadata (checksums) are stored on an internal LV allocated by lvm for each linear image. The internal LV is allocated on the same PV as the image. Create a raid LV with an integrity layer over each raid image (for raid levels 1,4,5,6,10): lvcreate --type raidN --raidintegrity y [options] Add an integrity layer to images of an existing raid LV: lvconvert --raidintegrity y LV Remove the integrity layer from images of a raid LV: lvconvert --raidintegrity n LV Settings Use --raidintegritymode journal|bitmap (journal is default) to configure the method used by dm-integrity to ensure crash consistency. Initialization When integrity is added to an LV, the kernel needs to initialize the integrity metadata/checksums for all blocks in the LV. The data corruption checking performed by dm-integrity will only operate on areas of the LV that are already initialized. The progress of integrity initialization is reported by the "syncpercent" LV reporting field (and under the Cpy%Sync lvs column.) Example: create a raid1 LV with integrity: $ lvcreate --type raid1 -m1 --raidintegrity y -n rr -L1G foo Creating integrity metadata LV rr_rimage_0_imeta with size 12.00 MiB. Logical volume "rr_rimage_0_imeta" created. Creating integrity metadata LV rr_rimage_1_imeta with size 12.00 MiB. Logical volume "rr_rimage_1_imeta" created. Logical volume "rr" created. $ lvs -a foo LV VG Attr LSize Origin Cpy%Sync rr foo rwi-a-r--- 1.00g 4.93 [rr_rimage_0] foo gwi-aor--- 1.00g [rr_rimage_0_iorig] 41.02 [rr_rimage_0_imeta] foo ewi-ao---- 12.00m [rr_rimage_0_iorig] foo -wi-ao---- 1.00g [rr_rimage_1] foo gwi-aor--- 1.00g [rr_rimage_1_iorig] 39.45 [rr_rimage_1_imeta] foo ewi-ao---- 12.00m [rr_rimage_1_iorig] foo -wi-ao---- 1.00g [rr_rmeta_0] foo ewi-aor--- 4.00m [rr_rmeta_1] foo ewi-aor--- 4.00m
2019-11-21 01:07:27 +03:00
}
if (!(lv_iorig = seg_lv(seg_image, 0))) {
log_error("2");
cleanup: no backtraces needed after log_error Reduce double backtracing.
2021-03-09 13:42:29 +03:00
return 0;
Allow dm-integrity to be used for raid images dm-integrity stores checksums of the data written to an LV, and returns an error if data read from the LV does not match the previously saved checksum. When used on raid images, dm-raid will correct the error by reading the block from another image, and the device user sees no error. The integrity metadata (checksums) are stored on an internal LV allocated by lvm for each linear image. The internal LV is allocated on the same PV as the image. Create a raid LV with an integrity layer over each raid image (for raid levels 1,4,5,6,10): lvcreate --type raidN --raidintegrity y [options] Add an integrity layer to images of an existing raid LV: lvconvert --raidintegrity y LV Remove the integrity layer from images of a raid LV: lvconvert --raidintegrity n LV Settings Use --raidintegritymode journal|bitmap (journal is default) to configure the method used by dm-integrity to ensure crash consistency. Initialization When integrity is added to an LV, the kernel needs to initialize the integrity metadata/checksums for all blocks in the LV. The data corruption checking performed by dm-integrity will only operate on areas of the LV that are already initialized. The progress of integrity initialization is reported by the "syncpercent" LV reporting field (and under the Cpy%Sync lvs column.) Example: create a raid1 LV with integrity: $ lvcreate --type raid1 -m1 --raidintegrity y -n rr -L1G foo Creating integrity metadata LV rr_rimage_0_imeta with size 12.00 MiB. Logical volume "rr_rimage_0_imeta" created. Creating integrity metadata LV rr_rimage_1_imeta with size 12.00 MiB. Logical volume "rr_rimage_1_imeta" created. Logical volume "rr" created. $ lvs -a foo LV VG Attr LSize Origin Cpy%Sync rr foo rwi-a-r--- 1.00g 4.93 [rr_rimage_0] foo gwi-aor--- 1.00g [rr_rimage_0_iorig] 41.02 [rr_rimage_0_imeta] foo ewi-ao---- 12.00m [rr_rimage_0_iorig] foo -wi-ao---- 1.00g [rr_rimage_1] foo gwi-aor--- 1.00g [rr_rimage_1_iorig] 39.45 [rr_rimage_1_imeta] foo ewi-ao---- 12.00m [rr_rimage_1_iorig] foo -wi-ao---- 1.00g [rr_rmeta_0] foo ewi-aor--- 4.00m [rr_rmeta_1] foo ewi-aor--- 4.00m
2019-11-21 01:07:27 +03:00
}
/* new size in sectors */
lv_image->size = lv_iorig->size;
seg_image->integrity_data_sectors = lv_iorig->size;
/* new size in extents */
lv_image->le_count = lv_iorig->le_count;
seg_image->len = lv_iorig->le_count;
seg_image->area_len = lv_iorig->le_count;
}
}
raid: setup LV size earlier New validation code which does require to not store LV with no size (no segments) revealed this size setup code needs to happen earlier.
2017-10-30 19:23:56 +03:00
seg->len += extents;
if (seg_is_raid(seg))
seg->area_len = seg->len;
else
seg->area_len += extents / area_multiple;
if (!_setup_lv_size(lv, lv->le_count + extents))
return_0;
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
if (clear_metadata) {
raid: fix (de)activation of RaidLVs with visible SubLVs There's a small window during creation of a new RaidLV when rmeta SubLVs are made visible to wipe them in order to prevent erroneous discovery of stale RAID metadata. In case a crash prevents the SubLVs from being committed hidden after such wiping, the RaidLV can still be activated with the SubLVs visible. During deactivation though, a deadlock occurs because the visible SubLVs are deactivated before the RaidLV. The patch adds _check_raid_sublvs to the raid validation in merge.c, an activation check to activate.c (paranoid, because the merge.c check will prevent activation in case of visible SubLVs) and shares the existing wiping function _clear_lvs in raid_manip.c moved to lv_manip.c and renamed to activate_and_wipe_lvlist to remove code duplication. Whilst on it, introduce activate_and_wipe_lv to share with (lvconvert|lvchange).c. Resolves: rhbz1633167
2018-11-01 01:05:08 +03:00
struct volume_group *vg = lv->vg;
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
/*
* We must clear the metadata areas upon creation.
*/
raid: fix (de)activation of RaidLVs with visible SubLVs There's a small window during creation of a new RaidLV when rmeta SubLVs are made visible to wipe them in order to prevent erroneous discovery of stale RAID metadata. In case a crash prevents the SubLVs from being committed hidden after such wiping, the RaidLV can still be activated with the SubLVs visible. During deactivation though, a deadlock occurs because the visible SubLVs are deactivated before the RaidLV. The patch adds _check_raid_sublvs to the raid validation in merge.c, an activation check to activate.c (paranoid, because the merge.c check will prevent activation in case of visible SubLVs) and shares the existing wiping function _clear_lvs in raid_manip.c moved to lv_manip.c and renamed to activate_and_wipe_lvlist to remove code duplication. Whilst on it, introduce activate_and_wipe_lv to share with (lvconvert|lvchange).c. Resolves: rhbz1633167
2018-11-01 01:05:08 +03:00
/*
* Declare the new RaidLV as temporary to avoid visible SubLV
* failures on activation until after we wiped them so that
* we can avoid activating crashed, potentially partially
* wiped RaidLVs.
*/
lv->status |= LV_ACTIVATION_SKIP;
raid: faster rmeta clearing Instead of clearing multiple rmeta device with sequential activation process and waiting for udev for every _rmeta device separately, activate all _rmeta devices first and then clear them and deactivate afterwards. Also update some tracing messages. When anyhing goes wrong during clearing process, always try to deactivate as much _rmeta devices as possible before fail.
2016-11-08 13:54:28 +03:00
raid: fix (de)activation of RaidLVs with visible SubLVs There's a small window during creation of a new RaidLV when rmeta SubLVs are made visible to wipe them in order to prevent erroneous discovery of stale RAID metadata. In case a crash prevents the SubLVs from being committed hidden after such wiping, the RaidLV can still be activated with the SubLVs visible. During deactivation though, a deadlock occurs because the visible SubLVs are deactivated before the RaidLV. The patch adds _check_raid_sublvs to the raid validation in merge.c, an activation check to activate.c (paranoid, because the merge.c check will prevent activation in case of visible SubLVs) and shares the existing wiping function _clear_lvs in raid_manip.c moved to lv_manip.c and renamed to activate_and_wipe_lvlist to remove code duplication. Whilst on it, introduce activate_and_wipe_lv to share with (lvconvert|lvchange).c. Resolves: rhbz1633167
2018-11-01 01:05:08 +03:00
if (test_mode()) {
/* FIXME VG is not in a fully-consistent state here and should not be committed! */
if (!vg_write(vg) || !vg_commit(vg))
return_0;
raid: faster rmeta clearing Instead of clearing multiple rmeta device with sequential activation process and waiting for udev for every _rmeta device separately, activate all _rmeta devices first and then clear them and deactivate afterwards. Also update some tracing messages. When anyhing goes wrong during clearing process, always try to deactivate as much _rmeta devices as possible before fail.
2016-11-08 13:54:28 +03:00
raid: fix (de)activation of RaidLVs with visible SubLVs There's a small window during creation of a new RaidLV when rmeta SubLVs are made visible to wipe them in order to prevent erroneous discovery of stale RAID metadata. In case a crash prevents the SubLVs from being committed hidden after such wiping, the RaidLV can still be activated with the SubLVs visible. During deactivation though, a deadlock occurs because the visible SubLVs are deactivated before the RaidLV. The patch adds _check_raid_sublvs to the raid validation in merge.c, an activation check to activate.c (paranoid, because the merge.c check will prevent activation in case of visible SubLVs) and shares the existing wiping function _clear_lvs in raid_manip.c moved to lv_manip.c and renamed to activate_and_wipe_lvlist to remove code duplication. Whilst on it, introduce activate_and_wipe_lv to share with (lvconvert|lvchange).c. Resolves: rhbz1633167
2018-11-01 01:05:08 +03:00
log_verbose("Test mode: Skipping wiping of metadata areas.");
} else {
struct dm_list meta_lvs;
struct lv_list *lvl;
raid: Use inherited tags when wiping rmeta. If there's an activation volume_filter, it might not be possible to activate the rmeta LVs to wipe them. At least inherit any LV tags from the parent LV while attempting this.
2016-04-29 21:49:21 +03:00
raid: fix (de)activation of RaidLVs with visible SubLVs There's a small window during creation of a new RaidLV when rmeta SubLVs are made visible to wipe them in order to prevent erroneous discovery of stale RAID metadata. In case a crash prevents the SubLVs from being committed hidden after such wiping, the RaidLV can still be activated with the SubLVs visible. During deactivation though, a deadlock occurs because the visible SubLVs are deactivated before the RaidLV. The patch adds _check_raid_sublvs to the raid validation in merge.c, an activation check to activate.c (paranoid, because the merge.c check will prevent activation in case of visible SubLVs) and shares the existing wiping function _clear_lvs in raid_manip.c moved to lv_manip.c and renamed to activate_and_wipe_lvlist to remove code duplication. Whilst on it, introduce activate_and_wipe_lv to share with (lvconvert|lvchange).c. Resolves: rhbz1633167
2018-11-01 01:05:08 +03:00
if (!(lvl = _raid_list_metalvs(seg, &meta_lvs)))
return 0;
lvcreate: remove RaidLV on creation failure In case a newly created RaidLV is blacklisted using config \"activation { volume list = [ ... ] }\" (i.e. its SubLVs stay inactive), the metadata SubLVs can't get wiped thus failing the creation. As a result, the RaidLV together with its SubLVs is left behind in an inconsistent state. Fix by removing the RaidLV and provide a hint about volume_list reasoning. Resolves: rhbz1161347
2018-03-16 17:47:12 +03:00
raid: fix (de)activation of RaidLVs with visible SubLVs There's a small window during creation of a new RaidLV when rmeta SubLVs are made visible to wipe them in order to prevent erroneous discovery of stale RAID metadata. In case a crash prevents the SubLVs from being committed hidden after such wiping, the RaidLV can still be activated with the SubLVs visible. During deactivation though, a deadlock occurs because the visible SubLVs are deactivated before the RaidLV. The patch adds _check_raid_sublvs to the raid validation in merge.c, an activation check to activate.c (paranoid, because the merge.c check will prevent activation in case of visible SubLVs) and shares the existing wiping function _clear_lvs in raid_manip.c moved to lv_manip.c and renamed to activate_and_wipe_lvlist to remove code duplication. Whilst on it, introduce activate_and_wipe_lv to share with (lvconvert|lvchange).c. Resolves: rhbz1633167
2018-11-01 01:05:08 +03:00
/* Wipe lv list committing metadata */
if (!activate_and_wipe_lvlist(&meta_lvs, 1)) {
/* If we failed clearing rmeta SubLVs, try removing the new RaidLV */
lvcreate: remove RaidLV on creation failure In case a newly created RaidLV is blacklisted using config \"activation { volume list = [ ... ] }\" (i.e. its SubLVs stay inactive), the metadata SubLVs can't get wiped thus failing the creation. As a result, the RaidLV together with its SubLVs is left behind in an inconsistent state. Fix by removing the RaidLV and provide a hint about volume_list reasoning. Resolves: rhbz1161347
2018-03-16 17:47:12 +03:00
if (!lv_remove(lv))
log_error("Failed to remove LV");
else if (!vg_write(vg) || !vg_commit(vg))
log_error("Failed to commit VG %s", vg->name);
raid: faster rmeta clearing Instead of clearing multiple rmeta device with sequential activation process and waiting for udev for every _rmeta device separately, activate all _rmeta devices first and then clear them and deactivate afterwards. Also update some tracing messages. When anyhing goes wrong during clearing process, always try to deactivate as much _rmeta devices as possible before fail.
2016-11-08 13:54:28 +03:00
return_0;
lvcreate: remove RaidLV on creation failure In case a newly created RaidLV is blacklisted using config \"activation { volume list = [ ... ] }\" (i.e. its SubLVs stay inactive), the metadata SubLVs can't get wiped thus failing the creation. As a result, the RaidLV together with its SubLVs is left behind in an inconsistent state. Fix by removing the RaidLV and provide a hint about volume_list reasoning. Resolves: rhbz1161347
2018-03-16 17:47:12 +03:00
}
raid: fix (de)activation of RaidLVs with visible SubLVs There's a small window during creation of a new RaidLV when rmeta SubLVs are made visible to wipe them in order to prevent erroneous discovery of stale RAID metadata. In case a crash prevents the SubLVs from being committed hidden after such wiping, the RaidLV can still be activated with the SubLVs visible. During deactivation though, a deadlock occurs because the visible SubLVs are deactivated before the RaidLV. The patch adds _check_raid_sublvs to the raid validation in merge.c, an activation check to activate.c (paranoid, because the merge.c check will prevent activation in case of visible SubLVs) and shares the existing wiping function _clear_lvs in raid_manip.c moved to lv_manip.c and renamed to activate_and_wipe_lvlist to remove code duplication. Whilst on it, introduce activate_and_wipe_lv to share with (lvconvert|lvchange).c. Resolves: rhbz1633167
2018-11-01 01:05:08 +03:00
dm_pool_free(vg->vgmem, lvl);
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
}
raid: faster rmeta clearing Instead of clearing multiple rmeta device with sequential activation process and waiting for udev for every _rmeta device separately, activate all _rmeta devices first and then clear them and deactivate afterwards. Also update some tracing messages. When anyhing goes wrong during clearing process, always try to deactivate as much _rmeta devices as possible before fail.
2016-11-08 13:54:28 +03:00
for (s = 0; s < seg->area_count; s++)
lv_set_hidden(seg_metalv(seg, s));
raid: fix (de)activation of RaidLVs with visible SubLVs There's a small window during creation of a new RaidLV when rmeta SubLVs are made visible to wipe them in order to prevent erroneous discovery of stale RAID metadata. In case a crash prevents the SubLVs from being committed hidden after such wiping, the RaidLV can still be activated with the SubLVs visible. During deactivation though, a deadlock occurs because the visible SubLVs are deactivated before the RaidLV. The patch adds _check_raid_sublvs to the raid validation in merge.c, an activation check to activate.c (paranoid, because the merge.c check will prevent activation in case of visible SubLVs) and shares the existing wiping function _clear_lvs in raid_manip.c moved to lv_manip.c and renamed to activate_and_wipe_lvlist to remove code duplication. Whilst on it, introduce activate_and_wipe_lv to share with (lvconvert|lvchange).c. Resolves: rhbz1633167
2018-11-01 01:05:08 +03:00
lv->status &= ~LV_ACTIVATION_SKIP;
stacked mirror support (incomplete)
2007-12-20 21:55:46 +03:00
}
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
stacked mirror support (incomplete)
2007-12-20 21:55:46 +03:00
return 1;
}
Fix "multisegment RAID1, allocator uses one disk for both legs" In case of e.g. 3 PVs, creating or extending a RaidLV causes SubLV collocation thus putting segments of diffent rimage (and potentially larger rmeta) SubLVs onto the same PV. For redundant RaidLVs this'll compromise redundancy. Fix by detecting such bogus allocation on lvcreate/lvextend and reject the request.
2023-05-10 19:22:11 +03:00
/* Check either RAID images and metas are being allocated redundantly. */
static int _lv_raid_redundant(struct logical_volume *lv,
struct dm_list *allocatable_pvs, int meta)
{
uint32_t nlvs, s;
struct lv_segment *seg = first_seg(lv);
struct pv_list *pvl;
if (meta && !seg->meta_areas)
return 1;
dm_list_iterate_items(pvl, allocatable_pvs) {
nlvs = 0;
for (s = 0; s < seg->area_count; s++) {
struct logical_volume *slv = meta ? seg_metalv(seg, s) : seg_lv(seg, s);
tests: integrity-caching: ensure raid redundancy The recent fix 05c2b10c5d0a9 ensures that raid LV images are not using the same devices. This was happening in the lvextend commands used by this test, so fix the test to use more devices to ensue redundancy.
2023-05-17 22:15:25 +03:00
if (slv && lv_is_on_pv(slv, pvl->pv) && nlvs++) {
log_error("LV %s using PV %s is not redundant.",
display_lvname(slv), dev_name(pvl->pv->dev));
Fix "multisegment RAID1, allocator uses one disk for both legs" In case of e.g. 3 PVs, creating or extending a RaidLV causes SubLV collocation thus putting segments of diffent rimage (and potentially larger rmeta) SubLVs onto the same PV. For redundant RaidLVs this'll compromise redundancy. Fix by detecting such bogus allocation on lvcreate/lvextend and reject the request.
2023-05-10 19:22:11 +03:00
return 0;
tests: integrity-caching: ensure raid redundancy The recent fix 05c2b10c5d0a9 ensures that raid LV images are not using the same devices. This was happening in the lvextend commands used by this test, so fix the test to use more devices to ensue redundancy.
2023-05-17 22:15:25 +03:00
}
Fix "multisegment RAID1, allocator uses one disk for both legs" In case of e.g. 3 PVs, creating or extending a RaidLV causes SubLV collocation thus putting segments of diffent rimage (and potentially larger rmeta) SubLVs onto the same PV. For redundant RaidLVs this'll compromise redundancy. Fix by detecting such bogus allocation on lvcreate/lvextend and reject the request.
2023-05-10 19:22:11 +03:00
}
}
return 1;
}
/* Check both RAID images and metas are being allocated redundantly. */
static int _lv_raid_redundant_allocation(struct logical_volume *lv, struct dm_list *allocatable_pvs)
{
return _lv_raid_redundant(lv, allocatable_pvs, 0) &&
_lv_raid_redundant(lv, allocatable_pvs, 1);
}
o Factor _allocate out for use by lv_extend
2001-11-06 14:31:29 +03:00
/*
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
* Entry point for single-step LV allocation + extension.
allocation: misc fixes for percent/raid rounding Several fixes for the recent changes that treat allocation percentages as upper limits. Improve messages to make it easier to see what is happening. Fix some cases that failed with errors when they didn't need to. Fix crashes when first_seg() returns NULL. Remove a couple of log_errors that were actually debugging messages.
2014-02-22 04:26:01 +04:00
* Extents is the number of logical extents to append to the LV unless
* approx_alloc is set when it is an upper limit for the total number of
* extents to use from the VG.
*
* FIXME The approx_alloc raid/stripe conversion should be performed
* before calling this function.
o Factor _allocate out for use by lv_extend
2001-11-06 14:31:29 +03:00
*/
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
int lv_extend(struct logical_volume *lv,
Make SIZE_SHORT the default for display_size(). Fix some memory leaks in error paths found by coverity. Use C99 struct initialisers. Move DEFS into configure.h. Clean-ups to remove miscellaneous compiler warnings.
2006-05-10 01:23:51 +04:00
const struct segment_type *segtype,
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
uint32_t stripes, uint32_t stripe_size,
This patch adds the ability to extend 0 length layered LVs. This allows us to allocate all images of a mirror (or RAID array) at one time during create. The current mirror implementation still requires a separate allocation for the log, however.
2011-04-07 01:32:20 +04:00
uint32_t mirrors, uint32_t region_size,
thin: simplify thin volume creation Move code for creation of thin volume into a single place out of lv_extend(). This allows to drop extra pool arg for alloc_lv_segment() && lv_extend() and makes code more easier to read and follow.
2014-10-26 10:13:59 +03:00
uint32_t extents,
allocation: Allow approximate allocation when specifying size in percent Introduce a new parameter called "approx_alloc" that is set when the desired size of a new LV is specified in percentage terms. If set, the allocation code tries to get as much space as it can but does not fail if can at least get some. One of the practical implications is that users can now specify 100%FREE when creating RAID LVs, like this: ~> lvcreate --type raid5 -i 2 -l 100%FREE -n lv vg
2014-02-14 07:10:28 +04:00
struct dm_list *allocatable_pvs, alloc_policy_t alloc,
int approx_alloc)
o Factor _allocate out for use by lv_extend
2001-11-06 14:31:29 +03:00
{
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
int r = 1;
lvcreate/remove thin_pool and thin volumes (--driverloaded n only)
2011-09-08 20:41:18 +04:00
int log_count = 0;
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
struct alloc_handle *ah;
lvcreate/remove thin_pool and thin volumes (--driverloaded n only)
2011-09-08 20:41:18 +04:00
uint32_t sub_lv_count;
lvextend: Reinstate --nosync logic for mirrors. Reinstate the logic for syncing extensions of mirrors created with --nosync. (Inadvertently disabled by the approximate allocation changes.)
2014-08-28 03:40:09 +04:00
uint32_t old_extents;
uint32_t new_extents; /* Total logical size after extension. */
cleanup: fix warning about shadowed declaration Avoid shadowing lv_size as lv_size() is already defined function in lv.h
2017-02-12 19:47:35 +03:00
uint64_t raid_size;
lvcreate/remove thin_pool and thin volumes (--driverloaded n only)
2011-09-08 20:41:18 +04:00
allocation: misc fixes for percent/raid rounding Several fixes for the recent changes that treat allocation percentages as upper limits. Improve messages to make it easier to see what is happening. Fix some cases that failed with errors when they didn't need to. Fix crashes when first_seg() returns NULL. Remove a couple of log_errors that were actually debugging messages.
2014-02-22 04:26:01 +04:00
log_very_verbose("Adding segment of type %s to LV %s.", segtype->name, lv->name);
o Factor _allocate out for use by lv_extend
2001-11-06 14:31:29 +03:00
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
if (segtype_is_virtual(segtype))
thin: simplify thin volume creation Move code for creation of thin volume into a single place out of lv_extend(). This allows to drop extra pool arg for alloc_lv_segment() && lv_extend() and makes code more easier to read and follow.
2014-10-26 10:13:59 +03:00
return lv_add_virtual_segment(lv, 0u, extents, segtype);
Add --type to lvcreate/resize. Add virtual segment types, zero and error. A large sparse device can be constructed as a writeable snapshot of a large zero device.
2004-05-11 20:01:58 +04:00
raid0: Add raid0_meta segment type.
2016-07-02 00:20:54 +03:00
if (!lv->le_count) {
if (segtype_is_pool(segtype))
/*
* Pool allocations treat the metadata device like a mirror log.
*/
/* FIXME Support striped metadata pool */
log_count = 1;
else if (segtype_is_raid0_meta(segtype))
/* Extend raid0 metadata LVs too */
log_count = stripes;
cleanup: use segtype_is_raid_with_meta Replace with common macro.
2017-11-01 01:16:13 +03:00
else if (segtype_is_raid_with_meta(segtype))
raid0: Add raid0_meta segment type.
2016-07-02 00:20:54 +03:00
log_count = mirrors * stripes;
}
Track unreserved space for all alloc policies and then permit NORMAL to place log and data on same single PV.
2012-02-01 06:10:45 +04:00
/* FIXME log_count should be 1 for mirrors */
lvcreate parsing for thin provisioning. The rest is incomplete so this isn't usable yet.
2011-09-06 04:26:42 +04:00
lvreduce/lvresize: add ability to reduce the size of a RaidLV - support shrinking of raid0/1/4/5/6/10 LVs - enhance lvresize-raid.sh tests: add raid0* and raid10 - fix have_raid4 in aux.sh to allow lv_resize-raid.sh and other scripts to test raid4 Resolves: rhbz1394048
2017-02-10 00:41:28 +03:00
if (segtype_is_raid(segtype) && !segtype_is_any_raid0(segtype)) {
cleanup: fix warning about shadowed declaration Avoid shadowing lv_size as lv_size() is already defined function in lv.h
2017-02-12 19:47:35 +03:00
raid_size = ((uint64_t) lv->le_count + extents) * lv->vg->extent_size;
lvreduce/lvresize: add ability to reduce the size of a RaidLV - support shrinking of raid0/1/4/5/6/10 LVs - enhance lvresize-raid.sh tests: add raid0* and raid10 - fix have_raid4 in aux.sh to allow lv_resize-raid.sh and other scripts to test raid4 Resolves: rhbz1394048
2017-02-10 00:41:28 +03:00
/*
* The MD bitmap is limited to being able to track 2^21 regions.
* The region_size must be adjusted to meet that criteria
* unless raid0/raid0_meta, which doesn't have a bitmap.
*/
cleanup: fix warning about shadowed declaration Avoid shadowing lv_size as lv_size() is already defined function in lv.h
2017-02-12 19:47:35 +03:00
region_size = raid_ensure_min_region_size(lv, raid_size, region_size);
lvreduce/lvresize: add ability to reduce the size of a RaidLV - support shrinking of raid0/1/4/5/6/10 LVs - enhance lvresize-raid.sh tests: add raid0* and raid10 - fix have_raid4 in aux.sh to allow lv_resize-raid.sh and other scripts to test raid4 Resolves: rhbz1394048
2017-02-10 00:41:28 +03:00
if (first_seg(lv))
first_seg(lv)->region_size = region_size;
}
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
if (!(ah = allocate_extents(lv->vg, lv, segtype, stripes, mirrors,
lvcreate/remove thin_pool and thin volumes (--driverloaded n only)
2011-09-08 20:41:18 +04:00
log_count, region_size, extents,
allocation: Allow approximate allocation when specifying size in percent Introduce a new parameter called "approx_alloc" that is set when the desired size of a new LV is specified in percentage terms. If set, the allocation code tries to get as much space as it can but does not fail if can at least get some. One of the practical implications is that users can now specify 100%FREE when creating RAID LVs, like this: ~> lvcreate --type raid5 -i 2 -l 100%FREE -n lv vg
2014-02-14 07:10:28 +04:00
allocatable_pvs, alloc, approx_alloc, NULL)))
drop mirrored_pv/mirrored_pe from alloc handle
2007-11-22 17:54:35 +03:00
return_0;
o Factor _allocate out for use by lv_extend
2001-11-06 14:31:29 +03:00
lvextend: Reinstate --nosync logic for mirrors. Reinstate the logic for syncing extensions of mirrors created with --nosync. (Inadvertently disabled by the approximate allocation changes.)
2014-08-28 03:40:09 +04:00
new_extents = ah->new_extents;
cleanup: use segtype_is_raid_with_meta Replace with common macro.
2017-11-01 01:16:13 +03:00
if (segtype_is_raid_with_meta(segtype))
lvextend: Reinstate --nosync logic for mirrors. Reinstate the logic for syncing extensions of mirrors created with --nosync. (Inadvertently disabled by the approximate allocation changes.)
2014-08-28 03:40:09 +04:00
new_extents -= ah->log_len * ah->area_multiple;
allocation: Allow approximate allocation when specifying size in percent Introduce a new parameter called "approx_alloc" that is set when the desired size of a new LV is specified in percentage terms. If set, the allocation code tries to get as much space as it can but does not fail if can at least get some. One of the practical implications is that users can now specify 100%FREE when creating RAID LVs, like this: ~> lvcreate --type raid5 -i 2 -l 100%FREE -n lv vg
2014-02-14 07:10:28 +04:00
thin: simplify thin volume creation Move code for creation of thin volume into a single place out of lv_extend(). This allows to drop extra pool arg for alloc_lv_segment() && lv_extend() and makes code more easier to read and follow.
2014-10-26 10:13:59 +03:00
if (segtype_is_pool(segtype)) {
thin: fix resize of stacked thin pool volume When the pool is created from non-linear target the more complex rules have to be used and stacking needs to properly decode args for _tdata LV. Also proper allocation policies are being used according to those set in lvm2 metadata for data and metadata LVs. Also properly check for active pool and extra code to active it temporarily. With this fix it's now possible to use: lvcreate -L20 -m2 -n pool vg --alloc anywhere lvcreate -L10 -m2 -n poolm vg --alloc anywhere lvconvert --thinpool vg/pool --poolmetadata vg/poolm lvresize -L+10 vg/pool
2013-09-06 12:54:50 +04:00
if (!(r = create_pool(lv, segtype, ah, stripes, stripe_size)))
Remove old thin code from _lv_insert_empty_sublvs Since thin is not able to use _lv_insert_empty_sublvs, remove its appearence from this function. Start to use extend_pool() function for desired functionality and modify lv_extend() for this.
2011-10-22 20:48:59 +04:00
stack;
mirror: checking for mirror segtype Checking more correctly for mirror segtype here instead of mirrored one which can be also 'raid'.
2018-04-20 11:01:28 +03:00
} else if (!segtype_is_mirror(segtype) && !segtype_is_raid(segtype)) {
Improve lv_extend stack reporting and some code cleanup with setting return value.
2011-10-29 00:23:24 +04:00
if (!(r = lv_add_segment(ah, 0, ah->area_count, lv, segtype,
stripe_size, 0u, 0)))
stack;
} else {
Remove old thin code from _lv_insert_empty_sublvs Since thin is not able to use _lv_insert_empty_sublvs, remove its appearence from this function. Start to use extend_pool() function for desired functionality and modify lv_extend() for this.
2011-10-22 20:48:59 +04:00
/*
* For RAID, all the devices are AREA_LV.
* However, for 'mirror on stripe' using non-RAID targets,
* the mirror legs are AREA_LV while the stripes underneath
* are AREA_PV.
*/
if (segtype_is_raid(segtype))
sub_lv_count = mirrors * stripes + segtype->parity_devs;
else
sub_lv_count = mirrors;
lvextend: Reinstate --nosync logic for mirrors. Reinstate the logic for syncing extensions of mirrors created with --nosync. (Inadvertently disabled by the approximate allocation changes.)
2014-08-28 03:40:09 +04:00
old_extents = lv->le_count;
This patch adds the ability to extend 0 length layered LVs. This allows us to allocate all images of a mirror (or RAID array) at one time during create. The current mirror implementation still requires a separate allocation for the log, however.
2011-04-07 01:32:20 +04:00
if (!lv->le_count &&
Improve lv_extend stack reporting and some code cleanup with setting return value.
2011-10-29 00:23:24 +04:00
!(r = _lv_insert_empty_sublvs(lv, segtype, stripe_size,
region_size, sub_lv_count))) {
This patch adds the ability to extend 0 length layered LVs. This allows us to allocate all images of a mirror (or RAID array) at one time during create. The current mirror implementation still requires a separate allocation for the log, however.
2011-04-07 01:32:20 +04:00
log_error("Failed to insert layer for %s", lv->name);
Improve lv_extend stack reporting and some code cleanup with setting return value.
2011-10-29 00:23:24 +04:00
goto out;
This patch adds the ability to extend 0 length layered LVs. This allows us to allocate all images of a mirror (or RAID array) at one time during create. The current mirror implementation still requires a separate allocation for the log, however.
2011-04-07 01:32:20 +04:00
}
o Factor _allocate out for use by lv_extend
2001-11-06 14:31:29 +03:00
lvextend: Reinstate --nosync logic for mirrors. Reinstate the logic for syncing extensions of mirrors created with --nosync. (Inadvertently disabled by the approximate allocation changes.)
2014-08-28 03:40:09 +04:00
if (!(r = _lv_extend_layered_lv(ah, lv, new_extents - lv->le_count, 0,
raid: fix raid LV resizing The lv_extend/_lv_reduce API doesn't cope with resizing RaidLVs with allocated reshape space and ongoing conversions. Prohibit resizing during conversions and remove the reshape space before processing resize. Add missing seg->data_copies initialisation. Fix typo/comment.
2017-03-08 00:05:23 +03:00
mirrors, stripes, stripe_size)))
Remove double-hack for setting metadata size Drop the second lv_extend and set 128MB directly in the first hack place.
2011-10-21 13:55:50 +04:00
goto_out;
Allow 'nosync' extension of mirrors. This patch allows a mirror to be extended without an initial resync of the extended portion. It compliments the existing '--nosync' option to lvcreate. This action can be done implicitly if the mirror was created with the '--nosync' option, or explicitly if the '--nosync' option is used when extending the device. Here are the operational criteria: 1) A mirror created with '--nosync' should extend with 'nosync' implicitly [EXAMPLE]# lvs vg; lvextend -L +5G vg/lv ; lvs vg LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg Mwi-a-m- 5.00g lv_mlog 100.00 Extending 2 mirror images. Extending logical volume lv to 10.00 GiB Logical volume lv successfully resized LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg Mwi-a-m- 10.00g lv_mlog 100.00 2) The 'M' attribute ('M' signifies a mirror created with '--nosync', while 'm' signifies a mirror created w/o '--nosync') must be preserved when extending a mirror created with '--nosync'. See #1 for example of 'M' attribute. 3) A mirror created without '--nosync' should extend with 'nosync' only when '--nosync' is explicitly used when extending. [EXAMPLE]# lvs vg; lvextend -L +5G vg/lv; lvs vg LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg mwi-a-m- 20.00m lv_mlog 100.00 Extending 2 mirror images. Extending logical volume lv to 5.02 GiB Logical volume lv successfully resized LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg mwi-a-m- 5.02g lv_mlog 0.39 vs. [EXAMPLE]# lvs vg; lvextend -L +5G vg/lv --nosync; lvs vg LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg mwi-a-m- 20.00m lv_mlog 100.00 Extending 2 mirror images. Extending logical volume lv to 5.02 GiB Logical volume lv successfully resized LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg Mwi-a-m- 5.02g lv_mlog 100.00 4) The 'm' attribute must change to 'M' when extending a mirror created without '--nosync' is extended with the '--nosync' option. (See #3 examples above.) 5) An inactive mirror's sync percent cannot be determined definitively, so it must not be allowed to skip resync. Instead, the extend should ask the user if they want to extend while performing a resync. [EXAMPLE]# lvchange -an vg/lv [EXAMPLE]# lvextend -L +5G vg/lv Extending 2 mirror images. Extending logical volume lv to 10.00 GiB vg/lv is not active. Unable to get sync percent. Do full resync of extended portion of vg/lv? [y/n]: y Logical volume lv successfully resized 6) A mirror that is performing recovery (as opposed to an initial sync) - like after a failure - is not allowed to extend with either an implicit or explicit nosync option. [You can simulate this with a 'corelog' mirror because when it is reactivated, it must be recovered every time.] [EXAMPLE]# lvcreate -m1 -L 5G -n lv vg --nosync --corelog WARNING: New mirror won't be synchronised. Don't read what you didn't write! Logical volume "lv" created [EXAMPLE]# lvs vg LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg Mwi-a-m- 5.00g 100.00 [EXAMPLE]# lvchange -an vg/lv; lvchange -ay vg/lv; lvs vg LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg Mwi-a-m- 5.00g 0.08 [EXAMPLE]# lvextend -L +5G vg/lv Extending 2 mirror images. Extending logical volume lv to 10.00 GiB vg/lv cannot be extended while it is recovering. 7) If 'no' is selected in #5 or if the condition in #6 is hit, it should not result in the mirror being resized or the 'm/M' attribute being changed. NOTE: A mirror created with '--nosync' behaves differently than one created without it when performing an extension. The former cannot be extended when the mirror is recovering (unless in-active), while the latter can. This is a reasonable thing to do since recovery of a mirror doesn't take long (at least in the case of an on-disk log) and it would cause far more time in degraded mode if the extension w/o '--nosync' was allowed. It might be reasonable to add the ability to force the operation in the future. This should /not/ force a nosync extension, but rather force a sync'ed extension. IOW, the user would be saying, "Yes, yes... I know recovery won't take long and that I'll be adding significantly to the time spent in degraded mode, but I need the extra space right now!".
2011-10-06 19:32:26 +04:00
Fix "multisegment RAID1, allocator uses one disk for both legs" In case of e.g. 3 PVs, creating or extending a RaidLV causes SubLV collocation thus putting segments of diffent rimage (and potentially larger rmeta) SubLVs onto the same PV. For redundant RaidLVs this'll compromise redundancy. Fix by detecting such bogus allocation on lvcreate/lvextend and reject the request.
2023-05-10 19:22:11 +03:00
if (segtype_is_raid(segtype) &&
alloc != ALLOC_ANYWHERE &&
!(r = _lv_raid_redundant_allocation(lv, allocatable_pvs))) {
log_error("Insufficient suitable allocatable extents for logical volume %s", display_lvname(lv));
if (!lv_remove(lv) || !vg_write(lv->vg) || !vg_commit(lv->vg))
return_0;
goto out;
}
Allow dm-integrity to be used for raid images dm-integrity stores checksums of the data written to an LV, and returns an error if data read from the LV does not match the previously saved checksum. When used on raid images, dm-raid will correct the error by reading the block from another image, and the device user sees no error. The integrity metadata (checksums) are stored on an internal LV allocated by lvm for each linear image. The internal LV is allocated on the same PV as the image. Create a raid LV with an integrity layer over each raid image (for raid levels 1,4,5,6,10): lvcreate --type raidN --raidintegrity y [options] Add an integrity layer to images of an existing raid LV: lvconvert --raidintegrity y LV Remove the integrity layer from images of a raid LV: lvconvert --raidintegrity n LV Settings Use --raidintegritymode journal|bitmap (journal is default) to configure the method used by dm-integrity to ensure crash consistency. Initialization When integrity is added to an LV, the kernel needs to initialize the integrity metadata/checksums for all blocks in the LV. The data corruption checking performed by dm-integrity will only operate on areas of the LV that are already initialized. The progress of integrity initialization is reported by the "syncpercent" LV reporting field (and under the Cpy%Sync lvs column.) Example: create a raid1 LV with integrity: $ lvcreate --type raid1 -m1 --raidintegrity y -n rr -L1G foo Creating integrity metadata LV rr_rimage_0_imeta with size 12.00 MiB. Logical volume "rr_rimage_0_imeta" created. Creating integrity metadata LV rr_rimage_1_imeta with size 12.00 MiB. Logical volume "rr_rimage_1_imeta" created. Logical volume "rr" created. $ lvs -a foo LV VG Attr LSize Origin Cpy%Sync rr foo rwi-a-r--- 1.00g 4.93 [rr_rimage_0] foo gwi-aor--- 1.00g [rr_rimage_0_iorig] 41.02 [rr_rimage_0_imeta] foo ewi-ao---- 12.00m [rr_rimage_0_iorig] foo -wi-ao---- 1.00g [rr_rimage_1] foo gwi-aor--- 1.00g [rr_rimage_1_iorig] 39.45 [rr_rimage_1_imeta] foo ewi-ao---- 12.00m [rr_rimage_1_iorig] foo -wi-ao---- 1.00g [rr_rmeta_0] foo ewi-aor--- 4.00m [rr_rmeta_1] foo ewi-aor--- 4.00m
2019-11-21 01:07:27 +03:00
if (lv_raid_has_integrity(lv)) {
if (!lv_extend_integrity_in_raid(lv, allocatable_pvs)) {
r = 0;
goto_out;
}
}
Allow 'nosync' extension of mirrors. This patch allows a mirror to be extended without an initial resync of the extended portion. It compliments the existing '--nosync' option to lvcreate. This action can be done implicitly if the mirror was created with the '--nosync' option, or explicitly if the '--nosync' option is used when extending the device. Here are the operational criteria: 1) A mirror created with '--nosync' should extend with 'nosync' implicitly [EXAMPLE]# lvs vg; lvextend -L +5G vg/lv ; lvs vg LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg Mwi-a-m- 5.00g lv_mlog 100.00 Extending 2 mirror images. Extending logical volume lv to 10.00 GiB Logical volume lv successfully resized LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg Mwi-a-m- 10.00g lv_mlog 100.00 2) The 'M' attribute ('M' signifies a mirror created with '--nosync', while 'm' signifies a mirror created w/o '--nosync') must be preserved when extending a mirror created with '--nosync'. See #1 for example of 'M' attribute. 3) A mirror created without '--nosync' should extend with 'nosync' only when '--nosync' is explicitly used when extending. [EXAMPLE]# lvs vg; lvextend -L +5G vg/lv; lvs vg LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg mwi-a-m- 20.00m lv_mlog 100.00 Extending 2 mirror images. Extending logical volume lv to 5.02 GiB Logical volume lv successfully resized LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg mwi-a-m- 5.02g lv_mlog 0.39 vs. [EXAMPLE]# lvs vg; lvextend -L +5G vg/lv --nosync; lvs vg LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg mwi-a-m- 20.00m lv_mlog 100.00 Extending 2 mirror images. Extending logical volume lv to 5.02 GiB Logical volume lv successfully resized LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg Mwi-a-m- 5.02g lv_mlog 100.00 4) The 'm' attribute must change to 'M' when extending a mirror created without '--nosync' is extended with the '--nosync' option. (See #3 examples above.) 5) An inactive mirror's sync percent cannot be determined definitively, so it must not be allowed to skip resync. Instead, the extend should ask the user if they want to extend while performing a resync. [EXAMPLE]# lvchange -an vg/lv [EXAMPLE]# lvextend -L +5G vg/lv Extending 2 mirror images. Extending logical volume lv to 10.00 GiB vg/lv is not active. Unable to get sync percent. Do full resync of extended portion of vg/lv? [y/n]: y Logical volume lv successfully resized 6) A mirror that is performing recovery (as opposed to an initial sync) - like after a failure - is not allowed to extend with either an implicit or explicit nosync option. [You can simulate this with a 'corelog' mirror because when it is reactivated, it must be recovered every time.] [EXAMPLE]# lvcreate -m1 -L 5G -n lv vg --nosync --corelog WARNING: New mirror won't be synchronised. Don't read what you didn't write! Logical volume "lv" created [EXAMPLE]# lvs vg LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg Mwi-a-m- 5.00g 100.00 [EXAMPLE]# lvchange -an vg/lv; lvchange -ay vg/lv; lvs vg LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg Mwi-a-m- 5.00g 0.08 [EXAMPLE]# lvextend -L +5G vg/lv Extending 2 mirror images. Extending logical volume lv to 10.00 GiB vg/lv cannot be extended while it is recovering. 7) If 'no' is selected in #5 or if the condition in #6 is hit, it should not result in the mirror being resized or the 'm/M' attribute being changed. NOTE: A mirror created with '--nosync' behaves differently than one created without it when performing an extension. The former cannot be extended when the mirror is recovering (unless in-active), while the latter can. This is a reasonable thing to do since recovery of a mirror doesn't take long (at least in the case of an on-disk log) and it would cause far more time in degraded mode if the extension w/o '--nosync' was allowed. It might be reasonable to add the ability to force the operation in the future. This should /not/ force a nosync extension, but rather force a sync'ed extension. IOW, the user would be saying, "Yes, yes... I know recovery won't take long and that I'll be adding significantly to the time spent in degraded mode, but I need the extra space right now!".
2011-10-06 19:32:26 +04:00
/*
* If we are expanding an existing mirror, we can skip the
* resync of the extension if the LV is currently in-sync
* and the LV has the LV_NOTSYNCED flag set.
*/
lvextend: Reinstate --nosync logic for mirrors. Reinstate the logic for syncing extensions of mirrors created with --nosync. (Inadvertently disabled by the approximate allocation changes.)
2014-08-28 03:40:09 +04:00
if (old_extents &&
Allow 'nosync' extension of mirrors. This patch allows a mirror to be extended without an initial resync of the extended portion. It compliments the existing '--nosync' option to lvcreate. This action can be done implicitly if the mirror was created with the '--nosync' option, or explicitly if the '--nosync' option is used when extending the device. Here are the operational criteria: 1) A mirror created with '--nosync' should extend with 'nosync' implicitly [EXAMPLE]# lvs vg; lvextend -L +5G vg/lv ; lvs vg LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg Mwi-a-m- 5.00g lv_mlog 100.00 Extending 2 mirror images. Extending logical volume lv to 10.00 GiB Logical volume lv successfully resized LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg Mwi-a-m- 10.00g lv_mlog 100.00 2) The 'M' attribute ('M' signifies a mirror created with '--nosync', while 'm' signifies a mirror created w/o '--nosync') must be preserved when extending a mirror created with '--nosync'. See #1 for example of 'M' attribute. 3) A mirror created without '--nosync' should extend with 'nosync' only when '--nosync' is explicitly used when extending. [EXAMPLE]# lvs vg; lvextend -L +5G vg/lv; lvs vg LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg mwi-a-m- 20.00m lv_mlog 100.00 Extending 2 mirror images. Extending logical volume lv to 5.02 GiB Logical volume lv successfully resized LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg mwi-a-m- 5.02g lv_mlog 0.39 vs. [EXAMPLE]# lvs vg; lvextend -L +5G vg/lv --nosync; lvs vg LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg mwi-a-m- 20.00m lv_mlog 100.00 Extending 2 mirror images. Extending logical volume lv to 5.02 GiB Logical volume lv successfully resized LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg Mwi-a-m- 5.02g lv_mlog 100.00 4) The 'm' attribute must change to 'M' when extending a mirror created without '--nosync' is extended with the '--nosync' option. (See #3 examples above.) 5) An inactive mirror's sync percent cannot be determined definitively, so it must not be allowed to skip resync. Instead, the extend should ask the user if they want to extend while performing a resync. [EXAMPLE]# lvchange -an vg/lv [EXAMPLE]# lvextend -L +5G vg/lv Extending 2 mirror images. Extending logical volume lv to 10.00 GiB vg/lv is not active. Unable to get sync percent. Do full resync of extended portion of vg/lv? [y/n]: y Logical volume lv successfully resized 6) A mirror that is performing recovery (as opposed to an initial sync) - like after a failure - is not allowed to extend with either an implicit or explicit nosync option. [You can simulate this with a 'corelog' mirror because when it is reactivated, it must be recovered every time.] [EXAMPLE]# lvcreate -m1 -L 5G -n lv vg --nosync --corelog WARNING: New mirror won't be synchronised. Don't read what you didn't write! Logical volume "lv" created [EXAMPLE]# lvs vg LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg Mwi-a-m- 5.00g 100.00 [EXAMPLE]# lvchange -an vg/lv; lvchange -ay vg/lv; lvs vg LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg Mwi-a-m- 5.00g 0.08 [EXAMPLE]# lvextend -L +5G vg/lv Extending 2 mirror images. Extending logical volume lv to 10.00 GiB vg/lv cannot be extended while it is recovering. 7) If 'no' is selected in #5 or if the condition in #6 is hit, it should not result in the mirror being resized or the 'm/M' attribute being changed. NOTE: A mirror created with '--nosync' behaves differently than one created without it when performing an extension. The former cannot be extended when the mirror is recovering (unless in-active), while the latter can. This is a reasonable thing to do since recovery of a mirror doesn't take long (at least in the case of an on-disk log) and it would cause far more time in degraded mode if the extension w/o '--nosync' was allowed. It might be reasonable to add the ability to force the operation in the future. This should /not/ force a nosync extension, but rather force a sync'ed extension. IOW, the user would be saying, "Yes, yes... I know recovery won't take long and that I'll be adding significantly to the time spent in degraded mode, but I need the extra space right now!".
2011-10-06 19:32:26 +04:00
segtype_is_mirrored(segtype) &&
macros: Add lv_is_not_synced.
2016-07-14 16:21:01 +03:00
(lv_is_not_synced(lv))) {
report: select: refactor: move percent handling code to libdm for reuse
2014-06-09 14:08:27 +04:00
dm_percent_t sync_percent = DM_PERCENT_INVALID;
Allow 'nosync' extension of mirrors. This patch allows a mirror to be extended without an initial resync of the extended portion. It compliments the existing '--nosync' option to lvcreate. This action can be done implicitly if the mirror was created with the '--nosync' option, or explicitly if the '--nosync' option is used when extending the device. Here are the operational criteria: 1) A mirror created with '--nosync' should extend with 'nosync' implicitly [EXAMPLE]# lvs vg; lvextend -L +5G vg/lv ; lvs vg LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg Mwi-a-m- 5.00g lv_mlog 100.00 Extending 2 mirror images. Extending logical volume lv to 10.00 GiB Logical volume lv successfully resized LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg Mwi-a-m- 10.00g lv_mlog 100.00 2) The 'M' attribute ('M' signifies a mirror created with '--nosync', while 'm' signifies a mirror created w/o '--nosync') must be preserved when extending a mirror created with '--nosync'. See #1 for example of 'M' attribute. 3) A mirror created without '--nosync' should extend with 'nosync' only when '--nosync' is explicitly used when extending. [EXAMPLE]# lvs vg; lvextend -L +5G vg/lv; lvs vg LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg mwi-a-m- 20.00m lv_mlog 100.00 Extending 2 mirror images. Extending logical volume lv to 5.02 GiB Logical volume lv successfully resized LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg mwi-a-m- 5.02g lv_mlog 0.39 vs. [EXAMPLE]# lvs vg; lvextend -L +5G vg/lv --nosync; lvs vg LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg mwi-a-m- 20.00m lv_mlog 100.00 Extending 2 mirror images. Extending logical volume lv to 5.02 GiB Logical volume lv successfully resized LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg Mwi-a-m- 5.02g lv_mlog 100.00 4) The 'm' attribute must change to 'M' when extending a mirror created without '--nosync' is extended with the '--nosync' option. (See #3 examples above.) 5) An inactive mirror's sync percent cannot be determined definitively, so it must not be allowed to skip resync. Instead, the extend should ask the user if they want to extend while performing a resync. [EXAMPLE]# lvchange -an vg/lv [EXAMPLE]# lvextend -L +5G vg/lv Extending 2 mirror images. Extending logical volume lv to 10.00 GiB vg/lv is not active. Unable to get sync percent. Do full resync of extended portion of vg/lv? [y/n]: y Logical volume lv successfully resized 6) A mirror that is performing recovery (as opposed to an initial sync) - like after a failure - is not allowed to extend with either an implicit or explicit nosync option. [You can simulate this with a 'corelog' mirror because when it is reactivated, it must be recovered every time.] [EXAMPLE]# lvcreate -m1 -L 5G -n lv vg --nosync --corelog WARNING: New mirror won't be synchronised. Don't read what you didn't write! Logical volume "lv" created [EXAMPLE]# lvs vg LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg Mwi-a-m- 5.00g 100.00 [EXAMPLE]# lvchange -an vg/lv; lvchange -ay vg/lv; lvs vg LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg Mwi-a-m- 5.00g 0.08 [EXAMPLE]# lvextend -L +5G vg/lv Extending 2 mirror images. Extending logical volume lv to 10.00 GiB vg/lv cannot be extended while it is recovering. 7) If 'no' is selected in #5 or if the condition in #6 is hit, it should not result in the mirror being resized or the 'm/M' attribute being changed. NOTE: A mirror created with '--nosync' behaves differently than one created without it when performing an extension. The former cannot be extended when the mirror is recovering (unless in-active), while the latter can. This is a reasonable thing to do since recovery of a mirror doesn't take long (at least in the case of an on-disk log) and it would cause far more time in degraded mode if the extension w/o '--nosync' was allowed. It might be reasonable to add the ability to force the operation in the future. This should /not/ force a nosync extension, but rather force a sync'ed extension. IOW, the user would be saying, "Yes, yes... I know recovery won't take long and that I'll be adding significantly to the time spent in degraded mode, but I need the extra space right now!".
2011-10-06 19:32:26 +04:00
Remove unused clvm variations for active LVs Different flavors of activate_lv() and lv_is_active() which are meaningful in a clustered VG can be eliminated and replaced with whatever that flavor already falls back to in a local VG. e.g. lv_is_active_exclusive_locally() is distinct from lv_is_active() in a clustered VG, but in a local VG they are equivalent. So, all instances of the variant are replaced with the basic local equivalent. For local VGs, the same behavior remains as before. For shared VGs, lvmlockd was written with the explicit requirement of local behavior from these functions (lvmlockd requires locking_type 1), so the behavior in shared VGs also remains the same.
2018-06-05 21:21:28 +03:00
if (!lv_is_active(lv)) {
cleanup: use display_lvname
2015-11-05 14:29:44 +03:00
log_error("Unable to read sync percent while LV %s "
"is not locally active.", display_lvname(lv));
buffering: use unbuffered silent mode for liblvm Disable private buffering when using liblvm. When private stdin/stdout buffering is not used always use silent mode.
2012-08-26 03:15:45 +04:00
/* FIXME Support --force */
Allow 'nosync' extension of mirrors. This patch allows a mirror to be extended without an initial resync of the extended portion. It compliments the existing '--nosync' option to lvcreate. This action can be done implicitly if the mirror was created with the '--nosync' option, or explicitly if the '--nosync' option is used when extending the device. Here are the operational criteria: 1) A mirror created with '--nosync' should extend with 'nosync' implicitly [EXAMPLE]# lvs vg; lvextend -L +5G vg/lv ; lvs vg LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg Mwi-a-m- 5.00g lv_mlog 100.00 Extending 2 mirror images. Extending logical volume lv to 10.00 GiB Logical volume lv successfully resized LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg Mwi-a-m- 10.00g lv_mlog 100.00 2) The 'M' attribute ('M' signifies a mirror created with '--nosync', while 'm' signifies a mirror created w/o '--nosync') must be preserved when extending a mirror created with '--nosync'. See #1 for example of 'M' attribute. 3) A mirror created without '--nosync' should extend with 'nosync' only when '--nosync' is explicitly used when extending. [EXAMPLE]# lvs vg; lvextend -L +5G vg/lv; lvs vg LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg mwi-a-m- 20.00m lv_mlog 100.00 Extending 2 mirror images. Extending logical volume lv to 5.02 GiB Logical volume lv successfully resized LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg mwi-a-m- 5.02g lv_mlog 0.39 vs. [EXAMPLE]# lvs vg; lvextend -L +5G vg/lv --nosync; lvs vg LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg mwi-a-m- 20.00m lv_mlog 100.00 Extending 2 mirror images. Extending logical volume lv to 5.02 GiB Logical volume lv successfully resized LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg Mwi-a-m- 5.02g lv_mlog 100.00 4) The 'm' attribute must change to 'M' when extending a mirror created without '--nosync' is extended with the '--nosync' option. (See #3 examples above.) 5) An inactive mirror's sync percent cannot be determined definitively, so it must not be allowed to skip resync. Instead, the extend should ask the user if they want to extend while performing a resync. [EXAMPLE]# lvchange -an vg/lv [EXAMPLE]# lvextend -L +5G vg/lv Extending 2 mirror images. Extending logical volume lv to 10.00 GiB vg/lv is not active. Unable to get sync percent. Do full resync of extended portion of vg/lv? [y/n]: y Logical volume lv successfully resized 6) A mirror that is performing recovery (as opposed to an initial sync) - like after a failure - is not allowed to extend with either an implicit or explicit nosync option. [You can simulate this with a 'corelog' mirror because when it is reactivated, it must be recovered every time.] [EXAMPLE]# lvcreate -m1 -L 5G -n lv vg --nosync --corelog WARNING: New mirror won't be synchronised. Don't read what you didn't write! Logical volume "lv" created [EXAMPLE]# lvs vg LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg Mwi-a-m- 5.00g 100.00 [EXAMPLE]# lvchange -an vg/lv; lvchange -ay vg/lv; lvs vg LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg Mwi-a-m- 5.00g 0.08 [EXAMPLE]# lvextend -L +5G vg/lv Extending 2 mirror images. Extending logical volume lv to 10.00 GiB vg/lv cannot be extended while it is recovering. 7) If 'no' is selected in #5 or if the condition in #6 is hit, it should not result in the mirror being resized or the 'm/M' attribute being changed. NOTE: A mirror created with '--nosync' behaves differently than one created without it when performing an extension. The former cannot be extended when the mirror is recovering (unless in-active), while the latter can. This is a reasonable thing to do since recovery of a mirror doesn't take long (at least in the case of an on-disk log) and it would cause far more time in degraded mode if the extension w/o '--nosync' was allowed. It might be reasonable to add the ability to force the operation in the future. This should /not/ force a nosync extension, but rather force a sync'ed extension. IOW, the user would be saying, "Yes, yes... I know recovery won't take long and that I'll be adding significantly to the time spent in degraded mode, but I need the extra space right now!".
2011-10-06 19:32:26 +04:00
if (yes_no_prompt("Do full resync of extended "
cleanup: use display_lvname
2015-11-05 14:29:44 +03:00
"portion of %s? [y/n]: ",
display_lvname(lv)) == 'n') {
debug: backtrace error path Add backtrace for 'n' answer.
2014-05-18 22:07:24 +04:00
r = 0;
goto_out;
}
Allow 'nosync' extension of mirrors. This patch allows a mirror to be extended without an initial resync of the extended portion. It compliments the existing '--nosync' option to lvcreate. This action can be done implicitly if the mirror was created with the '--nosync' option, or explicitly if the '--nosync' option is used when extending the device. Here are the operational criteria: 1) A mirror created with '--nosync' should extend with 'nosync' implicitly [EXAMPLE]# lvs vg; lvextend -L +5G vg/lv ; lvs vg LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg Mwi-a-m- 5.00g lv_mlog 100.00 Extending 2 mirror images. Extending logical volume lv to 10.00 GiB Logical volume lv successfully resized LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg Mwi-a-m- 10.00g lv_mlog 100.00 2) The 'M' attribute ('M' signifies a mirror created with '--nosync', while 'm' signifies a mirror created w/o '--nosync') must be preserved when extending a mirror created with '--nosync'. See #1 for example of 'M' attribute. 3) A mirror created without '--nosync' should extend with 'nosync' only when '--nosync' is explicitly used when extending. [EXAMPLE]# lvs vg; lvextend -L +5G vg/lv; lvs vg LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg mwi-a-m- 20.00m lv_mlog 100.00 Extending 2 mirror images. Extending logical volume lv to 5.02 GiB Logical volume lv successfully resized LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg mwi-a-m- 5.02g lv_mlog 0.39 vs. [EXAMPLE]# lvs vg; lvextend -L +5G vg/lv --nosync; lvs vg LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg mwi-a-m- 20.00m lv_mlog 100.00 Extending 2 mirror images. Extending logical volume lv to 5.02 GiB Logical volume lv successfully resized LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg Mwi-a-m- 5.02g lv_mlog 100.00 4) The 'm' attribute must change to 'M' when extending a mirror created without '--nosync' is extended with the '--nosync' option. (See #3 examples above.) 5) An inactive mirror's sync percent cannot be determined definitively, so it must not be allowed to skip resync. Instead, the extend should ask the user if they want to extend while performing a resync. [EXAMPLE]# lvchange -an vg/lv [EXAMPLE]# lvextend -L +5G vg/lv Extending 2 mirror images. Extending logical volume lv to 10.00 GiB vg/lv is not active. Unable to get sync percent. Do full resync of extended portion of vg/lv? [y/n]: y Logical volume lv successfully resized 6) A mirror that is performing recovery (as opposed to an initial sync) - like after a failure - is not allowed to extend with either an implicit or explicit nosync option. [You can simulate this with a 'corelog' mirror because when it is reactivated, it must be recovered every time.] [EXAMPLE]# lvcreate -m1 -L 5G -n lv vg --nosync --corelog WARNING: New mirror won't be synchronised. Don't read what you didn't write! Logical volume "lv" created [EXAMPLE]# lvs vg LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg Mwi-a-m- 5.00g 100.00 [EXAMPLE]# lvchange -an vg/lv; lvchange -ay vg/lv; lvs vg LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg Mwi-a-m- 5.00g 0.08 [EXAMPLE]# lvextend -L +5G vg/lv Extending 2 mirror images. Extending logical volume lv to 10.00 GiB vg/lv cannot be extended while it is recovering. 7) If 'no' is selected in #5 or if the condition in #6 is hit, it should not result in the mirror being resized or the 'm/M' attribute being changed. NOTE: A mirror created with '--nosync' behaves differently than one created without it when performing an extension. The former cannot be extended when the mirror is recovering (unless in-active), while the latter can. This is a reasonable thing to do since recovery of a mirror doesn't take long (at least in the case of an on-disk log) and it would cause far more time in degraded mode if the extension w/o '--nosync' was allowed. It might be reasonable to add the ability to force the operation in the future. This should /not/ force a nosync extension, but rather force a sync'ed extension. IOW, the user would be saying, "Yes, yes... I know recovery won't take long and that I'll be adding significantly to the time spent in degraded mode, but I need the extra space right now!".
2011-10-06 19:32:26 +04:00
goto out;
}
Improve lv_extend stack reporting and some code cleanup with setting return value.
2011-10-29 00:23:24 +04:00
if (!(r = lv_mirror_percent(lv->vg->cmd, lv, 0,
&sync_percent, NULL))) {
cleanup: use display_lvname
2015-11-05 14:29:44 +03:00
log_error("Failed to get sync percent for %s.",
display_lvname(lv));
Allow 'nosync' extension of mirrors. This patch allows a mirror to be extended without an initial resync of the extended portion. It compliments the existing '--nosync' option to lvcreate. This action can be done implicitly if the mirror was created with the '--nosync' option, or explicitly if the '--nosync' option is used when extending the device. Here are the operational criteria: 1) A mirror created with '--nosync' should extend with 'nosync' implicitly [EXAMPLE]# lvs vg; lvextend -L +5G vg/lv ; lvs vg LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg Mwi-a-m- 5.00g lv_mlog 100.00 Extending 2 mirror images. Extending logical volume lv to 10.00 GiB Logical volume lv successfully resized LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg Mwi-a-m- 10.00g lv_mlog 100.00 2) The 'M' attribute ('M' signifies a mirror created with '--nosync', while 'm' signifies a mirror created w/o '--nosync') must be preserved when extending a mirror created with '--nosync'. See #1 for example of 'M' attribute. 3) A mirror created without '--nosync' should extend with 'nosync' only when '--nosync' is explicitly used when extending. [EXAMPLE]# lvs vg; lvextend -L +5G vg/lv; lvs vg LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg mwi-a-m- 20.00m lv_mlog 100.00 Extending 2 mirror images. Extending logical volume lv to 5.02 GiB Logical volume lv successfully resized LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg mwi-a-m- 5.02g lv_mlog 0.39 vs. [EXAMPLE]# lvs vg; lvextend -L +5G vg/lv --nosync; lvs vg LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg mwi-a-m- 20.00m lv_mlog 100.00 Extending 2 mirror images. Extending logical volume lv to 5.02 GiB Logical volume lv successfully resized LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg Mwi-a-m- 5.02g lv_mlog 100.00 4) The 'm' attribute must change to 'M' when extending a mirror created without '--nosync' is extended with the '--nosync' option. (See #3 examples above.) 5) An inactive mirror's sync percent cannot be determined definitively, so it must not be allowed to skip resync. Instead, the extend should ask the user if they want to extend while performing a resync. [EXAMPLE]# lvchange -an vg/lv [EXAMPLE]# lvextend -L +5G vg/lv Extending 2 mirror images. Extending logical volume lv to 10.00 GiB vg/lv is not active. Unable to get sync percent. Do full resync of extended portion of vg/lv? [y/n]: y Logical volume lv successfully resized 6) A mirror that is performing recovery (as opposed to an initial sync) - like after a failure - is not allowed to extend with either an implicit or explicit nosync option. [You can simulate this with a 'corelog' mirror because when it is reactivated, it must be recovered every time.] [EXAMPLE]# lvcreate -m1 -L 5G -n lv vg --nosync --corelog WARNING: New mirror won't be synchronised. Don't read what you didn't write! Logical volume "lv" created [EXAMPLE]# lvs vg LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg Mwi-a-m- 5.00g 100.00 [EXAMPLE]# lvchange -an vg/lv; lvchange -ay vg/lv; lvs vg LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg Mwi-a-m- 5.00g 0.08 [EXAMPLE]# lvextend -L +5G vg/lv Extending 2 mirror images. Extending logical volume lv to 10.00 GiB vg/lv cannot be extended while it is recovering. 7) If 'no' is selected in #5 or if the condition in #6 is hit, it should not result in the mirror being resized or the 'm/M' attribute being changed. NOTE: A mirror created with '--nosync' behaves differently than one created without it when performing an extension. The former cannot be extended when the mirror is recovering (unless in-active), while the latter can. This is a reasonable thing to do since recovery of a mirror doesn't take long (at least in the case of an on-disk log) and it would cause far more time in degraded mode if the extension w/o '--nosync' was allowed. It might be reasonable to add the ability to force the operation in the future. This should /not/ force a nosync extension, but rather force a sync'ed extension. IOW, the user would be saying, "Yes, yes... I know recovery won't take long and that I'll be adding significantly to the time spent in degraded mode, but I need the extra space right now!".
2011-10-06 19:32:26 +04:00
goto out;
lv_manip: allow extension on --nosync raid lv If the recovery of the repleced leg(s) of a RaidLV created without initial resynchronization (i.e. "lvcreate --nosync ...") got interrupted, it can't be extended because of the < 100% sync rate.
2017-12-01 20:38:18 +03:00
} else if (lv_is_not_synced(lv) ||
sync_percent == DM_PERCENT_100) {
Allow 'nosync' extension of mirrors. This patch allows a mirror to be extended without an initial resync of the extended portion. It compliments the existing '--nosync' option to lvcreate. This action can be done implicitly if the mirror was created with the '--nosync' option, or explicitly if the '--nosync' option is used when extending the device. Here are the operational criteria: 1) A mirror created with '--nosync' should extend with 'nosync' implicitly [EXAMPLE]# lvs vg; lvextend -L +5G vg/lv ; lvs vg LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg Mwi-a-m- 5.00g lv_mlog 100.00 Extending 2 mirror images. Extending logical volume lv to 10.00 GiB Logical volume lv successfully resized LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg Mwi-a-m- 10.00g lv_mlog 100.00 2) The 'M' attribute ('M' signifies a mirror created with '--nosync', while 'm' signifies a mirror created w/o '--nosync') must be preserved when extending a mirror created with '--nosync'. See #1 for example of 'M' attribute. 3) A mirror created without '--nosync' should extend with 'nosync' only when '--nosync' is explicitly used when extending. [EXAMPLE]# lvs vg; lvextend -L +5G vg/lv; lvs vg LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg mwi-a-m- 20.00m lv_mlog 100.00 Extending 2 mirror images. Extending logical volume lv to 5.02 GiB Logical volume lv successfully resized LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg mwi-a-m- 5.02g lv_mlog 0.39 vs. [EXAMPLE]# lvs vg; lvextend -L +5G vg/lv --nosync; lvs vg LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg mwi-a-m- 20.00m lv_mlog 100.00 Extending 2 mirror images. Extending logical volume lv to 5.02 GiB Logical volume lv successfully resized LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg Mwi-a-m- 5.02g lv_mlog 100.00 4) The 'm' attribute must change to 'M' when extending a mirror created without '--nosync' is extended with the '--nosync' option. (See #3 examples above.) 5) An inactive mirror's sync percent cannot be determined definitively, so it must not be allowed to skip resync. Instead, the extend should ask the user if they want to extend while performing a resync. [EXAMPLE]# lvchange -an vg/lv [EXAMPLE]# lvextend -L +5G vg/lv Extending 2 mirror images. Extending logical volume lv to 10.00 GiB vg/lv is not active. Unable to get sync percent. Do full resync of extended portion of vg/lv? [y/n]: y Logical volume lv successfully resized 6) A mirror that is performing recovery (as opposed to an initial sync) - like after a failure - is not allowed to extend with either an implicit or explicit nosync option. [You can simulate this with a 'corelog' mirror because when it is reactivated, it must be recovered every time.] [EXAMPLE]# lvcreate -m1 -L 5G -n lv vg --nosync --corelog WARNING: New mirror won't be synchronised. Don't read what you didn't write! Logical volume "lv" created [EXAMPLE]# lvs vg LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg Mwi-a-m- 5.00g 100.00 [EXAMPLE]# lvchange -an vg/lv; lvchange -ay vg/lv; lvs vg LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg Mwi-a-m- 5.00g 0.08 [EXAMPLE]# lvextend -L +5G vg/lv Extending 2 mirror images. Extending logical volume lv to 10.00 GiB vg/lv cannot be extended while it is recovering. 7) If 'no' is selected in #5 or if the condition in #6 is hit, it should not result in the mirror being resized or the 'm/M' attribute being changed. NOTE: A mirror created with '--nosync' behaves differently than one created without it when performing an extension. The former cannot be extended when the mirror is recovering (unless in-active), while the latter can. This is a reasonable thing to do since recovery of a mirror doesn't take long (at least in the case of an on-disk log) and it would cause far more time in degraded mode if the extension w/o '--nosync' was allowed. It might be reasonable to add the ability to force the operation in the future. This should /not/ force a nosync extension, but rather force a sync'ed extension. IOW, the user would be saying, "Yes, yes... I know recovery won't take long and that I'll be adding significantly to the time spent in degraded mode, but I need the extra space right now!".
2011-10-06 19:32:26 +04:00
log_verbose("Skipping initial resync for "
cleanup: use display_lvname
2015-11-05 14:29:44 +03:00
"extended portion of %s",
display_lvname(lv));
Allow 'nosync' extension of mirrors. This patch allows a mirror to be extended without an initial resync of the extended portion. It compliments the existing '--nosync' option to lvcreate. This action can be done implicitly if the mirror was created with the '--nosync' option, or explicitly if the '--nosync' option is used when extending the device. Here are the operational criteria: 1) A mirror created with '--nosync' should extend with 'nosync' implicitly [EXAMPLE]# lvs vg; lvextend -L +5G vg/lv ; lvs vg LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg Mwi-a-m- 5.00g lv_mlog 100.00 Extending 2 mirror images. Extending logical volume lv to 10.00 GiB Logical volume lv successfully resized LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg Mwi-a-m- 10.00g lv_mlog 100.00 2) The 'M' attribute ('M' signifies a mirror created with '--nosync', while 'm' signifies a mirror created w/o '--nosync') must be preserved when extending a mirror created with '--nosync'. See #1 for example of 'M' attribute. 3) A mirror created without '--nosync' should extend with 'nosync' only when '--nosync' is explicitly used when extending. [EXAMPLE]# lvs vg; lvextend -L +5G vg/lv; lvs vg LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg mwi-a-m- 20.00m lv_mlog 100.00 Extending 2 mirror images. Extending logical volume lv to 5.02 GiB Logical volume lv successfully resized LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg mwi-a-m- 5.02g lv_mlog 0.39 vs. [EXAMPLE]# lvs vg; lvextend -L +5G vg/lv --nosync; lvs vg LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg mwi-a-m- 20.00m lv_mlog 100.00 Extending 2 mirror images. Extending logical volume lv to 5.02 GiB Logical volume lv successfully resized LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg Mwi-a-m- 5.02g lv_mlog 100.00 4) The 'm' attribute must change to 'M' when extending a mirror created without '--nosync' is extended with the '--nosync' option. (See #3 examples above.) 5) An inactive mirror's sync percent cannot be determined definitively, so it must not be allowed to skip resync. Instead, the extend should ask the user if they want to extend while performing a resync. [EXAMPLE]# lvchange -an vg/lv [EXAMPLE]# lvextend -L +5G vg/lv Extending 2 mirror images. Extending logical volume lv to 10.00 GiB vg/lv is not active. Unable to get sync percent. Do full resync of extended portion of vg/lv? [y/n]: y Logical volume lv successfully resized 6) A mirror that is performing recovery (as opposed to an initial sync) - like after a failure - is not allowed to extend with either an implicit or explicit nosync option. [You can simulate this with a 'corelog' mirror because when it is reactivated, it must be recovered every time.] [EXAMPLE]# lvcreate -m1 -L 5G -n lv vg --nosync --corelog WARNING: New mirror won't be synchronised. Don't read what you didn't write! Logical volume "lv" created [EXAMPLE]# lvs vg LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg Mwi-a-m- 5.00g 100.00 [EXAMPLE]# lvchange -an vg/lv; lvchange -ay vg/lv; lvs vg LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg Mwi-a-m- 5.00g 0.08 [EXAMPLE]# lvextend -L +5G vg/lv Extending 2 mirror images. Extending logical volume lv to 10.00 GiB vg/lv cannot be extended while it is recovering. 7) If 'no' is selected in #5 or if the condition in #6 is hit, it should not result in the mirror being resized or the 'm/M' attribute being changed. NOTE: A mirror created with '--nosync' behaves differently than one created without it when performing an extension. The former cannot be extended when the mirror is recovering (unless in-active), while the latter can. This is a reasonable thing to do since recovery of a mirror doesn't take long (at least in the case of an on-disk log) and it would cause far more time in degraded mode if the extension w/o '--nosync' was allowed. It might be reasonable to add the ability to force the operation in the future. This should /not/ force a nosync extension, but rather force a sync'ed extension. IOW, the user would be saying, "Yes, yes... I know recovery won't take long and that I'll be adding significantly to the time spent in degraded mode, but I need the extra space right now!".
2011-10-06 19:32:26 +04:00
init_mirror_in_sync(1);
lv->status |= LV_NOTSYNCED;
} else {
cleanup: use display_lvname
2015-11-05 14:29:44 +03:00
log_error("LV %s cannot be extended while it "
"is recovering.", display_lvname(lv));
Stop processing lvextend if trying to extend a mirror that is being recovered. Missing correct return value in lv_extend fn.
2012-02-09 19:13:42 +04:00
r = 0;
Allow 'nosync' extension of mirrors. This patch allows a mirror to be extended without an initial resync of the extended portion. It compliments the existing '--nosync' option to lvcreate. This action can be done implicitly if the mirror was created with the '--nosync' option, or explicitly if the '--nosync' option is used when extending the device. Here are the operational criteria: 1) A mirror created with '--nosync' should extend with 'nosync' implicitly [EXAMPLE]# lvs vg; lvextend -L +5G vg/lv ; lvs vg LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg Mwi-a-m- 5.00g lv_mlog 100.00 Extending 2 mirror images. Extending logical volume lv to 10.00 GiB Logical volume lv successfully resized LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg Mwi-a-m- 10.00g lv_mlog 100.00 2) The 'M' attribute ('M' signifies a mirror created with '--nosync', while 'm' signifies a mirror created w/o '--nosync') must be preserved when extending a mirror created with '--nosync'. See #1 for example of 'M' attribute. 3) A mirror created without '--nosync' should extend with 'nosync' only when '--nosync' is explicitly used when extending. [EXAMPLE]# lvs vg; lvextend -L +5G vg/lv; lvs vg LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg mwi-a-m- 20.00m lv_mlog 100.00 Extending 2 mirror images. Extending logical volume lv to 5.02 GiB Logical volume lv successfully resized LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg mwi-a-m- 5.02g lv_mlog 0.39 vs. [EXAMPLE]# lvs vg; lvextend -L +5G vg/lv --nosync; lvs vg LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg mwi-a-m- 20.00m lv_mlog 100.00 Extending 2 mirror images. Extending logical volume lv to 5.02 GiB Logical volume lv successfully resized LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg Mwi-a-m- 5.02g lv_mlog 100.00 4) The 'm' attribute must change to 'M' when extending a mirror created without '--nosync' is extended with the '--nosync' option. (See #3 examples above.) 5) An inactive mirror's sync percent cannot be determined definitively, so it must not be allowed to skip resync. Instead, the extend should ask the user if they want to extend while performing a resync. [EXAMPLE]# lvchange -an vg/lv [EXAMPLE]# lvextend -L +5G vg/lv Extending 2 mirror images. Extending logical volume lv to 10.00 GiB vg/lv is not active. Unable to get sync percent. Do full resync of extended portion of vg/lv? [y/n]: y Logical volume lv successfully resized 6) A mirror that is performing recovery (as opposed to an initial sync) - like after a failure - is not allowed to extend with either an implicit or explicit nosync option. [You can simulate this with a 'corelog' mirror because when it is reactivated, it must be recovered every time.] [EXAMPLE]# lvcreate -m1 -L 5G -n lv vg --nosync --corelog WARNING: New mirror won't be synchronised. Don't read what you didn't write! Logical volume "lv" created [EXAMPLE]# lvs vg LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg Mwi-a-m- 5.00g 100.00 [EXAMPLE]# lvchange -an vg/lv; lvchange -ay vg/lv; lvs vg LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg Mwi-a-m- 5.00g 0.08 [EXAMPLE]# lvextend -L +5G vg/lv Extending 2 mirror images. Extending logical volume lv to 10.00 GiB vg/lv cannot be extended while it is recovering. 7) If 'no' is selected in #5 or if the condition in #6 is hit, it should not result in the mirror being resized or the 'm/M' attribute being changed. NOTE: A mirror created with '--nosync' behaves differently than one created without it when performing an extension. The former cannot be extended when the mirror is recovering (unless in-active), while the latter can. This is a reasonable thing to do since recovery of a mirror doesn't take long (at least in the case of an on-disk log) and it would cause far more time in degraded mode if the extension w/o '--nosync' was allowed. It might be reasonable to add the ability to force the operation in the future. This should /not/ force a nosync extension, but rather force a sync'ed extension. IOW, the user would be saying, "Yes, yes... I know recovery won't take long and that I'll be adding significantly to the time spent in degraded mode, but I need the extra space right now!".
2011-10-06 19:32:26 +04:00
goto out;
}
}
This patch adds the ability to extend 0 length layered LVs. This allows us to allocate all images of a mirror (or RAID array) at one time during create. The current mirror implementation still requires a separate allocation for the log, however.
2011-04-07 01:32:20 +04:00
}
Allow 'nosync' extension of mirrors. This patch allows a mirror to be extended without an initial resync of the extended portion. It compliments the existing '--nosync' option to lvcreate. This action can be done implicitly if the mirror was created with the '--nosync' option, or explicitly if the '--nosync' option is used when extending the device. Here are the operational criteria: 1) A mirror created with '--nosync' should extend with 'nosync' implicitly [EXAMPLE]# lvs vg; lvextend -L +5G vg/lv ; lvs vg LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg Mwi-a-m- 5.00g lv_mlog 100.00 Extending 2 mirror images. Extending logical volume lv to 10.00 GiB Logical volume lv successfully resized LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg Mwi-a-m- 10.00g lv_mlog 100.00 2) The 'M' attribute ('M' signifies a mirror created with '--nosync', while 'm' signifies a mirror created w/o '--nosync') must be preserved when extending a mirror created with '--nosync'. See #1 for example of 'M' attribute. 3) A mirror created without '--nosync' should extend with 'nosync' only when '--nosync' is explicitly used when extending. [EXAMPLE]# lvs vg; lvextend -L +5G vg/lv; lvs vg LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg mwi-a-m- 20.00m lv_mlog 100.00 Extending 2 mirror images. Extending logical volume lv to 5.02 GiB Logical volume lv successfully resized LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg mwi-a-m- 5.02g lv_mlog 0.39 vs. [EXAMPLE]# lvs vg; lvextend -L +5G vg/lv --nosync; lvs vg LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg mwi-a-m- 20.00m lv_mlog 100.00 Extending 2 mirror images. Extending logical volume lv to 5.02 GiB Logical volume lv successfully resized LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg Mwi-a-m- 5.02g lv_mlog 100.00 4) The 'm' attribute must change to 'M' when extending a mirror created without '--nosync' is extended with the '--nosync' option. (See #3 examples above.) 5) An inactive mirror's sync percent cannot be determined definitively, so it must not be allowed to skip resync. Instead, the extend should ask the user if they want to extend while performing a resync. [EXAMPLE]# lvchange -an vg/lv [EXAMPLE]# lvextend -L +5G vg/lv Extending 2 mirror images. Extending logical volume lv to 10.00 GiB vg/lv is not active. Unable to get sync percent. Do full resync of extended portion of vg/lv? [y/n]: y Logical volume lv successfully resized 6) A mirror that is performing recovery (as opposed to an initial sync) - like after a failure - is not allowed to extend with either an implicit or explicit nosync option. [You can simulate this with a 'corelog' mirror because when it is reactivated, it must be recovered every time.] [EXAMPLE]# lvcreate -m1 -L 5G -n lv vg --nosync --corelog WARNING: New mirror won't be synchronised. Don't read what you didn't write! Logical volume "lv" created [EXAMPLE]# lvs vg LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg Mwi-a-m- 5.00g 100.00 [EXAMPLE]# lvchange -an vg/lv; lvchange -ay vg/lv; lvs vg LV VG Attr LSize Pool Origin Snap% Move Log Copy% Convert lv vg Mwi-a-m- 5.00g 0.08 [EXAMPLE]# lvextend -L +5G vg/lv Extending 2 mirror images. Extending logical volume lv to 10.00 GiB vg/lv cannot be extended while it is recovering. 7) If 'no' is selected in #5 or if the condition in #6 is hit, it should not result in the mirror being resized or the 'm/M' attribute being changed. NOTE: A mirror created with '--nosync' behaves differently than one created without it when performing an extension. The former cannot be extended when the mirror is recovering (unless in-active), while the latter can. This is a reasonable thing to do since recovery of a mirror doesn't take long (at least in the case of an on-disk log) and it would cause far more time in degraded mode if the extension w/o '--nosync' was allowed. It might be reasonable to add the ability to force the operation in the future. This should /not/ force a nosync extension, but rather force a sync'ed extension. IOW, the user would be saying, "Yes, yes... I know recovery won't take long and that I'll be adding significantly to the time spent in degraded mode, but I need the extra space right now!".
2011-10-06 19:32:26 +04:00
out:
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
alloc_destroy(ah);
o Factor _allocate out for use by lv_extend
2001-11-06 14:31:29 +03:00
return r;
}
Add support for renaming mirrored LVs. Patch by Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
2007-08-07 00:35:48 +04:00
/*
* Minimal LV renaming function.
* Metadata transaction should be made by caller.
cleanup: update comment
2015-11-09 12:41:17 +03:00
* Assumes new_name is allocated from lv->vgmem pool.
Add support for renaming mirrored LVs. Patch by Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
2007-08-07 00:35:48 +04:00
*/
static int _rename_single_lv(struct logical_volume *lv, char *new_name)
{
struct volume_group *vg = lv->vg;
metadata: also look at historical LVs when checking LV name availability Live LVs and historical LVs are in one namespace and the name needs to be unique in whole VG.
2016-03-01 17:31:48 +03:00
int historical;
Add support for renaming mirrored LVs. Patch by Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
2007-08-07 00:35:48 +04:00
metadata: also look at historical LVs when checking LV name availability Live LVs and historical LVs are in one namespace and the name needs to be unique in whole VG.
2016-03-01 17:31:48 +03:00
if (lv_name_is_used_in_vg(vg, new_name, &historical)) {
log_error("%sLogical Volume \"%s\" already exists in "
"volume group \"%s\"", historical ? "historical " : "",
new_name, vg->name);
Some simple fixups for last checkin: * remove "_" from "return_0" * improve some naming and terminology * add 'const'
2007-08-07 20:57:09 +04:00
return 0;
Add support for renaming mirrored LVs. Patch by Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
2007-08-07 00:35:48 +04:00
}
cleanup: Use lv_is_ macros. Use lv_is_* macros throughout the code base, introducing lv_is_pvmove, lv_is_locked, lv_is_converting and lv_is_merging. lv_is_mirror_type no longer includes pvmove.
2014-09-16 00:33:53 +04:00
if (lv_is_locked(lv)) {
Add support for renaming mirrored LVs. Patch by Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
2007-08-07 00:35:48 +04:00
log_error("Cannot rename locked LV %s", lv->name);
Some simple fixups for last checkin: * remove "_" from "return_0" * improve some naming and terminology * add 'const'
2007-08-07 20:57:09 +04:00
return 0;
Add support for renaming mirrored LVs. Patch by Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
2007-08-07 00:35:48 +04:00
}
lv->name = new_name;
return 1;
}
/*
* Rename sub LV.
Some simple fixups for last checkin: * remove "_" from "return_0" * improve some naming and terminology * add 'const'
2007-08-07 20:57:09 +04:00
* 'lv_name_old' and 'lv_name_new' are old and new names of the main LV.
Add support for renaming mirrored LVs. Patch by Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
2007-08-07 00:35:48 +04:00
*/
lv_manip: drop cmd pointer from for_each_sub_lv Drop unused passed cmd pointer from function. TODO: We have two similar functions (though not identical) lv_manip.c: for_each_sub_lv() metadata.c: _lv_each_dependency() They seem to not always match - we should probably convert to use only a single function.
2014-03-27 13:35:07 +04:00
static int _rename_sub_lv(struct logical_volume *lv,
Some simple fixups for last checkin: * remove "_" from "return_0" * improve some naming and terminology * add 'const'
2007-08-07 20:57:09 +04:00
const char *lv_name_old, const char *lv_name_new)
Add support for renaming mirrored LVs. Patch by Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
2007-08-07 00:35:48 +04:00
{
Const fixing Fixing some const warnings - with API change in: int vg_extend(struct volume_group *vg, int pv_count, const char *const *pv_names, Change is needed - as lvm2api expects const behaviour here. So vg_extend() is doing local strdup for unescaping. skip_dev_dir return const char* from const char* vg_name. Rest of the patch is cleanup of related warnings. Also using dm_report_filed_string() API change to simplify casting in _string_disp and _lvname_disp.
2011-02-18 17:47:28 +03:00
const char *suffix;
char *new_name;
Some simple fixups for last checkin: * remove "_" from "return_0" * improve some naming and terminology * add 'const'
2007-08-07 20:57:09 +04:00
size_t len;
Add support for renaming mirrored LVs. Patch by Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
2007-08-07 00:35:48 +04:00
Remove extra checks for sub LV renaming. Patch by Jun'ichi Nomura <j-nomura@ce.jp.nec.com>.
2007-08-08 22:00:36 +04:00
/*
* A sub LV name starts with lv_name_old + '_'.
* The suffix follows lv_name_old and includes '_'.
*/
len = strlen(lv_name_old);
if (strncmp(lv->name, lv_name_old, len) || lv->name[len] != '_') {
log_error("Cannot rename \"%s\": name format not recognized "
"for internal LV \"%s\"",
lv_name_old, lv->name);
return 0;
}
suffix = lv->name + len;
Add support for renaming mirrored LVs. Patch by Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
2007-08-07 00:35:48 +04:00
pre-release review cleanups
2008-01-17 20:17:09 +03:00
/*
Add support for renaming mirrored LVs. Patch by Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
2007-08-07 00:35:48 +04:00
* Compose a new name for sub lv:
* e.g. new name is "lvol1_mlog"
Extend cling allocation policy to recognise PV tags (cling_by_tags). Add allocation/cling_tag_list to lvm.conf.
2010-11-09 15:34:40 +03:00
* if the sub LV is "lvol0_mlog" and
* a new name for main LV is "lvol1"
Add support for renaming mirrored LVs. Patch by Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
2007-08-07 00:35:48 +04:00
*/
Some simple fixups for last checkin: * remove "_" from "return_0" * improve some naming and terminology * add 'const'
2007-08-07 20:57:09 +04:00
len = strlen(lv_name_new) + strlen(suffix) + 1;
lv_rename: validate renamed sublv Use proper vgmem memory pool for allocation of LV name in the vg and check if new renamed LV is a valid name. TODO: validation should really use also VG name, othewise we are not able to tell "vgname-lvname" will be valid.
2014-03-27 13:35:51 +04:00
new_name = dm_pool_alloc(lv->vg->vgmem, len);
Add support for renaming mirrored LVs. Patch by Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
2007-08-07 00:35:48 +04:00
if (!new_name) {
log_error("Failed to allocate space for new name");
Some simple fixups for last checkin: * remove "_" from "return_0" * improve some naming and terminology * add 'const'
2007-08-07 20:57:09 +04:00
return 0;
Add support for renaming mirrored LVs. Patch by Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
2007-08-07 00:35:48 +04:00
}
Fix incorrect tests for dm_snprintf() failure As the memory is preallocated based on arg size in these cases, the error would be quite hard to trigger here anyway.
2011-04-09 23:05:23 +04:00
if (dm_snprintf(new_name, len, "%s%s", lv_name_new, suffix) < 0) {
Add support for renaming mirrored LVs. Patch by Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
2007-08-07 00:35:48 +04:00
log_error("Failed to create new name");
Some simple fixups for last checkin: * remove "_" from "return_0" * improve some naming and terminology * add 'const'
2007-08-07 20:57:09 +04:00
return 0;
Add support for renaming mirrored LVs. Patch by Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
2007-08-07 00:35:48 +04:00
}
fix spurios char Mistyped char left in code.
2014-03-27 16:49:24 +04:00
if (!validate_name(new_name)) {
lv_rename: validate renamed sublv Use proper vgmem memory pool for allocation of LV name in the vg and check if new renamed LV is a valid name. TODO: validation should really use also VG name, othewise we are not able to tell "vgname-lvname" will be valid.
2014-03-27 13:35:51 +04:00
log_error("Cannot rename \"%s\". New logical volume name \"%s\" is invalid.",
lv->name, new_name);
return 0;
}
Add support for renaming mirrored LVs. Patch by Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
2007-08-07 00:35:48 +04:00
/* Rename it */
return _rename_single_lv(lv, new_name);
}
When suspending, automatically preload newly-visible existing LVs Let's find out if this makes things better or worse overall...
2011-06-30 22:25:18 +04:00
/* Callback for for_each_sub_lv */
lv_manip: drop cmd pointer from for_each_sub_lv Drop unused passed cmd pointer from function. TODO: We have two similar functions (though not identical) lv_manip.c: for_each_sub_lv() metadata.c: _lv_each_dependency() They seem to not always match - we should probably convert to use only a single function.
2014-03-27 13:35:07 +04:00
static int _rename_cb(struct logical_volume *lv, void *data)
Add support for renaming mirrored LVs. Patch by Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
2007-08-07 00:35:48 +04:00
{
A few more cleanups for lvrename of mirrors checkin: * add struct lv_names for old/new names * replace lv->status & MIRROR checks with lv_is_visible()
2007-08-07 22:55:38 +04:00
struct lv_names *lv_names = (struct lv_names *) data;
Add support for renaming mirrored LVs. Patch by Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
2007-08-07 00:35:48 +04:00
lv_manip: drop cmd pointer from for_each_sub_lv Drop unused passed cmd pointer from function. TODO: We have two similar functions (though not identical) lv_manip.c: for_each_sub_lv() metadata.c: _lv_each_dependency() They seem to not always match - we should probably convert to use only a single function.
2014-03-27 13:35:07 +04:00
return _rename_sub_lv(lv, lv_names->old, lv_names->new);
Add support for renaming mirrored LVs. Patch by Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
2007-08-07 00:35:48 +04:00
}
lv_manip: enhance for_each_sub_lv Fix missing 'externalLV' traversing for thins with external origins. Replace extra for_each_sub_lv_except_pools() with better internal logic allowing selectively to cut of processed subLV tree. Extend error code for function 'fn()' when it returns -1 it will stop futher tree scan for given LV. Also a bit simplify code to have only one place that is calling 'fn()' and use level counter to know depth of traversing. Update renaming travering to skip trees for pools and external origins.
2018-02-28 19:00:33 +03:00
static int _rename_skip_pools_externals_cb(struct logical_volume *lv, void *data)
{
vdo: introduce segment types and manip functions Core functionality introducing lvm VDO support.
2018-06-29 12:11:14 +03:00
if (lv_is_pool(lv) ||
lv_is_vdo_pool(lv) ||
Use "cachevol" to refer to cache on a single LV and "cachepool" to refer to a cache on a cache pool object. The problem was that the --cachepool option was being used to refer to both a cache pool object, and to a standard LV used for caching. This could be somewhat confusing, and it made it less clear when each kind would be used. By separating them, it's clear when a cachepool or a cachevol should be used. Previously: - lvm would use the cache pool approach when the user passed a cache-pool LV to the --cachepool option. - lvm would use the cache vol approach when the user passed a standard LV in the --cachepool option. Now: - lvm will always use the cache pool approach when the user uses the --cachepool option. - lvm will always use the cache vol approach when the user uses the --cachevol option.
2019-01-30 18:55:34 +03:00
lv_is_cache_vol(lv) ||
vdo: introduce segment types and manip functions Core functionality introducing lvm VDO support.
2018-06-29 12:11:14 +03:00
lv_is_external_origin(lv))
lv_manip: enhance for_each_sub_lv Fix missing 'externalLV' traversing for thins with external origins. Replace extra for_each_sub_lv_except_pools() with better internal logic allowing selectively to cut of processed subLV tree. Extend error code for function 'fn()' when it returns -1 it will stop futher tree scan for given LV. Also a bit simplify code to have only one place that is calling 'fn()' and use level counter to know depth of traversing. Update renaming travering to skip trees for pools and external origins.
2018-02-28 19:00:33 +03:00
return -1; /* and skip subLVs */
return _rename_cb(lv, data);
}
Add support for renaming mirrored LVs. Patch by Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
2007-08-07 00:35:48 +04:00
/*
When suspending, automatically preload newly-visible existing LVs Let's find out if this makes things better or worse overall...
2011-06-30 22:25:18 +04:00
* Loop down sub LVs and call fn for each.
* fn is responsible to log necessary information on failure.
lv_manip: enhance for_each_sub_lv Fix missing 'externalLV' traversing for thins with external origins. Replace extra for_each_sub_lv_except_pools() with better internal logic allowing selectively to cut of processed subLV tree. Extend error code for function 'fn()' when it returns -1 it will stop futher tree scan for given LV. Also a bit simplify code to have only one place that is calling 'fn()' and use level counter to know depth of traversing. Update renaming travering to skip trees for pools and external origins.
2018-02-28 19:00:33 +03:00
* Return value '0' stops whole traversal.
* Return value '-1' stops subtree traversal.
Add support for renaming mirrored LVs. Patch by Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
2007-08-07 00:35:48 +04:00
*/
lv_manip: enhance for_each_sub_lv Fix missing 'externalLV' traversing for thins with external origins. Replace extra for_each_sub_lv_except_pools() with better internal logic allowing selectively to cut of processed subLV tree. Extend error code for function 'fn()' when it returns -1 it will stop futher tree scan for given LV. Also a bit simplify code to have only one place that is calling 'fn()' and use level counter to know depth of traversing. Update renaming travering to skip trees for pools and external origins.
2018-02-28 19:00:33 +03:00
static int _for_each_sub_lv(struct logical_volume *lv, int level,
lv_manip: add for_each_sub_lv_except_pools() for_each_sub_lv() now scans in depth also pools, however for rename we actually do want to skip pools. So add a new for_each_sub_lv_except_pools() to be used by rename, every other user of for_each_sub_lv() scans every sub LV with pools included. This is i.e. necessary for properly working preload of pools that are using raid arrays.
2015-01-30 14:27:49 +03:00
int (*fn)(struct logical_volume *lv, void *data),
void *data)
Add support for renaming mirrored LVs. Patch by Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
2007-08-07 00:35:48 +04:00
{
Rename internal vorigin LV to match visible LV.
2009-05-28 04:29:14 +04:00
struct logical_volume *org;
Add support for renaming mirrored LVs. Patch by Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
2007-08-07 00:35:48 +04:00
struct lv_segment *seg;
Clean up numerous compiler warnings that crept in recently. Remove several unused parameters from _allocate().
2007-08-22 18:38:18 +04:00
uint32_t s;
lv_manip: enhance for_each_sub_lv Fix missing 'externalLV' traversing for thins with external origins. Replace extra for_each_sub_lv_except_pools() with better internal logic allowing selectively to cut of processed subLV tree. Extend error code for function 'fn()' when it returns -1 it will stop futher tree scan for given LV. Also a bit simplify code to have only one place that is calling 'fn()' and use level counter to know depth of traversing. Update renaming travering to skip trees for pools and external origins.
2018-02-28 19:00:33 +03:00
int r;
Add support for renaming mirrored LVs. Patch by Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
2007-08-07 00:35:48 +04:00
lv_manip: enhance for_each_sub_lv Fix missing 'externalLV' traversing for thins with external origins. Replace extra for_each_sub_lv_except_pools() with better internal logic allowing selectively to cut of processed subLV tree. Extend error code for function 'fn()' when it returns -1 it will stop futher tree scan for given LV. Also a bit simplify code to have only one place that is calling 'fn()' and use level counter to know depth of traversing. Update renaming travering to skip trees for pools and external origins.
2018-02-28 19:00:33 +03:00
if (!lv)
return 1;
if (level++) {
if (!(r = fn(lv, data)))
Rename internal vorigin LV to match visible LV.
2009-05-28 04:29:14 +04:00
return_0;
lv_manip: enhance for_each_sub_lv Fix missing 'externalLV' traversing for thins with external origins. Replace extra for_each_sub_lv_except_pools() with better internal logic allowing selectively to cut of processed subLV tree. Extend error code for function 'fn()' when it returns -1 it will stop futher tree scan for given LV. Also a bit simplify code to have only one place that is calling 'fn()' and use level counter to know depth of traversing. Update renaming travering to skip trees for pools and external origins.
2018-02-28 19:00:33 +03:00
if (r == -1)
return 1;
debug: update comment
2018-03-02 17:06:36 +03:00
/* Only r != -1 continues with for_each_sub_lv()... */
lv_manip: enhance for_each_sub_lv Fix missing 'externalLV' traversing for thins with external origins. Replace extra for_each_sub_lv_except_pools() with better internal logic allowing selectively to cut of processed subLV tree. Extend error code for function 'fn()' when it returns -1 it will stop futher tree scan for given LV. Also a bit simplify code to have only one place that is calling 'fn()' and use level counter to know depth of traversing. Update renaming travering to skip trees for pools and external origins.
2018-02-28 19:00:33 +03:00
}
if (lv_is_cow(lv) && lv_is_virtual_origin(org = origin_from_cow(lv))) {
if (!_for_each_sub_lv(org, level, fn, data))
Add missing lvrename mirrored log recursion in for_each_sub_lv.
2011-11-04 05:31:23 +04:00
return_0;
}
Rename internal vorigin LV to match visible LV.
2009-05-28 04:29:14 +04:00
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
dm_list_iterate_items(seg, &lv->segments) {
lv_manip: enhance for_each_sub_lv Fix missing 'externalLV' traversing for thins with external origins. Replace extra for_each_sub_lv_except_pools() with better internal logic allowing selectively to cut of processed subLV tree. Extend error code for function 'fn()' when it returns -1 it will stop futher tree scan for given LV. Also a bit simplify code to have only one place that is calling 'fn()' and use level counter to know depth of traversing. Update renaming travering to skip trees for pools and external origins.
2018-02-28 19:00:33 +03:00
if (!_for_each_sub_lv(seg->external_lv, level, fn, data))
return_0;
Thin for_each_sub_lv Adapt to scan thin dependency LVs
2012-01-27 01:39:32 +04:00
lv_manip: enhance for_each_sub_lv Fix missing 'externalLV' traversing for thins with external origins. Replace extra for_each_sub_lv_except_pools() with better internal logic allowing selectively to cut of processed subLV tree. Extend error code for function 'fn()' when it returns -1 it will stop futher tree scan for given LV. Also a bit simplify code to have only one place that is calling 'fn()' and use level counter to know depth of traversing. Update renaming travering to skip trees for pools and external origins.
2018-02-28 19:00:33 +03:00
if (!_for_each_sub_lv(seg->log_lv, level, fn, data))
return_0;
Thin for_each_sub_lv Adapt to scan thin dependency LVs
2012-01-27 01:39:32 +04:00
lv_manip: enhance for_each_sub_lv Fix missing 'externalLV' traversing for thins with external origins. Replace extra for_each_sub_lv_except_pools() with better internal logic allowing selectively to cut of processed subLV tree. Extend error code for function 'fn()' when it returns -1 it will stop futher tree scan for given LV. Also a bit simplify code to have only one place that is calling 'fn()' and use level counter to know depth of traversing. Update renaming travering to skip trees for pools and external origins.
2018-02-28 19:00:33 +03:00
if (!_for_each_sub_lv(seg->metadata_lv, level, fn, data))
return_0;
if (!_for_each_sub_lv(seg->pool_lv, level, fn, data))
return_0;
lv_manip: add for_each_sub_lv_except_pools() for_each_sub_lv() now scans in depth also pools, however for rename we actually do want to skip pools. So add a new for_each_sub_lv_except_pools() to be used by rename, every other user of for_each_sub_lv() scans every sub LV with pools included. This is i.e. necessary for properly working preload of pools that are using raid arrays.
2015-01-30 14:27:49 +03:00
writecache: fix splitcache when origin is raid
2020-02-05 01:05:56 +03:00
if (!_for_each_sub_lv(seg->writecache, level, fn, data))
return_0;
Allow dm-integrity to be used for raid images dm-integrity stores checksums of the data written to an LV, and returns an error if data read from the LV does not match the previously saved checksum. When used on raid images, dm-raid will correct the error by reading the block from another image, and the device user sees no error. The integrity metadata (checksums) are stored on an internal LV allocated by lvm for each linear image. The internal LV is allocated on the same PV as the image. Create a raid LV with an integrity layer over each raid image (for raid levels 1,4,5,6,10): lvcreate --type raidN --raidintegrity y [options] Add an integrity layer to images of an existing raid LV: lvconvert --raidintegrity y LV Remove the integrity layer from images of a raid LV: lvconvert --raidintegrity n LV Settings Use --raidintegritymode journal|bitmap (journal is default) to configure the method used by dm-integrity to ensure crash consistency. Initialization When integrity is added to an LV, the kernel needs to initialize the integrity metadata/checksums for all blocks in the LV. The data corruption checking performed by dm-integrity will only operate on areas of the LV that are already initialized. The progress of integrity initialization is reported by the "syncpercent" LV reporting field (and under the Cpy%Sync lvs column.) Example: create a raid1 LV with integrity: $ lvcreate --type raid1 -m1 --raidintegrity y -n rr -L1G foo Creating integrity metadata LV rr_rimage_0_imeta with size 12.00 MiB. Logical volume "rr_rimage_0_imeta" created. Creating integrity metadata LV rr_rimage_1_imeta with size 12.00 MiB. Logical volume "rr_rimage_1_imeta" created. Logical volume "rr" created. $ lvs -a foo LV VG Attr LSize Origin Cpy%Sync rr foo rwi-a-r--- 1.00g 4.93 [rr_rimage_0] foo gwi-aor--- 1.00g [rr_rimage_0_iorig] 41.02 [rr_rimage_0_imeta] foo ewi-ao---- 12.00m [rr_rimage_0_iorig] foo -wi-ao---- 1.00g [rr_rimage_1] foo gwi-aor--- 1.00g [rr_rimage_1_iorig] 39.45 [rr_rimage_1_imeta] foo ewi-ao---- 12.00m [rr_rimage_1_iorig] foo -wi-ao---- 1.00g [rr_rmeta_0] foo ewi-aor--- 4.00m [rr_rmeta_1] foo ewi-aor--- 4.00m
2019-11-21 01:07:27 +03:00
if (!_for_each_sub_lv(seg->integrity_meta_dev, level, fn, data))
return_0;
stacked mirror support (incomplete)
2007-12-20 21:55:46 +03:00
for (s = 0; s < seg->area_count; s++) {
if (seg_type(seg, s) != AREA_LV)
continue;
lv_manip: enhance for_each_sub_lv Fix missing 'externalLV' traversing for thins with external origins. Replace extra for_each_sub_lv_except_pools() with better internal logic allowing selectively to cut of processed subLV tree. Extend error code for function 'fn()' when it returns -1 it will stop futher tree scan for given LV. Also a bit simplify code to have only one place that is calling 'fn()' and use level counter to know depth of traversing. Update renaming travering to skip trees for pools and external origins.
2018-02-28 19:00:33 +03:00
if (!_for_each_sub_lv(seg_lv(seg, s), level, fn, data))
Rename internal vorigin LV to match visible LV.
2009-05-28 04:29:14 +04:00
return_0;
stacked mirror support (incomplete)
2007-12-20 21:55:46 +03:00
}
Fix renaming of RAID logical volumes. The function 'for_each_sub_lv', which rename uses, was not handling the RAID metadata areas. Thus, the metadata LVs were not being renamed.
2011-08-11 07:29:51 +04:00
raid0: Standardise meta_areas checks before access.
2016-05-24 00:55:13 +03:00
if (!seg_is_raid_with_meta(seg))
Fix renaming of RAID logical volumes. The function 'for_each_sub_lv', which rename uses, was not handling the RAID metadata areas. Thus, the metadata LVs were not being renamed.
2011-08-11 07:29:51 +04:00
continue;
/* RAID has meta_areas */
for (s = 0; s < seg->area_count; s++) {
raid0: Standardise meta_areas checks before access.
2016-05-24 00:55:13 +03:00
if ((seg_metatype(seg, s) != AREA_LV) || !seg_metalv(seg, s))
Fix renaming of RAID logical volumes. The function 'for_each_sub_lv', which rename uses, was not handling the RAID metadata areas. Thus, the metadata LVs were not being renamed.
2011-08-11 07:29:51 +04:00
continue;
lv_manip: enhance for_each_sub_lv Fix missing 'externalLV' traversing for thins with external origins. Replace extra for_each_sub_lv_except_pools() with better internal logic allowing selectively to cut of processed subLV tree. Extend error code for function 'fn()' when it returns -1 it will stop futher tree scan for given LV. Also a bit simplify code to have only one place that is calling 'fn()' and use level counter to know depth of traversing. Update renaming travering to skip trees for pools and external origins.
2018-02-28 19:00:33 +03:00
if (!_for_each_sub_lv(seg_metalv(seg, s), level, fn, data))
Fix renaming of RAID logical volumes. The function 'for_each_sub_lv', which rename uses, was not handling the RAID metadata areas. Thus, the metadata LVs were not being renamed.
2011-08-11 07:29:51 +04:00
return_0;
}
Add support for renaming mirrored LVs. Patch by Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
2007-08-07 00:35:48 +04:00
}
return 1;
}
lv_manip: add for_each_sub_lv_except_pools() for_each_sub_lv() now scans in depth also pools, however for rename we actually do want to skip pools. So add a new for_each_sub_lv_except_pools() to be used by rename, every other user of for_each_sub_lv() scans every sub LV with pools included. This is i.e. necessary for properly working preload of pools that are using raid arrays.
2015-01-30 14:27:49 +03:00
int for_each_sub_lv(struct logical_volume *lv,
int (*fn)(struct logical_volume *lv, void *data),
void *data)
{
return _for_each_sub_lv(lv, 0, fn, data);
}
Factor out core of lvrename to lv_rename library function. Patch by Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
2007-08-04 01:22:10 +04:00
/*
* Core of LV renaming routine.
* VG must be locked by caller.
*/
liblvm: add lv_rename_update Support lv_rename without directly updating metatata. It can save some metadata commits in some cases, i.e. when LVs are offline.
2012-09-27 11:48:25 +04:00
int lv_rename_update(struct cmd_context *cmd, struct logical_volume *lv,
const char *new_name, int update_mda)
Factor out core of lvrename to lv_rename library function. Patch by Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
2007-08-04 01:22:10 +04:00
{
struct volume_group *vg = lv->vg;
lv_rename: fix snapshot rename Fix rename operation for snapshot (cow) LV. Only the snapshot's origin has the lock and by mistake suspend and resume has been called for the snapshot LV. This further made volumes unusable in cluster. So instead of suspend and resuming list of LVs, we need to just suspend and resume origin. As the sequence write/suspend/commit/resume is widely used in lvm2 code base - move it to new lv_update_and_reload function.
2014-09-09 20:47:27 +04:00
struct lv_names lv_names = { .old = lv->name };
lvrename: support renaming historical logical volumes
2016-03-04 13:36:24 +03:00
int old_lv_is_historical = lv_is_historical(lv);
metadata: also look at historical LVs when checking LV name availability Live LVs and historical LVs are in one namespace and the name needs to be unique in whole VG.
2016-03-01 17:31:48 +03:00
int historical;
vdo: support online rename New VDO targets v6.2.3 corrects support for online rename of VDO device. If needed if can be disable via new lvm.conf setting: vdo_disabled_features = [ "online_rename" ]
2021-01-21 23:18:05 +03:00
unsigned attrs;
const struct segment_type *segtype;
Add support for renaming mirrored LVs. Patch by Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
2007-08-07 00:35:48 +04:00
lvrename: always allow to rename pools Since we mark cache-pool as 'hidden/private' while it is in-use, we may still allow user to change it's name. It should not cause any harm and user may prefer better naming for a cache-pool in use.
2015-12-09 15:52:47 +03:00
/*
* rename is not allowed on sub LVs except for pools
* (thin pool is 'visible', but cache may not)
*/
if (!lv_is_pool(lv) &&
vdo: introduce segment types and manip functions Core functionality introducing lvm VDO support.
2018-06-29 12:11:14 +03:00
!lv_is_vdo_pool(lv) &&
lvrename: always allow to rename pools Since we mark cache-pool as 'hidden/private' while it is in-use, we may still allow user to change it's name. It should not cause any harm and user may prefer better naming for a cache-pool in use.
2015-12-09 15:52:47 +03:00
!lv_is_visible(lv)) {
Some simple fixups for last checkin: * remove "_" from "return_0" * improve some naming and terminology * add 'const'
2007-08-07 20:57:09 +04:00
log_error("Cannot rename internal LV \"%s\".", lv->name);
Add support for renaming mirrored LVs. Patch by Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
2007-08-07 00:35:48 +04:00
return 0;
}
Factor out core of lvrename to lv_rename library function. Patch by Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
2007-08-04 01:22:10 +04:00
metadata: also look at historical LVs when checking LV name availability Live LVs and historical LVs are in one namespace and the name needs to be unique in whole VG.
2016-03-01 17:31:48 +03:00
if (lv_name_is_used_in_vg(vg, new_name, &historical)) {
log_error("%sLogical Volume \"%s\" already exists in "
lvrename: support renaming historical logical volumes
2016-03-04 13:36:24 +03:00
"volume group \"%s\"", historical ? "Historical " : "",
metadata: also look at historical LVs when checking LV name availability Live LVs and historical LVs are in one namespace and the name needs to be unique in whole VG.
2016-03-01 17:31:48 +03:00
new_name, vg->name);
Factor out core of lvrename to lv_rename library function. Patch by Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
2007-08-04 01:22:10 +04:00
return 0;
}
cleanup: Use lv_is_ macros. Use lv_is_* macros throughout the code base, introducing lv_is_pvmove, lv_is_locked, lv_is_converting and lv_is_merging. lv_is_mirror_type no longer includes pvmove.
2014-09-16 00:33:53 +04:00
if (lv_is_locked(lv)) {
Factor out core of lvrename to lv_rename library function. Patch by Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
2007-08-04 01:22:10 +04:00
log_error("Cannot rename locked LV %s", lv->name);
return 0;
}
vdo: disable support for online rename of vdopool LV Since ATM kernel does not support this operation, disable 'lvrename' of an active vdopool. As a workaround, user may simply deactivate, rename and activate.
2020-09-23 14:18:23 +03:00
if (lv_is_vdo_pool(lv) && lv_is_active(lv_lock_holder(lv))) {
vdo: support online rename New VDO targets v6.2.3 corrects support for online rename of VDO device. If needed if can be disable via new lvm.conf setting: vdo_disabled_features = [ "online_rename" ]
2021-01-21 23:18:05 +03:00
segtype = first_seg(lv)->segtype;
if (!segtype->ops->target_present ||
!segtype->ops->target_present(lv->vg->cmd, NULL, &attrs) ||
!(attrs & VDO_FEATURE_ONLINE_RENAME)) {
log_error("Cannot rename active VDOPOOL volume %s, "
"VDO target feature support is missing.",
display_lvname(lv));
return 0;
}
vdo: disable support for online rename of vdopool LV Since ATM kernel does not support this operation, disable 'lvrename' of an active vdopool. As a workaround, user may simply deactivate, rename and activate.
2020-09-23 14:18:23 +03:00
}
lvrename: support renaming historical logical volumes
2016-03-04 13:36:24 +03:00
if (old_lv_is_historical) {
cleanup: comment in the code for renaming historical LVs
2016-03-04 13:46:29 +03:00
/*
* Historical LVs have neither sub LVs nor any
* devices to reload, so just update metadata.
*/
lvrename: support renaming historical logical volumes
2016-03-04 13:36:24 +03:00
lv->this_glv->historical->name = lv->name = new_name;
if (update_mda &&
(!vg_write(vg) || !vg_commit(vg)))
return_0;
} else {
if (!(lv_names.new = dm_pool_strdup(cmd->mem, new_name))) {
log_error("Failed to allocate space for new name.");
return 0;
}
lv_rename: actual fix for snapshot By my rebasing mistake it's been eliminated from previous patch set.
2014-09-09 22:15:51 +04:00
lvrename: support renaming historical logical volumes
2016-03-04 13:36:24 +03:00
/* rename sub LVs */
lv_manip: enhance for_each_sub_lv Fix missing 'externalLV' traversing for thins with external origins. Replace extra for_each_sub_lv_except_pools() with better internal logic allowing selectively to cut of processed subLV tree. Extend error code for function 'fn()' when it returns -1 it will stop futher tree scan for given LV. Also a bit simplify code to have only one place that is calling 'fn()' and use level counter to know depth of traversing. Update renaming travering to skip trees for pools and external origins.
2018-02-28 19:00:33 +03:00
if (!for_each_sub_lv(lv, _rename_skip_pools_externals_cb, (void *) &lv_names))
lvrename: support renaming historical logical volumes
2016-03-04 13:36:24 +03:00
return_0;
Add support for renaming mirrored LVs. Patch by Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
2007-08-07 00:35:48 +04:00
lvrename: support renaming historical logical volumes
2016-03-04 13:36:24 +03:00
/* rename main LV */
lv->name = lv_names.new;
Factor out core of lvrename to lv_rename library function. Patch by Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
2007-08-04 01:22:10 +04:00
lvrename: support renaming historical logical volumes
2016-03-04 13:36:24 +03:00
if (lv_is_cow(lv))
lv = origin_from_cow(lv);
lv_rename: actual fix for snapshot By my rebasing mistake it's been eliminated from previous patch set.
2014-09-09 22:15:51 +04:00
lvrename: support renaming historical logical volumes
2016-03-04 13:36:24 +03:00
if (update_mda && !lv_update_and_reload((struct logical_volume *)lv_lock_holder(lv)))
return_0;
}
Factor out core of lvrename to lv_rename library function. Patch by Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
2007-08-04 01:22:10 +04:00
lv_rename: fix snapshot rename Fix rename operation for snapshot (cow) LV. Only the snapshot's origin has the lock and by mistake suspend and resume has been called for the snapshot LV. This further made volumes unusable in cluster. So instead of suspend and resuming list of LVs, we need to just suspend and resume origin. As the sequence write/suspend/commit/resume is widely used in lvm2 code base - move it to new lv_update_and_reload function.
2014-09-09 20:47:27 +04:00
return 1;
Factor out core of lvrename to lv_rename library function. Patch by Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
2007-08-04 01:22:10 +04:00
}
lv_manip: add lv_uniq_rename_update Add function to rename LV to either passed name or if the name is already in use, generate new lvol% name.
2019-10-21 10:16:45 +03:00
/*
* Rename LV to new name, if name is occupies, lvol% is generated.
* VG must be locked by caller.
*/
int lv_uniq_rename_update(struct cmd_context *cmd, struct logical_volume *lv,
const char *new_name, int update_mda)
{
char uniq_name[NAME_LEN];
/* If the name is in use, generate new lvol%d */
if (lv_name_is_used_in_vg(lv->vg, new_name, NULL)) {
if (!generate_lv_name(lv->vg, "lvol%d", uniq_name, sizeof(uniq_name))) {
log_error("Failed to generate unique name for unused logical volume.");
return 0;
}
new_name = uniq_name;
}
if (!lv_rename_update(cmd, lv, new_name, 0))
return_0;
return 1;
}
liblvm: add lv_rename_update Support lv_rename without directly updating metatata. It can save some metadata commits in some cases, i.e. when LVs are offline.
2012-09-27 11:48:25 +04:00
/*
* Core of LV renaming routine.
* VG must be locked by caller.
*/
int lv_rename(struct cmd_context *cmd, struct logical_volume *lv,
const char *new_name)
{
return lv_rename_update(cmd, lv, new_name, 1);
}
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
/*
* Core lv resize code
*/
#define SIZE_BUF 128
lvresize: fix stripe size validation While stripe size is twice the physical extent size, the original code will not reduce stripe size to maximum (physical extent size). Signed-off-by: Zhiqing Zhang <zhangzq.fnst@cn.fujitsu.com>
2014-02-26 06:14:18 +04:00
/* TODO: unify stripe size validation across source code */
cleanup: drop extra cmd passed arg Use vg->cmd when needed cmd struct.
2016-01-19 01:24:32 +03:00
static int _validate_stripesize(const struct volume_group *vg,
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
struct lvresize_params *lp)
{
lvresize: update lvresize_params struct Reorganise struct lvresize_params to better fit lvresize needs to be able to resize more then just a single LV.
2016-06-17 14:25:41 +03:00
if (lp->stripe_size > (STRIPE_SIZE_LIMIT * 2)) {
cleanup: use log_print Using log_print for ignoring message instead of log_warn. Add some missing '.'.
2016-01-15 12:35:10 +03:00
log_error("Stripe size cannot be larger than %s.",
cleanup: drop extra cmd passed arg Use vg->cmd when needed cmd struct.
2016-01-19 01:24:32 +03:00
display_size(vg->cmd, (uint64_t) STRIPE_SIZE_LIMIT));
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
return 0;
}
lvresize: update lvresize_params struct Reorganise struct lvresize_params to better fit lvresize needs to be able to resize more then just a single LV.
2016-06-17 14:25:41 +03:00
if (lp->stripe_size > vg->extent_size) {
lvresize: fix stripe size validation While stripe size is twice the physical extent size, the original code will not reduce stripe size to maximum (physical extent size). Signed-off-by: Zhiqing Zhang <zhangzq.fnst@cn.fujitsu.com>
2014-02-26 06:14:18 +04:00
log_print_unless_silent("Reducing stripe size %s to maximum, "
cleanup: use log_print Using log_print for ignoring message instead of log_warn. Add some missing '.'.
2016-01-15 12:35:10 +03:00
"physical extent size %s.",
lvresize: update lvresize_params struct Reorganise struct lvresize_params to better fit lvresize needs to be able to resize more then just a single LV.
2016-06-17 14:25:41 +03:00
display_size(vg->cmd, lp->stripe_size),
cleanup: drop extra cmd passed arg Use vg->cmd when needed cmd struct.
2016-01-19 01:24:32 +03:00
display_size(vg->cmd, vg->extent_size));
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
lp->stripe_size = vg->extent_size;
lvresize: update lvresize_params struct Reorganise struct lvresize_params to better fit lvresize needs to be able to resize more then just a single LV.
2016-06-17 14:25:41 +03:00
}
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
macros: Use is_power_of_2.
2016-06-30 19:59:44 +03:00
if (!is_power_of_2(lp->stripe_size)) {
cleanup: use log_print Using log_print for ignoring message instead of log_warn. Add some missing '.'.
2016-01-15 12:35:10 +03:00
log_error("Stripe size must be power of 2.");
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
return 0;
}
return 1;
}
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
static int _lv_reduce_confirmation(struct logical_volume *lv,
struct lvresize_params *lp)
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
{
lvresize: do not pass struct cmd Use common API design and pass just LV pointer to lv_manip.c functions. Read cmd struct via lv->vg->cmd when needed. Also do not try to return EINVALID_CMD_LINE error when we have already openned VG - this error code can only be returned before locking VG.
2016-06-14 16:32:21 +03:00
const struct volume_group *vg = lv->vg;
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
struct lvinfo info = { 0 };
cleanup: drop extra cmd passed arg Use vg->cmd when needed cmd struct.
2016-01-19 01:24:32 +03:00
if (!lv_info(vg->cmd, lv, 0, &info, 1, 0) && driver_version(NULL, 0)) {
cleanup: add dots to some messages Add missing dots and one comment.
2016-06-14 15:56:17 +03:00
log_error("lv_info failed: aborting.");
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
return 0;
}
if (!info.exists)
return 1;
cleanup: update messages
2016-02-08 15:08:54 +03:00
log_warn("WARNING: Reducing active%s logical volume to %s.",
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
info.open_count ? " and open" : "",
cleanup: drop extra cmd passed arg Use vg->cmd when needed cmd struct.
2016-01-19 01:24:32 +03:00
display_size(vg->cmd, (uint64_t) lp->extents * vg->extent_size));
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
log_warn("THIS MAY DESTROY YOUR DATA (filesystem etc.)");
lvreduce: support --yes Missed support for --yes with 'lvreduce' to answer 'y' to prompt.
2021-04-06 13:26:42 +03:00
if (!lp->force && !lp->yes) {
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
if (yes_no_prompt("Do you really want to reduce %s? [y/n]: ",
cleanup: update messages
2016-02-08 15:08:54 +03:00
display_lvname(lv)) == 'n') {
cleanup: add dots to some messages Add missing dots and one comment.
2016-06-14 15:56:17 +03:00
log_error("Logical volume %s NOT reduced.",
cleanup: update messages
2016-02-08 15:08:54 +03:00
display_lvname(lv));
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
return 0;
}
}
return 1;
}
enum fsadm_cmd_e { FSADM_CMD_CHECK, FSADM_CMD_RESIZE };
fsadm: support configurable full path Just like with other tools lvm2 is using allow to define fully configurable path. Default is selected by $PREFIX/sbin/fsadm
2017-04-08 20:43:20 +03:00
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
#define FSADM_CMD_MAX_ARGS 6
#define FSADM_CHECK_FAILS_FOR_MOUNTED 3 /* shell exist status code */
/*
fsadm: support configurable full path Just like with other tools lvm2 is using allow to define fully configurable path. Default is selected by $PREFIX/sbin/fsadm
2017-04-08 20:43:20 +03:00
* fsadm --dry-run --verbose --force check lv_path
* fsadm --dry-run --verbose --force resize lv_path size
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
*/
lvresize: pass only needed params to _fsadm_cmd Do not pass whole lvresize_params into _fsadm_cmd, and give it only needed args.
2016-06-15 16:46:03 +03:00
static int _fsadm_cmd(enum fsadm_cmd_e fcmd,
struct logical_volume *lv,
uint32_t extents,
lvresize: support passing --yes to fsadm Since fsadm now needs --yes to pass prompting operations, we need to pass --yes from lvresize to fsadm.
2017-06-21 15:02:57 +03:00
int yes,
lvresize: pass only needed params to _fsadm_cmd Do not pass whole lvresize_params into _fsadm_cmd, and give it only needed args.
2016-06-15 16:46:03 +03:00
int force,
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
int *status)
{
lvresize: pass only needed params to _fsadm_cmd Do not pass whole lvresize_params into _fsadm_cmd, and give it only needed args.
2016-06-15 16:46:03 +03:00
struct volume_group *vg = lv->vg;
struct cmd_context *cmd = vg->cmd;
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
char lv_path[PATH_MAX];
char size_buf[SIZE_BUF];
lvresize: support passing --yes to fsadm Since fsadm now needs --yes to pass prompting operations, we need to pass --yes from lvresize to fsadm.
2017-06-21 15:02:57 +03:00
const char *argv[FSADM_CMD_MAX_ARGS + 4];
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
unsigned i = 0;
fsadm: support configurable full path Just like with other tools lvm2 is using allow to define fully configurable path. Default is selected by $PREFIX/sbin/fsadm
2017-04-08 20:43:20 +03:00
argv[i++] = find_config_tree_str(cmd, global_fsadm_executable_CFG, NULL);
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
if (test_mode())
argv[i++] = "--dry-run";
if (verbose_level() >= _LOG_NOTICE)
argv[i++] = "--verbose";
lvresize: support passing --yes to fsadm Since fsadm now needs --yes to pass prompting operations, we need to pass --yes from lvresize to fsadm.
2017-06-21 15:02:57 +03:00
if (yes)
argv[i++] = "--yes";
lvresize: pass only needed params to _fsadm_cmd Do not pass whole lvresize_params into _fsadm_cmd, and give it only needed args.
2016-06-15 16:46:03 +03:00
if (force)
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
argv[i++] = "--force";
argv[i++] = (fcmd == FSADM_CMD_RESIZE) ? "resize" : "check";
if (status)
*status = -1;
cleanup: ignore vg_name in /lib Since vg_name inside /lib function has already been ignored mostly except for a few debug prints - make it and official internal API feature. vg_name is used only in /tools while the VG is not yet openned, and when lvresize/lvcreate /lib function is called with VG pointer already being used, then vg_name becomes irrelevant (it's not been validated anyway). So any internal user of lvcreate_params and lvresize_params does not need to set vg_name pointer and may leave it NULL.
2014-06-30 14:02:05 +04:00
if (dm_snprintf(lv_path, sizeof(lv_path), "%s%s/%s", cmd->dev_dir,
lvresize: pass only needed params to _fsadm_cmd Do not pass whole lvresize_params into _fsadm_cmd, and give it only needed args.
2016-06-15 16:46:03 +03:00
vg->name, lv->name) < 0) {
log_error("Couldn't create LV path for %s.", display_lvname(lv));
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
return 0;
}
argv[i++] = lv_path;
if (fcmd == FSADM_CMD_RESIZE) {
macros: Wrap PRI with FMT. Create a set of wrappers with embedded % such as #define FMTu64 "%" PRIu64
2015-07-06 17:09:17 +03:00
if (dm_snprintf(size_buf, sizeof(size_buf), FMTu64 "K",
lvresize: pass only needed params to _fsadm_cmd Do not pass whole lvresize_params into _fsadm_cmd, and give it only needed args.
2016-06-15 16:46:03 +03:00
(uint64_t) extents * (vg->extent_size / 2)) < 0) {
log_error("Couldn't generate new LV size string.");
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
return 0;
}
argv[i++] = size_buf;
}
argv[i] = NULL;
return exec_cmd(cmd, argv, status, 1);
}
lvresize: support more resized LVs Add code to support more LVs to be resized through a same code path using a single lvresize_params struct. (Now it's used for thin-pool metadata resize, next user will be snapshot virtual resize). Update code to adjust percent amount resize for use_policies. Properly activate inactive thin-pool in case of any pool resize as the command should not 'deffer' this operation to next activation.
2016-06-23 00:32:35 +03:00
static uint32_t _adjust_amount(dm_percent_t percent, int policy_threshold, int policy_amount)
lv_manip: ensure it will fit bellow threshold Use single code to evaluate if the percentage value has crossed threshold. Recalculate amount value to always fit bellow threshold so there are not need any extra reiterations to reach this state in case policy amount is too small.
2015-10-25 21:19:39 +03:00
{
lvextend: improve percentage estimation Correcting rounding rules for percentage evaluation. Validate supported range of percentage. (although ranges are already validated earlier on code path)
2020-09-10 23:38:34 +03:00
if (!((50 * DM_PERCENT_1) < percent && percent <= DM_PERCENT_100) ||
lv_manip: ensure it will fit bellow threshold Use single code to evaluate if the percentage value has crossed threshold. Recalculate amount value to always fit bellow threshold so there are not need any extra reiterations to reach this state in case policy amount is too small.
2015-10-25 21:19:39 +03:00
percent <= (policy_threshold * DM_PERCENT_1))
cleanup: update messages
2016-02-08 15:08:54 +03:00
return 0; /* nothing to do */
lv_manip: ensure it will fit bellow threshold Use single code to evaluate if the percentage value has crossed threshold. Recalculate amount value to always fit bellow threshold so there are not need any extra reiterations to reach this state in case policy amount is too small.
2015-10-25 21:19:39 +03:00
/*
* Evaluate the minimal amount needed to get bellow threshold.
* Keep using DM_PERCENT_1 units for better precision.
* Round-up to needed percentage value
*/
lv_manip: even better rounding
2020-09-11 14:31:29 +03:00
policy_threshold *= (DM_PERCENT_1 / 100);
percent = (percent + policy_threshold - 1) / policy_threshold - 100;
lv_manip: ensure it will fit bellow threshold Use single code to evaluate if the percentage value has crossed threshold. Recalculate amount value to always fit bellow threshold so there are not need any extra reiterations to reach this state in case policy amount is too small.
2015-10-25 21:19:39 +03:00
/* Use it if current policy amount is smaller */
lvresize: fixes for recent commit Merging process and patch rework missed some bits - fix them.
2016-06-24 01:24:26 +03:00
return (policy_amount < percent) ? (uint32_t) percent : (uint32_t) policy_amount;
lv_manip: ensure it will fit bellow threshold Use single code to evaluate if the percentage value has crossed threshold. Recalculate amount value to always fit bellow threshold so there are not need any extra reiterations to reach this state in case policy amount is too small.
2015-10-25 21:19:39 +03:00
}
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
/* "amount" here is percent */
int lv_extend_policy_calculate_percent(struct logical_volume *lv,
uint32_t *amount, uint32_t *meta_amount)
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
{
cleanup: drop extra cmd passed arg Use vg->cmd when needed cmd struct.
2016-01-19 01:24:32 +03:00
struct cmd_context *cmd = lv->vg->cmd;
report: select: refactor: move percent handling code to libdm for reuse
2014-06-09 14:08:27 +04:00
dm_percent_t percent;
thin: enforce there is some free space in thin pool metadata Unconditionally guard there is at least 1/4 of metadata volume free (<16Mib) or 4MiB - whichever value is smaller. In case there is not enough free space do not let operation proceed and recommend thin-pool metadata resize (in case user has not enabled autoresize, manual 'lvextend --poolmetadatasize' is needed).
2016-09-16 22:50:14 +03:00
dm_percent_t min_threshold;
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
int policy_threshold, policy_amount;
thin: use lv_status_thin and lv_status_thin_pool Introduce structures lv_status_thin_pool and lv_status_thin (pair to lv_status_cache, lv_status_vdo) Convert lv_thin_percent() -> lv_thin_status() and lv_thin_pool_percent() + lv_thin_pool_transaction_id() -> lv_thin_pool_status(). This way a function user can see not only percentages, but also other important status info about thin-pool. TODO: This patch tries to not change too many other things, but pool_below_threshold() now uses new thin-pool info to return failure if thin-pool cannot be actually modified. This should be handle separately in a better way.
2020-09-27 02:11:47 +03:00
struct lv_status_thin_pool *thin_pool_status;
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
lvresize: support more resized LVs Add code to support more LVs to be resized through a same code path using a single lvresize_params struct. (Now it's used for thin-pool metadata resize, next user will be snapshot virtual resize). Update code to adjust percent amount resize for use_policies. Properly activate inactive thin-pool in case of any pool resize as the command should not 'deffer' this operation to next activation.
2016-06-23 00:32:35 +03:00
*amount = *meta_amount = 0;
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
if (lv_is_thin_pool(lv)) {
policy_threshold =
find_config_tree_int(cmd, activation_thin_pool_autoextend_threshold_CFG,
lib: better reporting of threshold Simplify code reporting warning about incorrect thresholds.
2015-10-22 11:46:39 +03:00
lv_config_profile(lv));
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
policy_amount =
find_config_tree_int(cmd, activation_thin_pool_autoextend_percent_CFG,
lv_config_profile(lv));
lib: better reporting of threshold Simplify code reporting warning about incorrect thresholds.
2015-10-22 11:46:39 +03:00
if (policy_threshold < 50) {
thin: Fix typo in policy threshold message.
2015-10-23 17:38:31 +03:00
log_warn("WARNING: Thin pool autoextend threshold %d%% is set below "
"minimum supported 50%%.", policy_threshold);
lib: better reporting of threshold Simplify code reporting warning about incorrect thresholds.
2015-10-22 11:46:39 +03:00
policy_threshold = 50;
thin: show message on error path Add missing log_error and show proper reason for failure when autoextend is set to 0. Add missing log_error when checked LV is not locally active.
2015-09-14 13:58:21 +03:00
}
vdo: enable dmeventd resize
2019-01-20 18:08:11 +03:00
} else if (lv_is_vdo_pool(lv)) {
policy_threshold =
find_config_tree_int(cmd, activation_vdo_pool_autoextend_threshold_CFG,
lv_config_profile(lv));
policy_amount =
find_config_tree_int(cmd, activation_vdo_pool_autoextend_percent_CFG,
lv_config_profile(lv));
if (policy_threshold < 50) {
log_warn("WARNING: VDO pool autoextend threshold %d%% is set below "
"minimum supported 50%%.", policy_threshold);
policy_threshold = 50;
}
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
} else {
policy_threshold =
lib: better reporting of threshold Simplify code reporting warning about incorrect thresholds.
2015-10-22 11:46:39 +03:00
find_config_tree_int(cmd, activation_snapshot_autoextend_threshold_CFG, NULL);
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
policy_amount =
find_config_tree_int(cmd, activation_snapshot_autoextend_percent_CFG, NULL);
lib: better reporting of threshold Simplify code reporting warning about incorrect thresholds.
2015-10-22 11:46:39 +03:00
if (policy_threshold < 50) {
log_warn("WARNING: Snapshot autoextend threshold %d%% is set bellow "
"minimal supported value 50%%.", policy_threshold);
policy_threshold = 50;
}
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
}
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
if (policy_threshold >= 100) {
log_debug("lvextend policy disabled by threshold 100");
cleanup: shuffle check of threshold Check first threshold and then policy_amount.
2016-01-15 16:39:58 +03:00
return 1; /* nothing to do */
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
}
cleanup: shuffle check of threshold Check first threshold and then policy_amount.
2016-01-15 16:39:58 +03:00
if (!policy_amount) {
lib: better reporting of threshold Simplify code reporting warning about incorrect thresholds.
2015-10-22 11:46:39 +03:00
log_error("Can't extend %s with %s autoextend percent set to 0%%.",
cleanup: more use of lvseg_name Use existing function lvseg_name().
2016-12-25 02:29:30 +03:00
display_lvname(lv), lvseg_name(first_seg(lv)));
lib: better reporting of threshold Simplify code reporting warning about incorrect thresholds.
2015-10-22 11:46:39 +03:00
return 0;
}
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
if (lv_is_thin_pool(lv)) {
thin: use lv_status_thin and lv_status_thin_pool Introduce structures lv_status_thin_pool and lv_status_thin (pair to lv_status_cache, lv_status_vdo) Convert lv_thin_percent() -> lv_thin_status() and lv_thin_pool_percent() + lv_thin_pool_transaction_id() -> lv_thin_pool_status(). This way a function user can see not only percentages, but also other important status info about thin-pool. TODO: This patch tries to not change too many other things, but pool_below_threshold() now uses new thin-pool info to return failure if thin-pool cannot be actually modified. This should be handle separately in a better way.
2020-09-27 02:11:47 +03:00
if (!lv_thin_pool_status(lv, 0, &thin_pool_status))
resize: continue change for getting vdo status before resize Continue commit a98b77c16455ee97f5bd4b89536a3ae4efd8e009. There needs to be error reported when status can't be obtained.
2019-10-02 15:50:12 +03:00
goto_bad;
lvresize: support more resized LVs Add code to support more LVs to be resized through a same code path using a single lvresize_params struct. (Now it's used for thin-pool metadata resize, next user will be snapshot virtual resize). Update code to adjust percent amount resize for use_policies. Properly activate inactive thin-pool in case of any pool resize as the command should not 'deffer' this operation to next activation.
2016-06-23 00:32:35 +03:00
thin: enforce there is some free space in thin pool metadata Unconditionally guard there is at least 1/4 of metadata volume free (<16Mib) or 4MiB - whichever value is smaller. In case there is not enough free space do not let operation proceed and recommend thin-pool metadata resize (in case user has not enabled autoresize, manual 'lvextend --poolmetadatasize' is needed).
2016-09-16 22:50:14 +03:00
/* Resize below the minimal usable value */
thin: rename internal function Names matching internal code layout. Functionc in thin_manip.c uses thin_pool in its name. Keep 'pool' only for function working for both cache and thin pools. No change of functionality.
2022-08-24 16:02:07 +03:00
min_threshold = thin_pool_metadata_min_threshold(first_seg(lv)) / DM_PERCENT_1;
thin: use lv_status_thin and lv_status_thin_pool Introduce structures lv_status_thin_pool and lv_status_thin (pair to lv_status_cache, lv_status_vdo) Convert lv_thin_percent() -> lv_thin_status() and lv_thin_pool_percent() + lv_thin_pool_transaction_id() -> lv_thin_pool_status(). This way a function user can see not only percentages, but also other important status info about thin-pool. TODO: This patch tries to not change too many other things, but pool_below_threshold() now uses new thin-pool info to return failure if thin-pool cannot be actually modified. This should be handle separately in a better way.
2020-09-27 02:11:47 +03:00
*meta_amount = _adjust_amount(thin_pool_status->metadata_usage,
(min_threshold < policy_threshold) ?
thin: enforce there is some free space in thin pool metadata Unconditionally guard there is at least 1/4 of metadata volume free (<16Mib) or 4MiB - whichever value is smaller. In case there is not enough free space do not let operation proceed and recommend thin-pool metadata resize (in case user has not enabled autoresize, manual 'lvextend --poolmetadatasize' is needed).
2016-09-16 22:50:14 +03:00
min_threshold : policy_threshold, policy_amount);
thin: compensate metadata size by extra percent When using --use-policy for automatic extension of thin-pool, the extension of thin-pool's metadata itself can actually take some extra space. Since I'm not aware of exact compensation formula, add just 1% extra to calculated amount and hope it fits. Wanted target is to always have usable thin-pool that fits bellow pool_metadata_min_threshold().
2020-09-11 14:31:55 +03:00
if (*meta_amount)
/* Compensate possible extra space consumption by kernel on resize */
(*meta_amount)++;
thin: use lv_status_thin and lv_status_thin_pool Introduce structures lv_status_thin_pool and lv_status_thin (pair to lv_status_cache, lv_status_vdo) Convert lv_thin_percent() -> lv_thin_status() and lv_thin_pool_percent() + lv_thin_pool_transaction_id() -> lv_thin_pool_status(). This way a function user can see not only percentages, but also other important status info about thin-pool. TODO: This patch tries to not change too many other things, but pool_below_threshold() now uses new thin-pool info to return failure if thin-pool cannot be actually modified. This should be handle separately in a better way.
2020-09-27 02:11:47 +03:00
percent = thin_pool_status->data_usage;
dm_pool_destroy(thin_pool_status->mem);
vdo: enable dmeventd resize
2019-01-20 18:08:11 +03:00
} else if (lv_is_vdo_pool(lv)) {
if (!lv_vdo_pool_percent(lv, &percent))
resize: continue change for getting vdo status before resize Continue commit a98b77c16455ee97f5bd4b89536a3ae4efd8e009. There needs to be error reported when status can't be obtained.
2019-10-02 15:50:12 +03:00
goto_bad;
vdo: properly check percentage for resize Avoid checking 'lv_is_active()' since special LV types does this validation anyway what calling _percent() function and call it ONLY when none of special types is queried. This restores support for VDO resize (as with support for separate VDO pool activation, plain query for lv_is_active() is not working in this case).
2019-09-30 14:25:42 +03:00
} else if (!lv_snapshot_percent(lv, &percent))
resize: continue change for getting vdo status before resize Continue commit a98b77c16455ee97f5bd4b89536a3ae4efd8e009. There needs to be error reported when status can't be obtained.
2019-10-02 15:50:12 +03:00
goto_bad;
vdo: properly check percentage for resize Avoid checking 'lv_is_active()' since special LV types does this validation anyway what calling _percent() function and call it ONLY when none of special types is queried. This restores support for VDO resize (as with support for separate VDO pool activation, plain query for lv_is_active() is not working in this case).
2019-09-30 14:25:42 +03:00
else if (!lv_is_active(lv)) {
resize: continue change for getting vdo status before resize Continue commit a98b77c16455ee97f5bd4b89536a3ae4efd8e009. There needs to be error reported when status can't be obtained.
2019-10-02 15:50:12 +03:00
bad:
vdo: properly check percentage for resize Avoid checking 'lv_is_active()' since special LV types does this validation anyway what calling _percent() function and call it ONLY when none of special types is queried. This restores support for VDO resize (as with support for separate VDO pool activation, plain query for lv_is_active() is not working in this case).
2019-09-30 14:25:42 +03:00
log_error("Can't read state of locally inactive LV %s.",
display_lvname(lv));
return 0;
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
}
lvresize: support more resized LVs Add code to support more LVs to be resized through a same code path using a single lvresize_params struct. (Now it's used for thin-pool metadata resize, next user will be snapshot virtual resize). Update code to adjust percent amount resize for use_policies. Properly activate inactive thin-pool in case of any pool resize as the command should not 'deffer' this operation to next activation.
2016-06-23 00:32:35 +03:00
*amount = _adjust_amount(percent, policy_threshold, policy_amount);
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
log_debug("lvextend policy calculated percentages main %u meta %u from threshold %d percent %d",
*amount, *meta_amount, policy_threshold, policy_amount);
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
return 1;
}
tidy: Add missing underscores to statics.
2017-10-18 17:57:46 +03:00
static uint32_t _lvseg_get_stripes(struct lv_segment *seg, uint32_t *stripesize)
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
{
lvreduce: simplify _lvseg_get_stripes integrity check Simplify unnecessary loop to avoid coverity complaint.
2023-05-25 20:09:41 +03:00
uint32_t s;
lvreduce: make _lvseg_get_stripes handle integrity layer lvreduce uses _lvseg_get_stripes() which was unable to get raid stripe info with an integrity layer present. This caused lvreduce on a raid+integrity LV to fail prematurely when checking stripe parameters. An unhelpful error message about stripe size would be printed.
2023-05-03 00:12:23 +03:00
struct lv_segment *seg_get, *seg_image, *seg_iorig;
struct logical_volume *lv_image, *lv_iorig;
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
/* If segment mirrored, check if images are striped */
lvreduce: make _lvseg_get_stripes handle integrity layer lvreduce uses _lvseg_get_stripes() which was unable to get raid stripe info with an integrity layer present. This caused lvreduce on a raid+integrity LV to fail prematurely when checking stripe parameters. An unhelpful error message about stripe size would be printed.
2023-05-03 00:12:23 +03:00
if (seg_is_mirrored(seg)) {
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
for (s = 0; s < seg->area_count; s++) {
if (seg_type(seg, s) != AREA_LV)
continue;
lvreduce: make _lvseg_get_stripes handle integrity layer lvreduce uses _lvseg_get_stripes() which was unable to get raid stripe info with an integrity layer present. This caused lvreduce on a raid+integrity LV to fail prematurely when checking stripe parameters. An unhelpful error message about stripe size would be printed.
2023-05-03 00:12:23 +03:00
lv_image = seg_lv(seg, s);
seg_image = first_seg(lv_image);
seg_get = NULL;
if (seg_is_integrity(seg_image)) {
/* Get stripe values from the iorig layer. */
lvreduce: simplify _lvseg_get_stripes integrity check Simplify unnecessary loop to avoid coverity complaint.
2023-05-25 20:09:41 +03:00
lv_iorig = seg_lv(seg_image, 0);
seg_iorig = first_seg(lv_iorig);
seg_get = seg_iorig;
lvreduce: make _lvseg_get_stripes handle integrity layer lvreduce uses _lvseg_get_stripes() which was unable to get raid stripe info with an integrity layer present. This caused lvreduce on a raid+integrity LV to fail prematurely when checking stripe parameters. An unhelpful error message about stripe size would be printed.
2023-05-03 00:12:23 +03:00
} else {
/* Get stripe values from the image layer. */
seg_get = seg_image;
}
if (seg_get && seg_is_striped(seg_get)) {
seg = seg_get;
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
break;
}
}
lvreduce: make _lvseg_get_stripes handle integrity layer lvreduce uses _lvseg_get_stripes() which was unable to get raid stripe info with an integrity layer present. This caused lvreduce on a raid+integrity LV to fail prematurely when checking stripe parameters. An unhelpful error message about stripe size would be printed.
2023-05-03 00:12:23 +03:00
}
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
if (seg_is_striped(seg)) {
*stripesize = seg->stripe_size;
return seg->area_count;
}
lvreduce/lvresize: add ability to reduce the size of a RaidLV - support shrinking of raid0/1/4/5/6/10 LVs - enhance lvresize-raid.sh tests: add raid0* and raid10 - fix have_raid4 in aux.sh to allow lv_resize-raid.sh and other scripts to test raid4 Resolves: rhbz1394048
2017-02-10 00:41:28 +03:00
if (seg_is_raid(seg)) {
*stripesize = seg->stripe_size;
lvreduce: make _lvseg_get_stripes handle integrity layer lvreduce uses _lvseg_get_stripes() which was unable to get raid stripe info with an integrity layer present. This caused lvreduce on a raid+integrity LV to fail prematurely when checking stripe parameters. An unhelpful error message about stripe size would be printed.
2023-05-03 00:12:23 +03:00
return _raid_stripes_count(seg);
lvreduce/lvresize: add ability to reduce the size of a RaidLV - support shrinking of raid0/1/4/5/6/10 LVs - enhance lvresize-raid.sh tests: add raid0* and raid10 - fix have_raid4 in aux.sh to allow lv_resize-raid.sh and other scripts to test raid4 Resolves: rhbz1394048
2017-02-10 00:41:28 +03:00
}
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
*stripesize = 0;
return 0;
}
cleanup: adjust once
2016-01-19 13:44:11 +03:00
static int _lvresize_adjust_size(struct volume_group *vg,
uint64_t size, sign_t sign,
uint32_t *extents)
lvresize: separate validation from action Start separating the validation from the action in the basic lvresize code moved to the library. Remove incorrect use of command line error codes from lvresize library functions. Move errors.h to tools directory to reinforce this, exporting public versions of the error codes in lvm2cmd.h for dmeventd plugins to use.
2013-07-06 06:28:21 +04:00
{
cleanup: adjust once
2016-01-19 13:44:11 +03:00
uint32_t extent_size = vg->extent_size;
uint32_t adjust;
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
/*
* First adjust to an exact multiple of extent size.
cleanup: adjust once
2016-01-19 13:44:11 +03:00
* When changing to an absolute size, we round that size up.
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
* When extending by a relative amount we round that amount up.
* When reducing by a relative amount we remove at most that amount.
*/
cleanup: adjust once
2016-01-19 13:44:11 +03:00
if ((adjust = (size % extent_size))) {
if (sign != SIGN_MINUS) /* not reducing */
size += extent_size;
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
cleanup: adjust once
2016-01-19 13:44:11 +03:00
size -= adjust;
log_print_unless_silent("Rounding size to boundary between physical extents: %s.",
display_size(vg->cmd, size));
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
}
lvresize: use standard extent conversion function We need to validate whether the requested resizing size can be expressed with given extent_size.
2023-01-10 20:09:51 +03:00
if (!(*extents = extents_from_size(vg->cmd, size, extent_size)))
return_0;
cleanup: adjust once
2016-01-19 13:44:11 +03:00
lvresize: separate validation from action Start separating the validation from the action in the basic lvresize code moved to the library. Remove incorrect use of command line error codes from lvresize library functions. Move errors.h to tools directory to reinforce this, exporting public versions of the error codes in lvm2cmd.h for dmeventd plugins to use.
2013-07-06 06:28:21 +04:00
return 1;
}
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
/*
* If percent options were used, convert them into actual numbers of extents.
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
* FIXME: fix cases where lp->extents is initially used as a percentage,
* and is then rewritten to be a number of extents (simply save the percent
* value elsewhere.)
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
*/
lvresize: do not pass struct cmd Use common API design and pass just LV pointer to lv_manip.c functions. Read cmd struct via lv->vg->cmd when needed. Also do not try to return EINVALID_CMD_LINE error when we have already openned VG - this error code can only be returned before locking VG.
2016-06-14 16:32:21 +03:00
static int _lvresize_extents_from_percent(const struct logical_volume *lv,
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
struct lvresize_params *lp)
lvresize: separate validation from action Start separating the validation from the action in the basic lvresize code moved to the library. Remove incorrect use of command line error codes from lvresize library functions. Move errors.h to tools directory to reinforce this, exporting public versions of the error codes in lvm2cmd.h for dmeventd plugins to use.
2013-07-06 06:28:21 +04:00
{
lvresize: do not pass struct cmd Use common API design and pass just LV pointer to lv_manip.c functions. Read cmd struct via lv->vg->cmd when needed. Also do not try to return EINVALID_CMD_LINE error when we have already openned VG - this error code can only be returned before locking VG.
2016-06-14 16:32:21 +03:00
const struct volume_group *vg = lv->vg;
lvresize: separate validation from action Start separating the validation from the action in the basic lvresize code moved to the library. Remove incorrect use of command line error codes from lvresize library functions. Move errors.h to tools directory to reinforce this, exporting public versions of the error codes in lvm2cmd.h for dmeventd plugins to use.
2013-07-06 06:28:21 +04:00
uint32_t pv_extent_count;
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
uint32_t old_extents = lp->extents;
lvresize: separate validation from action Start separating the validation from the action in the basic lvresize code moved to the library. Remove incorrect use of command line error codes from lvresize library functions. Move errors.h to tools directory to reinforce this, exporting public versions of the error codes in lvm2cmd.h for dmeventd plugins to use.
2013-07-06 06:28:21 +04:00
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
log_debug("lvresize_extents_from_percent type %d extents %u percent_value %u",
lp->percent, lp->extents, lp->percent_value);
lvresize: separate validation from action Start separating the validation from the action in the basic lvresize code moved to the library. Remove incorrect use of command line error codes from lvresize library functions. Move errors.h to tools directory to reinforce this, exporting public versions of the error codes in lvm2cmd.h for dmeventd plugins to use.
2013-07-06 06:28:21 +04:00
switch (lp->percent) {
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
case PERCENT_VG:
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
/* rewrites lp->extents from percentage to extents */
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
lp->extents = percent_of_extents(lp->extents, vg->extent_count,
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
(lp->sign != SIGN_MINUS));
lv_manip: better work with PERCENT_VG modifier with lvresize Fixing recent commit 022ebb0cfebee4ac8fdbe4e0c61e85db1038a115 Resize already has size that needs to be counted with, otherwise upsizing operation could turn into size reduction one.
2019-01-21 17:37:51 +03:00
if ((lp->sign == SIGN_NONE) && (lp->extents > (lv->le_count + vg->free_count))) {
lp->extents = lv->le_count + vg->free_count;
lv_manip: better work with PERCENT_VG modifier When using 'lvcreate -l100%VG' and there is big disproportion between real available space and requested setting - automatically fallback to 100%FREE. Difference can be seen when VG is big and already most space was allocated, so the requestion 100%VG can end (and by spec for % modifier it's correct) as LV with size of 1%VG. Usually this is not a big problem - buit in some cases - like cache-pool allocation, this can result a big difference for chunksize selection. With this patch it's more closely match common-sense logic without the need of reitteration of too big changes in lvm2 core ATM. TODO: in the future there should be allocator solving all allocations in a single call.
2019-01-19 00:27:02 +03:00
log_print_unless_silent("Reducing %u%%VG to remaining free space %s in VG.",
old_extents,
display_size(vg->cmd, (uint64_t)vg->extent_size * lp->extents));
}
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
break;
case PERCENT_FREE:
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
/* rewrites lp->extents from percentage to extents */
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
lp->extents = percent_of_extents(lp->extents, vg->free_count,
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
(lp->sign != SIGN_MINUS));
break;
case PERCENT_LV:
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
if (lp->extents) {
/* rewrites lp->extents from percentage to extents */
lp->extents = percent_of_extents(lp->extents, lv->le_count,
(lp->sign != SIGN_MINUS));
} else if (lp->percent_value) {
old_extents = lp->percent_value;
lp->extents = percent_of_extents(lp->percent_value, lv->le_count,
(lp->sign != SIGN_MINUS));
}
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
break;
case PERCENT_PVS:
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
if (lp->pvh != &vg->pvs) {
pv_extent_count = pv_list_extents_free(lp->pvh);
if (lp->extents) {
/* rewrites lp->extents from percentage to extents */
lp->extents = percent_of_extents(lp->extents, pv_extent_count,
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
(lp->sign != SIGN_MINUS));
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
} else if (lp->percent_value) {
/* lvresize has PVs args and no size of exents options */
old_extents = lp->percent_value;
lp->extents = percent_of_extents(lp->percent_value, pv_extent_count,
(lp->sign != SIGN_MINUS));
}
} else {
if (lp->extents) {
/* rewrites lp->extents from percentage to extents */
lp->extents = percent_of_extents(lp->extents, vg->extent_count,
(lp->sign != SIGN_MINUS));
} else if (lp->percent_value) {
old_extents = lp->percent_value;
lp->extents = percent_of_extents(lp->percent_value, vg->extent_count,
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
(lp->sign != SIGN_MINUS));
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
}
}
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
break;
case PERCENT_ORIGIN:
if (!lv_is_cow(lv)) {
log_error("Specified LV does not have an origin LV.");
lvresize: separate validation from action Start separating the validation from the action in the basic lvresize code moved to the library. Remove incorrect use of command line error codes from lvresize library functions. Move errors.h to tools directory to reinforce this, exporting public versions of the error codes in lvm2cmd.h for dmeventd plugins to use.
2013-07-06 06:28:21 +04:00
return 0;
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
}
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
lp->extents = percent_of_extents(lp->extents, origin_from_cow(lv)->le_count,
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
(lp->sign != SIGN_MINUS));
break;
case PERCENT_NONE:
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
return 1; /* Nothing to do */
allocation: add default path Make it obvious for compiler extents is always defined for valid code path.
2014-02-25 12:36:26 +04:00
default:
log_error(INTERNAL_ERROR "Unsupported percent type %u.", lp->percent);
return 0;
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
}
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
if (lp->percent == PERCENT_VG || lp->percent == PERCENT_FREE || lp->percent == PERCENT_PVS)
lp->extents_are_pes = 1;
allocation: improve approx alloc with resize Start to convert percentage size handling in lvresize to the new standard. Note in the man pages that this code is incomplete. Fix a regression in non-percentage allocation in my last check in. This is what I am aiming for: -l<extents> -l<percent> LV/ORIGIN sets or changes the LV size based on the specified quantity of logical logical extents (that might be backed by a higher number of physical extents) -l<percent> PVS/VG/FREE sets or changes the LV size so as to allocate or free the desired quantity of physical extents (that might amount to a lower number of logical extents for the LV concerned) -l+50%FREE - Use up half the remaining free space in the VG when carrying out this operation. -l50%VG - After this operation, this LV should be using up half the space in the VG. -l200%LV - Double the logical size of this LV. -l+100%LV - Double the logical size of this LV. -l-50%LV - Reduce the logical size of this LV by half.
2014-02-25 02:48:23 +04:00
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
if (lp->sign == SIGN_NONE && (lp->percent == PERCENT_VG || lp->percent == PERCENT_FREE || lp->percent == PERCENT_PVS))
lp->approx_alloc = 1;
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
if (lp->sign == SIGN_PLUS && lp->percent == PERCENT_FREE)
lp->approx_alloc = 1;
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
log_verbose("Converted %" PRIu32 "%%%s into %s%" PRIu32 " %s extents.", old_extents, get_percent_string(lp->percent),
lp->approx_alloc ? "at most " : "", lp->extents, lp->extents_are_pes ? "physical" : "logical");
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
return 1;
}
lvresize: separate validation from action Start separating the validation from the action in the basic lvresize code moved to the library. Remove incorrect use of command line error codes from lvresize library functions. Move errors.h to tools directory to reinforce this, exporting public versions of the error codes in lvm2cmd.h for dmeventd plugins to use.
2013-07-06 06:28:21 +04:00
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
static int _add_pes(struct logical_volume *lv, void *data)
{
uint32_t *pe_total = data;
struct lv_segment *seg;
uint32_t s;
dm_list_iterate_items(seg, &lv->segments) {
for (s = 0; s < seg->area_count; s++) {
if (seg_type(seg, s) != AREA_PV)
continue;
*pe_total += seg_pvseg(seg, s)->len;
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
}
}
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
return 1;
}
static uint32_t _lv_pe_count(struct logical_volume *lv)
{
uint32_t pe_total = 0;
/* Top-level LV first */
if (!_add_pes(lv, &pe_total))
stack;
/* Any sub-LVs */
if (!for_each_sub_lv(lv, _add_pes, &pe_total))
stack;
return pe_total;
}
/* FIXME Avoid having variables like lp->extents mean different things at different places */
lvresize: do not pass struct cmd Use common API design and pass just LV pointer to lv_manip.c functions. Read cmd struct via lv->vg->cmd when needed. Also do not try to return EINVALID_CMD_LINE error when we have already openned VG - this error code can only be returned before locking VG.
2016-06-14 16:32:21 +03:00
static int _lvresize_adjust_extents(struct logical_volume *lv,
struct lvresize_params *lp,
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
int *matches_existing)
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
{
struct volume_group *vg = lv->vg;
lvresize: do not pass struct cmd Use common API design and pass just LV pointer to lv_manip.c functions. Read cmd struct via lv->vg->cmd when needed. Also do not try to return EINVALID_CMD_LINE error when we have already openned VG - this error code can only be returned before locking VG.
2016-06-14 16:32:21 +03:00
struct cmd_context *cmd = vg->cmd;
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
uint32_t logical_extents_used = 0;
uint32_t physical_extents_used = 0;
uint32_t seg_stripes = 0, seg_stripesize = 0;
uint32_t seg_mirrors = 0;
cleanup: adjust once
2016-01-19 13:44:11 +03:00
struct lv_segment *seg, *seg_last;
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
uint32_t sz, str;
uint32_t seg_logical_extents;
uint32_t seg_physical_extents;
uint32_t area_multiple;
cleanup: stripes_extents Simplify calculation of extents rounding needed for segment size. Segment size has to divisible by 'extent count' needed to contain whole stripe. LVM currently does not support stripes across segment. In case the stripe size is bigger then extent size, require bigger rounding.
2016-01-22 18:11:29 +03:00
uint32_t stripes_extents;
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
uint32_t size_rest;
uint32_t existing_logical_extents = lv->le_count;
uint32_t existing_physical_extents, saved_existing_physical_extents;
cleanup: adjust once
2016-01-19 13:44:11 +03:00
uint32_t existing_extents;
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
uint32_t seg_size = 0;
uint32_t new_extents;
thin: improve 16g support for thin pool metadata Initial support for thin-pool used slightly smaller max size 15.81GiB for thin-pool metadata. However the real limit later settled at 15.88GiB (difference is ~64MiB - 16448 4K blocks). lvm2 could not simply increase the size as it has been using hard cropping of the loaded metadata device to avoid warnings printing warning of kernel when the size was bigger (i.e. due to bigger extent_size). This patch adds the new lvm.conf configurable setting: allocation/thin_pool_crop_metadata which defaults to 0 -> no crop of metadata beyond 15.81GiB. Only user with these sizes of metadata will be affected. Without cropping lvm2 now limits metadata allocation size to 15.88GiB. Any space beyond is currently not used by thin-pool target. Even if i.e. bigger LV is used for metadata via lvconvert, or allocated bigger because of to large extent size. With cropping enabled (=1) lvm2 preserves the old limitation 15.81GiB and should allow to work in the evironement with older lvm2 tools (i.e. older distribution). Thin-pool metadata with size bigger then 15.81G is now using CROP_METADATA flag within lvm2 metadata, so older lvm2 recognizes an incompatible thin-pool and cannot activate such pool! Users should use uncropped version as it is not suffering from various issues between thin_repair results and allocated metadata LV as thin_repair limit is 15.88GiB Users should use cropping only when really needed! Patch also better handles resize of thin-pool metadata and prevents resize beoyond usable size 15.88GiB. Resize beyond 15.81GiB automatically switches pool to no-crop version. Even with existing bigger thin-pool metadata command 'lvextend -l+1 vg/pool_tmeta' does the change. Patch gives better controls 'coverted' metadata LV and reports less confusing message during conversion. Patch set also moves the code for updating min/max into pool_manip.c for better sharing with cache_pool code.
2021-01-12 19:59:29 +03:00
uint64_t max_metadata_size;
thin_crop_metadata_t crop;
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
int reducing = 0;
cleanup: adjust once
2016-01-19 13:44:11 +03:00
seg_last = last_seg(lv);
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
lvresize: allow mixing striped with errors or zero Enabled extension/mixing of stripes/linears, error and zero segtype LVs with stripes/linear, error and zero segtypes. It is not very useful in practice, as the user cannot store any real data on error or zero segtypes, but it may get some uses in some scenarios where i.e. some portion of the device should not be readable. Mixing of types happens on 'extent_size' level: lvcreate -L1 -n lv vg lvextend --type error -L+1 vg/lv lvextend --type zero -L+1 vg/lv lvextend --type linear -L+1 vg/lv lvextend --type striped -L+1 vg/lv lvs -o+segtype,seg_size vg Note: when the type is not specified, the last segment type is automatically selected. It's also a small 'can of worms' since we can't tell LVs if the LV is linear/error/zero or their mixtures. So the meaning behind them may need some updates. We already have this types of LV created i.e by: vgreduce --removemissing --force where missing LV segments have been replaced by either error or zero segtype (lvm.conf). TODO: it might be worth adding a message while such device is activated.
2021-03-18 15:19:45 +03:00
if (!lp->segtype)
/* Use segment type of last segment */
lp->segtype = seg_last->segtype;
else if (lp->segtype != seg_last->segtype) {
/* Support newseg error or zero with lastseg striped
* and newseg striped with lastseg error or zero */
if ((segtype_is_error(lp->segtype) || segtype_is_zero(lp->segtype) ||
segtype_is_striped(lp->segtype)) &&
(segtype_is_striped(seg_last->segtype) ||
segtype_is_error(seg_last->segtype) || segtype_is_zero(seg_last->segtype))) {
if (!lp->stripes)
lp->stripes = 1;
} else {
log_error("VolumeType does not match (%s).", lp->segtype->name);
return 0;
}
/* FIXME Support more LVs with mixed segment types */
log_print_unless_silent("Logical volume %s is using mixing segment types %s and %s.",
display_lvname(lv), seg_last->segtype->name, lp->segtype->name);
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
}
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
/* For virtual devices, just pretend the physical size matches. */
existing_physical_extents = saved_existing_physical_extents = _lv_pe_count(lv);
if (!existing_physical_extents) {
existing_physical_extents = lv->le_count;
lp->extents_are_pes = 0;
}
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
cleanup: adjust once
2016-01-19 13:44:11 +03:00
existing_extents = (lp->extents_are_pes)
? existing_physical_extents : existing_logical_extents;
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
/* Initial decision on whether we are extending or reducing */
if (lp->sign == SIGN_MINUS ||
cleanup: adjust once
2016-01-19 13:44:11 +03:00
(lp->sign == SIGN_NONE && (lp->extents < existing_extents)))
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
reducing = 1;
/* If extending, find properties of last segment */
if (!reducing) {
cleanup: adjust once
2016-01-19 13:44:11 +03:00
seg_mirrors = seg_is_mirrored(seg_last) ? lv_mirror_count(lv) : 0;
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
lvresize: update lvresize_params struct Reorganise struct lvresize_params to better fit lvresize needs to be able to resize more then just a single LV.
2016-06-17 14:25:41 +03:00
if (!lp->mirrors && seg_mirrors) {
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
log_print_unless_silent("Extending %" PRIu32 " mirror images.", seg_mirrors);
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
lp->mirrors = seg_mirrors;
lvresize: update lvresize_params struct Reorganise struct lvresize_params to better fit lvresize needs to be able to resize more then just a single LV.
2016-06-17 14:25:41 +03:00
} else if ((lp->mirrors || seg_mirrors) && (lp->mirrors != seg_mirrors)) {
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
log_error("Cannot vary number of mirrors in LV yet.");
lvresize: separate validation from action Start separating the validation from the action in the basic lvresize code moved to the library. Remove incorrect use of command line error codes from lvresize library functions. Move errors.h to tools directory to reinforce this, exporting public versions of the error codes in lvm2cmd.h for dmeventd plugins to use.
2013-07-06 06:28:21 +04:00
return 0;
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
}
cleanup: adjust once
2016-01-19 13:44:11 +03:00
if (seg_is_raid10(seg_last)) {
coverity: add few internal errors Mark impossible paths with internal errors. Also replace 'strcmp() with more readable seg_is...()
2015-11-13 11:49:59 +03:00
if (!seg_mirrors) {
log_error(INTERNAL_ERROR "Missing mirror segments for %s.",
display_lvname(lv));
return 0;
}
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
/* FIXME Warn if command line values are being overridden? */
cleanup: adjust once
2016-01-19 13:44:11 +03:00
lp->stripes = seg_last->area_count / seg_mirrors;
lp->stripe_size = seg_last->stripe_size;
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
} else if (!(lp->stripes == 1 || (lp->stripes > 1 && lp->stripe_size))) {
/* If extending, find stripes, stripesize & size of last segment */
/* FIXME Don't assume mirror seg will always be AREA_LV */
/* FIXME We will need to support resize for metadata LV as well,
* and data LV could be any type (i.e. mirror)) */
cleanup: adjust once
2016-01-19 13:44:11 +03:00
dm_list_iterate_items(seg, seg_mirrors ? &seg_lv(seg_last, 0)->segments : &lv->segments) {
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
/* Allow through "striped" and RAID 4/5/6/10 */
if (!seg_is_striped(seg) &&
(!seg_is_raid(seg) || seg_is_mirrored(seg)) &&
coverity: add few internal errors Mark impossible paths with internal errors. Also replace 'strcmp() with more readable seg_is...()
2015-11-13 11:49:59 +03:00
!seg_is_raid10(seg))
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
continue;
cleanup: spaces
2016-01-11 16:11:37 +03:00
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
sz = seg->stripe_size;
str = seg->area_count - lp->segtype->parity_devs;
cleanup: spaces
2016-01-11 16:11:37 +03:00
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
if ((seg_stripesize && seg_stripesize != sz &&
sz && !lp->stripe_size) ||
(seg_stripes && seg_stripes != str && !lp->stripes)) {
log_error("Please specify number of "
"stripes (-i) and stripesize (-I)");
return 0;
}
cleanup: spaces
2016-01-11 16:11:37 +03:00
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
seg_stripesize = sz;
seg_stripes = str;
}
cleanup: spaces
2016-01-11 16:11:37 +03:00
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
if (!lp->stripes)
lp->stripes = seg_stripes;
else if (seg_is_raid(first_seg(lv)) &&
(lp->stripes != seg_stripes)) {
log_error("Unable to extend \"%s\" segment type with different number of stripes.",
segments: introduce lvseg_name Instead of segtype->ops->name() introduce lvseg_name(). This also allows us to leave name() function 'empty' for default return of segtype->name. TODO: add functions for rest of ops->
2014-10-20 20:40:39 +04:00
lvseg_name(first_seg(lv)));
lvresize: separate validation from action Start separating the validation from the action in the basic lvresize code moved to the library. Remove incorrect use of command line error codes from lvresize library functions. Move errors.h to tools directory to reinforce this, exporting public versions of the error codes in lvm2cmd.h for dmeventd plugins to use.
2013-07-06 06:28:21 +04:00
return 0;
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
}
cleanup: spaces
2016-01-11 16:11:37 +03:00
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
if (!lp->stripe_size && lp->stripes > 1) {
if (seg_stripesize) {
log_print_unless_silent("Using stripesize of last segment %s",
display_size(cmd, (uint64_t) seg_stripesize));
lp->stripe_size = seg_stripesize;
} else {
lp->stripe_size =
find_config_tree_int(cmd, metadata_stripesize_CFG, NULL) * 2;
log_print_unless_silent("Using default stripesize %s",
display_size(cmd, (uint64_t) lp->stripe_size));
}
}
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
}
cleanup: adjust once
2016-01-19 13:44:11 +03:00
if (lp->stripes > 1 && !lp->stripe_size) {
log_error("Stripesize for striped segment should not be 0!");
return 0;
}
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
/* Determine the amount to extend by */
if (lp->sign == SIGN_PLUS)
seg_size = lp->extents;
else
cleanup: adjust once
2016-01-19 13:44:11 +03:00
seg_size = lp->extents - existing_extents;
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
vdo: enhance vdo pool extension When user tries to extend vdo pool - he needs to go always at least by 1 full VDO slab (defined as vdo_slab_size_mb). To avoid all trouble around find 'workable' size - lvm2 automatically increases the passed (or by --use-policies calculated) extension size (and informs a user about sometimes possibly large increase as slab size can go upto 32GiB) With VDO users need to always 'think-big' anyway and expect such operation to be in GiB domain range.
2020-09-23 00:25:58 +03:00
if (lv_is_vdo_pool_data(lv)) {
if (!(seg = get_only_segment_using_this_lv(lv)))
return_0;
/* Min growth is defined this way: max(1 slab, 128M + 128K (recovery journal + slab summary)) */
new_extents = max(seg->vdo_params.slab_size_mb * 1024, UINT32_C(128 * 1024 + 128));
new_extents *= (1024 >> SECTOR_SHIFT); /* minimal growth (~128MiB..32GiB) in sectors */
if (new_extents > vg->extent_size) {
/* Minimal growth in extent size units */
new_extents = (new_extents + vg->extent_size - 1) / vg->extent_size;
if (new_extents > seg_size) {
/* Notify user about extra increase of extension */
log_print_unless_silent("Increasing incremention size from %s to %s to fit new VDO slab.",
display_size(cmd, (uint64_t)seg_size * vg->extent_size),
display_size(cmd, (uint64_t)new_extents * vg->extent_size));
seg_size = new_extents;
}
}
}
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
/* Convert PEs to LEs */
cleanup: adjust once
2016-01-19 13:44:11 +03:00
if (lp->extents_are_pes && !seg_is_striped(seg_last) && !seg_is_virtual(seg_last)) {
area_multiple = _calc_area_multiple(seg_last->segtype, seg_last->area_count, 0);
seg_size = seg_size * area_multiple / (seg_last->area_count - seg_last->segtype->parity_devs);
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
seg_size = (seg_size / area_multiple) * area_multiple;
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
}
cleanup: adjust once
2016-01-19 13:44:11 +03:00
if (seg_size >= (MAX_EXTENT_COUNT - existing_logical_extents)) {
log_error("Unable to extend %s by %u logical extents: exceeds limit (%u).",
cleanup: use display_lvname
2016-06-23 14:04:37 +03:00
display_lvname(lv), seg_size, MAX_EXTENT_COUNT);
cleanup: adjust once
2016-01-19 13:44:11 +03:00
return 0;
}
lp->extents = existing_logical_extents + seg_size;
/* Don't allow a cow to grow larger than necessary. */
if (lv_is_cow(lv)) {
logical_extents_used = cow_max_extents(origin_from_cow(lv), find_snapshot(lv)->chunk_size);
if (logical_extents_used < lp->extents) {
log_print_unless_silent("Reached maximum COW size %s (%" PRIu32 " extents).",
display_size(vg->cmd, (uint64_t) vg->extent_size * logical_extents_used),
logical_extents_used);
lp->extents = logical_extents_used; // CHANGES lp->extents
seg_size = lp->extents - existing_logical_extents; // Recalculate
if (lp->extents == existing_logical_extents) {
/* Signal that normal resizing is not required */
snapshot: no error when extending above max size When lvm2 calculates the maximal usable COW size and crops the user requested size to this value, don't return the error result from the 'lvextend' operation. We already apply the same logic when resizing thin-pool beyond the supported maximal size. FIXME: The return code error logic here is somewhat fuzzy.
2023-06-30 00:19:09 +03:00
lp->size_changed = 1;
cleanup: adjust once
2016-01-19 13:44:11 +03:00
return 1;
}
}
thin: improve 16g support for thin pool metadata Initial support for thin-pool used slightly smaller max size 15.81GiB for thin-pool metadata. However the real limit later settled at 15.88GiB (difference is ~64MiB - 16448 4K blocks). lvm2 could not simply increase the size as it has been using hard cropping of the loaded metadata device to avoid warnings printing warning of kernel when the size was bigger (i.e. due to bigger extent_size). This patch adds the new lvm.conf configurable setting: allocation/thin_pool_crop_metadata which defaults to 0 -> no crop of metadata beyond 15.81GiB. Only user with these sizes of metadata will be affected. Without cropping lvm2 now limits metadata allocation size to 15.88GiB. Any space beyond is currently not used by thin-pool target. Even if i.e. bigger LV is used for metadata via lvconvert, or allocated bigger because of to large extent size. With cropping enabled (=1) lvm2 preserves the old limitation 15.81GiB and should allow to work in the evironement with older lvm2 tools (i.e. older distribution). Thin-pool metadata with size bigger then 15.81G is now using CROP_METADATA flag within lvm2 metadata, so older lvm2 recognizes an incompatible thin-pool and cannot activate such pool! Users should use uncropped version as it is not suffering from various issues between thin_repair results and allocated metadata LV as thin_repair limit is 15.88GiB Users should use cropping only when really needed! Patch also better handles resize of thin-pool metadata and prevents resize beoyond usable size 15.88GiB. Resize beyond 15.81GiB automatically switches pool to no-crop version. Even with existing bigger thin-pool metadata command 'lvextend -l+1 vg/pool_tmeta' does the change. Patch gives better controls 'coverted' metadata LV and reports less confusing message during conversion. Patch set also moves the code for updating min/max into pool_manip.c for better sharing with cache_pool code.
2021-01-12 19:59:29 +03:00
} else if (lv_is_thin_pool_metadata(lv)) {
if (!(seg = get_only_segment_using_this_lv(lv)))
return_0;
thinpool: use lv_config_profil for crop_metadata Better support for thin-pools with individual profiles introduced in the recent patch b4212be2e7e8797bbf8f9a166347659cc39ba075.
2021-02-05 01:26:08 +03:00
max_metadata_size = get_thin_pool_max_metadata_size(cmd, lv_config_profile(lv), &crop);
thin: improve 16g support for thin pool metadata Initial support for thin-pool used slightly smaller max size 15.81GiB for thin-pool metadata. However the real limit later settled at 15.88GiB (difference is ~64MiB - 16448 4K blocks). lvm2 could not simply increase the size as it has been using hard cropping of the loaded metadata device to avoid warnings printing warning of kernel when the size was bigger (i.e. due to bigger extent_size). This patch adds the new lvm.conf configurable setting: allocation/thin_pool_crop_metadata which defaults to 0 -> no crop of metadata beyond 15.81GiB. Only user with these sizes of metadata will be affected. Without cropping lvm2 now limits metadata allocation size to 15.88GiB. Any space beyond is currently not used by thin-pool target. Even if i.e. bigger LV is used for metadata via lvconvert, or allocated bigger because of to large extent size. With cropping enabled (=1) lvm2 preserves the old limitation 15.81GiB and should allow to work in the evironement with older lvm2 tools (i.e. older distribution). Thin-pool metadata with size bigger then 15.81G is now using CROP_METADATA flag within lvm2 metadata, so older lvm2 recognizes an incompatible thin-pool and cannot activate such pool! Users should use uncropped version as it is not suffering from various issues between thin_repair results and allocated metadata LV as thin_repair limit is 15.88GiB Users should use cropping only when really needed! Patch also better handles resize of thin-pool metadata and prevents resize beoyond usable size 15.88GiB. Resize beyond 15.81GiB automatically switches pool to no-crop version. Even with existing bigger thin-pool metadata command 'lvextend -l+1 vg/pool_tmeta' does the change. Patch gives better controls 'coverted' metadata LV and reports less confusing message during conversion. Patch set also moves the code for updating min/max into pool_manip.c for better sharing with cache_pool code.
2021-01-12 19:59:29 +03:00
if (((uint64_t)lp->extents * vg->extent_size) > max_metadata_size) {
lp->extents = (max_metadata_size + vg->extent_size - 1) / vg->extent_size;
log_print_unless_silent("Reached maximum pool metadata size %s (%" PRIu32 " extents).",
display_size(vg->cmd, max_metadata_size), lp->extents);
}
if (existing_logical_extents >= lp->extents)
lp->extents = existing_logical_extents;
crop = get_thin_pool_crop_metadata(cmd, crop, (uint64_t)lp->extents * vg->extent_size);
if (seg->crop_metadata != crop) {
seg->crop_metadata = crop;
seg->lv->status |= LV_CROP_METADATA;
/* Crop change require reload even if there no size change */
lp->size_changed = 1;
log_print_unless_silent("Thin pool will use metadata without cropping.");
}
if (!(seg_size = lp->extents - existing_logical_extents))
return 1; /* No change in metadata size */
cleanup: adjust once
2016-01-19 13:44:11 +03:00
}
lvresize: add new options and defaults for fs handling The new option "--fs String" for lvresize/lvreduce/lvextend controls the handling of file systems before/after resizing the LV. --resizefs is the same as --fs resize. The new option "--fsmode String" can be used to control mounting and unmounting of the fs during resizing. Possible --fs values: checksize Only applies to reducing size; does nothing for extend. Check the fs size and reduce the LV if the fs is not using the affected space, i.e. the fs does not need to be shrunk. Fail the command without reducing the fs or LV if the fs is using the affected space. resize Resize the fs using the fs-specific resize command. This may include mounting, unmounting, or running fsck. See --fsmode to control mounting behavior, and --nofsck to disable fsck. resize_fsadm Use the old method of calling fsadm to handle the fs (deprecated.) Warning: this option does not prevent lvreduce from destroying file systems that are unmounted (or mounted if prompts are skipped.) ignore Resize the LV without checking for or handling a file system. Warning: using ignore when reducing the LV size may destroy the file system. Possible --fsmode values: manage Mount or unmount the fs as needed to resize the fs, and attempt to restore the original mount state at the end. nochange Do not mount or unmount the fs. If mounting or unmounting is required to resize the fs, then do not resize the fs or the LV and fail the command. offline Unmount the fs if it is mounted, and resize the fs while it is unmounted. If mounting is required to resize the fs, then do not resize the fs or the LV and fail the command. Notes on lvreduce: When no --fs or --resizefs option is specified: . lvextend default behavior is fs ignore. . lvreduce default behavior is fs checksize (includes activating the LV.) With the exception of --fs resize_fsadm|ignore, lvreduce requires the recent libblkid fields FSLASTBLOCK and FSBLOCKSIZE. FSLASTBLOCK*FSBLOCKSIZE is the last byte used by the fs on the LV, which determines if reducing the fs is necessary.
2022-06-14 23:20:21 +03:00
} else {
/* If reducing, find stripes, stripesize & size of last segment */
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
cleanup: simplier formula
2016-01-08 13:07:47 +03:00
if (lp->sign == SIGN_MINUS) {
cleanup: adjust once
2016-01-19 13:44:11 +03:00
if (lp->extents >= existing_extents) {
cleanup: use display_lvname
2016-06-23 14:04:37 +03:00
log_error("Unable to reduce %s below 1 extent.",
display_lvname(lv));
cleanup: simplier formula
2016-01-08 13:07:47 +03:00
return 0;
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
}
cleanup: adjust once
2016-01-19 13:44:11 +03:00
new_extents = existing_extents - lp->extents;
cleanup: simplier formula
2016-01-08 13:07:47 +03:00
} else
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
new_extents = lp->extents;
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
dm_list_iterate_items(seg, &lv->segments) {
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
seg_logical_extents = seg->len;
seg_physical_extents = seg->area_len * seg->area_count; /* FIXME Also metadata, cow etc. */
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
/* Check for underlying stripe sizes */
tidy: Add missing underscores to statics.
2017-10-18 17:57:46 +03:00
seg_stripes = _lvseg_get_stripes(seg, &seg_stripesize);
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
if (seg_is_mirrored(seg))
seg_mirrors = lv_mirror_count(seg->lv);
else
seg_mirrors = 0;
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
/* Have we reached the final segment of the new LV? */
if (lp->extents_are_pes) {
if (new_extents <= physical_extents_used + seg_physical_extents) {
seg_size = new_extents - physical_extents_used;
if (seg_mirrors)
seg_size /= seg_mirrors;
lp->extents = logical_extents_used + seg_size;
break;
lvreduce: make _lvseg_get_stripes handle integrity layer lvreduce uses _lvseg_get_stripes() which was unable to get raid stripe info with an integrity layer present. This caused lvreduce on a raid+integrity LV to fail prematurely when checking stripe parameters. An unhelpful error message about stripe size would be printed.
2023-05-03 00:12:23 +03:00
}
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
} else if (new_extents <= logical_extents_used + seg_logical_extents) {
seg_size = new_extents - logical_extents_used;
lp->extents = new_extents;
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
break;
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
}
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
logical_extents_used += seg_logical_extents;
physical_extents_used += seg_physical_extents;
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
}
lp->stripe_size = seg_stripesize;
lp->stripes = seg_stripes;
lp->mirrors = seg_mirrors;
}
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
/* At this point, lp->extents should hold the correct NEW logical size required. */
if (!lp->extents) {
cleanup: add some dots to messages
2016-07-12 23:25:21 +03:00
log_error("New size of 0 not permitted.");
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
return 0;
}
lv_resize: support resizing of cached volumes Automatically figure out resizable layer in the LV stack and resize it online. Split check for reshaped raids and postpone removal of unused space after finished reshaping after metadata archiving. Drop warning about unsupported automatic resize of monitored thin-pool. Currently there is not yet support for resize of writecache.
2021-02-07 22:12:00 +03:00
if ((lp->extents == existing_logical_extents) && !lp->use_policies) {
cleanup: correcting some log_print Correcting to log_print_unless_silent(), so -qq can do some work.
2023-04-26 15:40:11 +03:00
log_print_unless_silent("New size (%d extents) matches existing size (%d extents).",
lp->extents, existing_logical_extents);
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
if (lp->resize == LV_ANY)
lp->resize = LV_EXTEND; /* lets pretend zero size extension */
*matches_existing = 1;
return 1;
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
}
/* Perform any rounding to produce complete stripes. */
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
if (lp->stripes > 1) {
if (lp->stripe_size < STRIPE_SIZE_MIN) {
cleanup: add some dots to messages
2016-07-12 23:25:21 +03:00
log_error("Invalid stripe size %s.",
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
display_size(cmd, (uint64_t) lp->stripe_size));
lvresize: separate validation from action Start separating the validation from the action in the basic lvresize code moved to the library. Remove incorrect use of command line error codes from lvresize library functions. Move errors.h to tools directory to reinforce this, exporting public versions of the error codes in lvm2cmd.h for dmeventd plugins to use.
2013-07-06 06:28:21 +04:00
return 0;
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
}
cleanup: stripes_extents Simplify calculation of extents rounding needed for segment size. Segment size has to divisible by 'extent count' needed to contain whole stripe. LVM currently does not support stripes across segment. In case the stripe size is bigger then extent size, require bigger rounding.
2016-01-22 18:11:29 +03:00
/* Segment size in extents must be divisible by stripes */
stripes_extents = lp->stripes;
if (lp->stripe_size > vg->extent_size)
/* Strip size is bigger then extent size needs more extents */
stripes_extents *= (lp->stripe_size / vg->extent_size);
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
cleanup: stripes_extents Simplify calculation of extents rounding needed for segment size. Segment size has to divisible by 'extent count' needed to contain whole stripe. LVM currently does not support stripes across segment. In case the stripe size is bigger then extent size, require bigger rounding.
2016-01-22 18:11:29 +03:00
size_rest = seg_size % stripes_extents;
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
/* Round toward the original size. */
if (size_rest &&
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
((lp->extents < existing_logical_extents) ||
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
!lp->percent ||
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
(vg->free_count >= (lp->extents - existing_logical_extents - size_rest +
cleanup: stripes_extents Simplify calculation of extents rounding needed for segment size. Segment size has to divisible by 'extent count' needed to contain whole stripe. LVM currently does not support stripes across segment. In case the stripe size is bigger then extent size, require bigger rounding.
2016-01-22 18:11:29 +03:00
stripes_extents)))) {
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
log_print_unless_silent("Rounding size (%d extents) up to stripe "
cleanup: add some dots to messages
2016-07-12 23:25:21 +03:00
"boundary size for segment (%d extents).",
cleanup: stripes_extents Simplify calculation of extents rounding needed for segment size. Segment size has to divisible by 'extent count' needed to contain whole stripe. LVM currently does not support stripes across segment. In case the stripe size is bigger then extent size, require bigger rounding.
2016-01-22 18:11:29 +03:00
lp->extents,
lp->extents - size_rest + stripes_extents);
lp->extents = lp->extents - size_rest + stripes_extents;
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
} else if (size_rest) {
log_print_unless_silent("Rounding size (%d extents) down to stripe "
"boundary size for segment (%d extents)",
lp->extents, lp->extents - size_rest);
lp->extents = lp->extents - size_rest;
}
}
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
/* Final sanity checking */
if (lp->extents < existing_logical_extents) {
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
if (lp->resize == LV_EXTEND) {
log_error("New size given (%d extents) not larger "
"than existing size (%d extents)",
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
lp->extents, existing_logical_extents);
lvresize: separate validation from action Start separating the validation from the action in the basic lvresize code moved to the library. Remove incorrect use of command line error codes from lvresize library functions. Move errors.h to tools directory to reinforce this, exporting public versions of the error codes in lvm2cmd.h for dmeventd plugins to use.
2013-07-06 06:28:21 +04:00
return 0;
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
}
lp->resize = LV_REDUCE;
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
} else if (lp->extents > existing_logical_extents) {
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
if (lp->resize == LV_REDUCE) {
log_error("New size given (%d extents) not less than "
"existing size (%d extents)", lp->extents,
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
existing_logical_extents);
lvresize: separate validation from action Start separating the validation from the action in the basic lvresize code moved to the library. Remove incorrect use of command line error codes from lvresize library functions. Move errors.h to tools directory to reinforce this, exporting public versions of the error codes in lvm2cmd.h for dmeventd plugins to use.
2013-07-06 06:28:21 +04:00
return 0;
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
}
lp->resize = LV_EXTEND;
lvresize: update lvresize_params struct Reorganise struct lvresize_params to better fit lvresize needs to be able to resize more then just a single LV.
2016-06-17 14:25:41 +03:00
} else if ((lp->extents == existing_logical_extents) && !lp->use_policies) {
cleanup: correcting some log_print Correcting to log_print_unless_silent(), so -qq can do some work.
2023-04-26 15:40:11 +03:00
log_print_unless_silent("New size (%d extents) matches existing size (%d extents)",
lp->extents, existing_logical_extents);
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
if (lp->resize == LV_ANY)
lp->resize = LV_EXTEND;
*matches_existing = 1;
return 1;
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
}
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
/*
* Has the user specified that they would like the additional
* extents of a mirror not to have an initial sync?
*/
if ((lp->extents > existing_logical_extents)) {
lvresize: update lvresize_params struct Reorganise struct lvresize_params to better fit lvresize needs to be able to resize more then just a single LV.
2016-06-17 14:25:41 +03:00
if (seg_is_mirrored(first_seg(lv)) && lp->nosync)
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
lv->status |= LV_NOTSYNCED;
}
log_debug("New size for %s: %" PRIu32 ". Existing logical extents: %" PRIu32 " / physical extents: %" PRIu32 ".",
display_lvname(lv), lp->extents, existing_logical_extents, saved_existing_physical_extents);
lvresize: separate validation from action Start separating the validation from the action in the basic lvresize code moved to the library. Remove incorrect use of command line error codes from lvresize library functions. Move errors.h to tools directory to reinforce this, exporting public versions of the error codes in lvm2cmd.h for dmeventd plugins to use.
2013-07-06 06:28:21 +04:00
return 1;
}
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
static int _lv_reduce_vdo_discard(struct cmd_context *cmd,
struct logical_volume *lv,
struct lvresize_params *lp)
{
char name[PATH_MAX];
struct device *dev;
struct volume_group *vg = lv->vg;
/* FIXME: stop using dev-cache and struct device here, dev-cache
should only be used for scanning headers/metadata to find PVs. */
if (dm_snprintf(name, sizeof(name), "%s%s/%s", cmd->dev_dir,
vg->name, lv->name) < 0) {
log_error("Name too long - device not discarded (%s)", lv->name);
return 0;
}
if (!(dev = dev_cache_get(cmd, name, NULL))) {
log_error("%s: not found: device not discarded.", name);
return 0;
}
if (!dev_discard_max_bytes(cmd->dev_types, dev) ||
!dev_discard_granularity(cmd->dev_types, dev)) {
log_error("%s: max bytes and granularity query fails.", name);
dev_destroy_file(dev);
return 0;
}
log_warn("WARNING: %s: Discarding %s at offset " FMTu64 ", please wait...",
name, display_size(cmd, (uint64_t)(lv->le_count - lp->extents) * vg->extent_size),
((uint64_t)lp->extents * vg->extent_size) << SECTOR_SHIFT);
if (!dev_discard_blocks(dev, ((uint64_t)lp->extents * vg->extent_size) << SECTOR_SHIFT,
((uint64_t)(lv->le_count - lp->extents) * vg->extent_size) << SECTOR_SHIFT)) {
log_error("%s: discarding failed.", name);
dev_destroy_file(dev);
return 0;
}
dev_destroy_file(dev);
return 1;
}
static int _lv_resize_check_type(struct logical_volume *lv,
struct lvresize_params *lp)
lvresize: separate validation from action Start separating the validation from the action in the basic lvresize code moved to the library. Remove incorrect use of command line error codes from lvresize library functions. Move errors.h to tools directory to reinforce this, exporting public versions of the error codes in lvm2cmd.h for dmeventd plugins to use.
2013-07-06 06:28:21 +04:00
{
coverity: extra check for find_pool_seg find_pool_seg may return NULL in some internal error stats. Handle it explicitely.
2017-06-27 11:16:13 +03:00
struct lv_segment *seg;
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
if (lv_is_origin(lv)) {
if (lp->resize == LV_REDUCE) {
cleanup: add dots to some messages Add missing dots and one comment.
2016-06-14 15:56:17 +03:00
log_error("Snapshot origin volumes cannot be reduced in size yet.");
lvresize: separate validation from action Start separating the validation from the action in the basic lvresize code moved to the library. Remove incorrect use of command line error codes from lvresize library functions. Move errors.h to tools directory to reinforce this, exporting public versions of the error codes in lvm2cmd.h for dmeventd plugins to use.
2013-07-06 06:28:21 +04:00
return 0;
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
}
if (lv_is_active(lv)) {
log_error("Snapshot origin volumes can be resized "
cleanup: add some dots to messages
2016-07-12 23:25:21 +03:00
"only while inactive: try lvchange -an.");
lvresize: separate validation from action Start separating the validation from the action in the basic lvresize code moved to the library. Remove incorrect use of command line error codes from lvresize library functions. Move errors.h to tools directory to reinforce this, exporting public versions of the error codes in lvm2cmd.h for dmeventd plugins to use.
2013-07-06 06:28:21 +04:00
return 0;
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
}
}
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
if (lv_is_raid_image(lv) || lv_is_raid_metadata(lv)) {
log_error("Cannot resize a RAID %s directly for %s",
lv_is_raid_image(lv) ? "image" : "metadata area",
display_lvname(lv));
return 0;
}
seg = first_seg(lv);
if ((seg_is_raid4(seg) || seg_is_any_raid5(seg)) && seg->area_count < 3) {
log_error("Cannot resize %s LV %s. Convert to more stripes first.",
lvseg_name(seg), display_lvname(lv));
return 0;
}
cleanup: more readable check
2015-12-15 17:13:11 +03:00
if (lp->resize == LV_REDUCE) {
lvresize: support more resized LVs Add code to support more LVs to be resized through a same code path using a single lvresize_params struct. (Now it's used for thin-pool metadata resize, next user will be snapshot virtual resize). Update code to adjust percent amount resize for use_policies. Properly activate inactive thin-pool in case of any pool resize as the command should not 'deffer' this operation to next activation.
2016-06-23 00:32:35 +03:00
if (lv_is_thin_pool_data(lv)) {
log_error("Thin pool volumes %s cannot be reduced in size yet.",
display_lvname(lv));
lvresize: separate validation from action Start separating the validation from the action in the basic lvresize code moved to the library. Remove incorrect use of command line error codes from lvresize library functions. Move errors.h to tools directory to reinforce this, exporting public versions of the error codes in lvm2cmd.h for dmeventd plugins to use.
2013-07-06 06:28:21 +04:00
return 0;
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
}
cleanup: more readable check
2015-12-15 17:13:11 +03:00
if (lv_is_thin_pool_metadata(lv)) {
log_error("Thin pool metadata volumes cannot be reduced.");
return 0;
}
vdo: allow resize of VDO and VDO pool volumes Now with newer VDO kvdo target we can start to use standard mechanism to enable resize of VDO volumes. VDO pool can be grown. Virtual volume grows on top of VDO pool when is not big enough. Reduced VDOLV is calling discard for reduced areas - this can take long time! TODO: implement some pollable mechanism for out-of-lock TRIM.
2019-01-10 20:00:06 +03:00
if (lv_is_vdo_pool_data(lv)) {
log_error("Cannot reduce VDO pool data volume %s.",
display_lvname(lv));
return 0;
}
lvextend: enable resize of writecached LV
2021-02-21 00:22:51 +03:00
if (lv_is_writecache(lv)) {
/* TODO: detect kernel with support for reduction */
log_error("Reduce not yet allowed on LVs with writecache attached.");
return 0;
}
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
if (lv_is_raid(lv)) {
unsigned attrs = 0;
const struct segment_type *segtype = first_seg(lv)->segtype;
if (!segtype->ops->target_present ||
!segtype->ops->target_present(lv->vg->cmd, NULL, &attrs) ||
!(attrs & RAID_FEATURE_SHRINK)) {
log_error("RAID module does not support shrinking.");
return 0;
}
}
if (lv_is_integrity(lv) || lv_raid_has_integrity(lv)) {
log_error("Cannot reduce LV with integrity.");
return 0;
}
cleanup: more readable check
2015-12-15 17:13:11 +03:00
} else if (lp->resize == LV_EXTEND) {
lvresize: support more resized LVs Add code to support more LVs to be resized through a same code path using a single lvresize_params struct. (Now it's used for thin-pool metadata resize, next user will be snapshot virtual resize). Update code to adjust percent amount resize for use_policies. Properly activate inactive thin-pool in case of any pool resize as the command should not 'deffer' this operation to next activation.
2016-06-23 00:32:35 +03:00
if (lv_is_thin_pool_metadata(lv) &&
coverity: extra check for find_pool_seg find_pool_seg may return NULL in some internal error stats. Handle it explicitely.
2017-06-27 11:16:13 +03:00
(!(seg = find_pool_seg(first_seg(lv))) ||
!thin_pool_feature_supported(seg->lv, THIN_FEATURE_METADATA_RESIZE))) {
lvresize: support more resized LVs Add code to support more LVs to be resized through a same code path using a single lvresize_params struct. (Now it's used for thin-pool metadata resize, next user will be snapshot virtual resize). Update code to adjust percent amount resize for use_policies. Properly activate inactive thin-pool in case of any pool resize as the command should not 'deffer' this operation to next activation.
2016-06-23 00:32:35 +03:00
log_error("Support for online metadata resize of %s not detected.",
display_lvname(lv));
return 0;
}
thin: disable extension of reduced thin with etx.origin Since we are currently incapable of providing zeroes for reextended thin volume area, let's disable extension of such already reduce thin volumes. (in-release change)
2014-01-28 13:24:50 +04:00
/* Validate thin target supports bigger size of thin volume then external origin */
cleanup: more readable check
2015-12-15 17:13:11 +03:00
if (lv_is_thin_volume(lv) && first_seg(lv)->external_lv &&
lvresize: check external origin with new size Instead of checking with existing size of external origin LV, use correctly the new 'wanted' size of this LV whether it fits the limitiation requirements for older thin-pool target. Otherwise code started to the the resize, updates metadata and just fails during 'resize' in case the LV was active. For inactive LV operation could have actually passed.
2018-02-28 19:04:26 +03:00
(lp->extents > first_seg(lv)->external_lv->le_count) &&
thin: disable extension of reduced thin with etx.origin Since we are currently incapable of providing zeroes for reextended thin volume area, let's disable extension of such already reduce thin volumes. (in-release change)
2014-01-28 13:24:50 +04:00
!thin_pool_feature_supported(first_seg(lv)->pool_lv, THIN_FEATURE_EXTERNAL_ORIGIN_EXTEND)) {
log_error("Thin target does not support external origin smaller then thin volume.");
return 0;
}
}
lv_resize: support resizing of cached volumes Automatically figure out resizable layer in the LV stack and resize it online. Split check for reshaped raids and postpone removal of unused space after finished reshaping after metadata archiving. Drop warning about unsupported automatic resize of monitored thin-pool. Currently there is not yet support for resize of writecache.
2021-02-07 22:12:00 +03:00
/* Prevent resizing on out-of-sync reshapable raid */
if (first_seg(lv)->reshape_len && !lv_raid_in_sync(lv)) {
log_error("Can't resize reshaping LV %s.", display_lvname(lv));
return 0;
}
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
if ((lp->resize == LV_REDUCE) && (lp->pvh != &lv->vg->pvs))
log_print_unless_silent("Ignoring PVs on command line when reducing.");
lvresize: separate validation from action Start separating the validation from the action in the basic lvresize code moved to the library. Remove incorrect use of command line error codes from lvresize library functions. Move errors.h to tools directory to reinforce this, exporting public versions of the error codes in lvm2cmd.h for dmeventd plugins to use.
2013-07-06 06:28:21 +04:00
return 1;
}
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
static int _lv_resize_volume(struct logical_volume *lv,
struct lvresize_params *lp,
struct dm_list *pvh)
lvresize: separate validation from action Start separating the validation from the action in the basic lvresize code moved to the library. Remove incorrect use of command line error codes from lvresize library functions. Move errors.h to tools directory to reinforce this, exporting public versions of the error codes in lvm2cmd.h for dmeventd plugins to use.
2013-07-06 06:28:21 +04:00
{
struct volume_group *vg = lv->vg;
lvresize: do not pass struct cmd Use common API design and pass just LV pointer to lv_manip.c functions. Read cmd struct via lv->vg->cmd when needed. Also do not try to return EINVALID_CMD_LINE error when we have already openned VG - this error code can only be returned before locking VG.
2016-06-14 16:32:21 +03:00
struct cmd_context *cmd = vg->cmd;
lvresize: Allow approximation with +%FREE. Make lvresize -l+%FREE support approximate allocation. Move existing "Reducing/Extending' message to verbose level and change it to say 'up to' if approximate allocation is being used. Replace it with a new message that gives the actual old and new size or says 'unchanged'.
2014-08-01 03:35:43 +04:00
uint32_t old_extents;
lvresize: support more resized LVs Add code to support more LVs to be resized through a same code path using a single lvresize_params struct. (Now it's used for thin-pool metadata resize, next user will be snapshot virtual resize). Update code to adjust percent amount resize for use_policies. Properly activate inactive thin-pool in case of any pool resize as the command should not 'deffer' this operation to next activation.
2016-06-23 00:32:35 +03:00
alloc_policy_t alloc = lp->alloc ? : lv->alloc;
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
lvresize: Allow approximation with +%FREE. Make lvresize -l+%FREE support approximate allocation. Move existing "Reducing/Extending' message to verbose level and change it to say 'up to' if approximate allocation is being used. Replace it with a new message that gives the actual old and new size or says 'unchanged'.
2014-08-01 03:35:43 +04:00
old_extents = lv->le_count;
log_verbose("%sing logical volume %s to %s%s",
(lp->resize == LV_REDUCE) ? "Reduc" : "Extend",
display_lvname(lv), lp->approx_alloc ? "up to " : "",
display_size(cmd, (uint64_t) lp->extents * vg->extent_size));
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
if (lp->resize == LV_REDUCE) {
if (!lv_reduce(lv, lv->le_count - lp->extents))
lvresize: return 0/1 Returning locking LV is no longer used from here, so return 1/0.
2016-06-17 12:29:28 +03:00
return_0;
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
} else if ((lp->extents > lv->le_count) && /* Ensure we extend */
!lv_extend(lv, lp->segtype,
lp->stripes, lp->stripe_size,
lp->mirrors, first_seg(lv)->region_size,
thin: simplify thin volume creation Move code for creation of thin volume into a single place out of lv_extend(). This allows to drop extra pool arg for alloc_lv_segment() && lv_extend() and makes code more easier to read and follow.
2014-10-26 10:13:59 +03:00
lp->extents - lv->le_count,
allocation: improve approx alloc with resize Start to convert percentage size handling in lvresize to the new standard. Note in the man pages that this code is incomplete. Fix a regression in non-percentage allocation in my last check in. This is what I am aiming for: -l<extents> -l<percent> LV/ORIGIN sets or changes the LV size based on the specified quantity of logical logical extents (that might be backed by a higher number of physical extents) -l<percent> PVS/VG/FREE sets or changes the LV size so as to allocate or free the desired quantity of physical extents (that might amount to a lower number of logical extents for the LV concerned) -l+50%FREE - Use up half the remaining free space in the VG when carrying out this operation. -l50%VG - After this operation, this LV should be using up half the space in the VG. -l200%LV - Double the logical size of this LV. -l+100%LV - Double the logical size of this LV. -l-50%LV - Reduce the logical size of this LV by half.
2014-02-25 02:48:23 +04:00
pvh, alloc, lp->approx_alloc))
lvresize: return 0/1 Returning locking LV is no longer used from here, so return 1/0.
2016-06-17 12:29:28 +03:00
return_0;
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
lvresize: Allow approximation with +%FREE. Make lvresize -l+%FREE support approximate allocation. Move existing "Reducing/Extending' message to verbose level and change it to say 'up to' if approximate allocation is being used. Replace it with a new message that gives the actual old and new size or says 'unchanged'.
2014-08-01 03:35:43 +04:00
if (old_extents == lv->le_count)
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
log_print_unless_silent("Size of logical volume %s unchanged from %s (%" PRIu32 " extents).",
lvresize: Allow approximation with +%FREE. Make lvresize -l+%FREE support approximate allocation. Move existing "Reducing/Extending' message to verbose level and change it to say 'up to' if approximate allocation is being used. Replace it with a new message that gives the actual old and new size or says 'unchanged'.
2014-08-01 03:35:43 +04:00
display_lvname(lv),
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
display_size(cmd, (uint64_t) old_extents * vg->extent_size), old_extents);
lvresize: fix zero size extension Commit ca878a3426197b629c76e98cfc049948da470cd7 changed behavior or resize operation. Later the code has been futher changed to skip fs resize completely when size of LV is already matching and finaly at the most recent resize changeset for resize the check for matching size has been eliminated as well so we ended with a request call to resize fs to 0 size in some cases. This commit reoders some test so the prompt happens just once before resize of possibly 2 related volumes. Also extra test for having LV already given size is added, and whole metadata update is skipped for this case as the only result would be an increment of seqno. However the filesystem is still resized when requested, so if the LV has some size and the resize is resolved to the same size, the filesystem resize is called so in case FS would not match, the resize will happen.
2016-07-13 17:23:25 +03:00
else {
lp->size_changed = 1;
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
log_print_unless_silent("Size of logical volume %s changed from %s (%" PRIu32 " extents) to %s (%" PRIu32 " extents).",
lvresize: Allow approximation with +%FREE. Make lvresize -l+%FREE support approximate allocation. Move existing "Reducing/Extending' message to verbose level and change it to say 'up to' if approximate allocation is being used. Replace it with a new message that gives the actual old and new size or says 'unchanged'.
2014-08-01 03:35:43 +04:00
display_lvname(lv),
lvresize: Fix raid/mirror and %PE handling code. Sort out the lvresize calculation code to handle size changes specified as physical extents as well as logical extents and to process mirror resizing and raid extensions correctly. The 'approx alloc' option was masking the underlying problem.
2014-08-22 04:26:14 +04:00
display_size(cmd, (uint64_t) old_extents * vg->extent_size), old_extents,
display_size(cmd, (uint64_t) lv->le_count * vg->extent_size), lv->le_count);
lvresize: fix zero size extension Commit ca878a3426197b629c76e98cfc049948da470cd7 changed behavior or resize operation. Later the code has been futher changed to skip fs resize completely when size of LV is already matching and finaly at the most recent resize changeset for resize the check for matching size has been eliminated as well so we ended with a request call to resize fs to 0 size in some cases. This commit reoders some test so the prompt happens just once before resize of possibly 2 related volumes. Also extra test for having LV already given size is added, and whole metadata update is skipped for this case as the only result would be an increment of seqno. However the filesystem is still resized when requested, so if the LV has some size and the resize is resolved to the same size, the filesystem resize is called so in case FS would not match, the resize will happen.
2016-07-13 17:23:25 +03:00
}
lvresize: Allow approximation with +%FREE. Make lvresize -l+%FREE support approximate allocation. Move existing "Reducing/Extending' message to verbose level and change it to say 'up to' if approximate allocation is being used. Replace it with a new message that gives the actual old and new size or says 'unchanged'.
2014-08-01 03:35:43 +04:00
lvresize: return 0/1 Returning locking LV is no longer used from here, so return 1/0.
2016-06-17 12:29:28 +03:00
return 1;
lvresize: separate validation from action Start separating the validation from the action in the basic lvresize code moved to the library. Remove incorrect use of command line error codes from lvresize library functions. Move errors.h to tools directory to reinforce this, exporting public versions of the error codes in lvm2cmd.h for dmeventd plugins to use.
2013-07-06 06:28:21 +04:00
}
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
static int _lv_resize_adjust_size(struct logical_volume *lv,
struct lvresize_params *lp,
int *matches_existing)
lvresize: separate validation from action Start separating the validation from the action in the basic lvresize code moved to the library. Remove incorrect use of command line error codes from lvresize library functions. Move errors.h to tools directory to reinforce this, exporting public versions of the error codes in lvm2cmd.h for dmeventd plugins to use.
2013-07-06 06:28:21 +04:00
{
lvresize: support more resized LVs Add code to support more LVs to be resized through a same code path using a single lvresize_params struct. (Now it's used for thin-pool metadata resize, next user will be snapshot virtual resize). Update code to adjust percent amount resize for use_policies. Properly activate inactive thin-pool in case of any pool resize as the command should not 'deffer' this operation to next activation.
2016-06-23 00:32:35 +03:00
/* Resolve extents from size */
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
if (lp->size) {
if (!_lvresize_adjust_size(lv->vg, lp->size, lp->sign, &lp->extents))
return_0;
}
/* set lp->extents based on lp->percent_value */
else if (lp->percent_value) {
if (!_lvresize_extents_from_percent(lv, lp))
return_0;
}
/* rewrites lp->extents from percentage to extents */
else if (lp->extents && (lp->percent != PERCENT_NONE)) {
if (!_lvresize_extents_from_percent(lv, lp))
return_0;
}
lvresize: separate validation from action Start separating the validation from the action in the basic lvresize code moved to the library. Remove incorrect use of command line error codes from lvresize library functions. Move errors.h to tools directory to reinforce this, exporting public versions of the error codes in lvm2cmd.h for dmeventd plugins to use.
2013-07-06 06:28:21 +04:00
lv_resize: support resizing of cached volumes Automatically figure out resizable layer in the LV stack and resize it online. Split check for reshaped raids and postpone removal of unused space after finished reshaping after metadata archiving. Drop warning about unsupported automatic resize of monitored thin-pool. Currently there is not yet support for resize of writecache.
2021-02-07 22:12:00 +03:00
/* Ensure stripe boundary extents! */
if (!lp->percent && lv_is_raid(lv))
lp->extents =_round_to_stripe_boundary(lv->vg, lp->extents,
seg_is_raid1(first_seg(lv)) ? 0 : _raid_stripes_count(first_seg(lv)),
lp->resize == LV_REDUCE ? 0 : 1);
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
if (!_lvresize_adjust_extents(lv, lp, matches_existing))
cleanup: indent
2014-05-23 16:25:12 +04:00
return_0;
thin: fix resize of stacked thin pool volume When the pool is created from non-linear target the more complex rules have to be used and stacking needs to properly decode args for _tdata LV. Also proper allocation policies are being used according to those set in lvm2 metadata for data and metadata LVs. Also properly check for active pool and extra code to active it temporarily. With this fix it's now possible to use: lvcreate -L20 -m2 -n pool vg --alloc anywhere lvcreate -L10 -m2 -n poolm vg --alloc anywhere lvconvert --thinpool vg/pool --poolmetadata vg/poolm lvresize -L+10 vg/pool
2013-09-06 12:54:50 +04:00
lvresize: separate validation from action Start separating the validation from the action in the basic lvresize code moved to the library. Remove incorrect use of command line error codes from lvresize library functions. Move errors.h to tools directory to reinforce this, exporting public versions of the error codes in lvm2cmd.h for dmeventd plugins to use.
2013-07-06 06:28:21 +04:00
return 1;
}
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
/* Set thin pool metadata properties, we can't use those from command line */
static void _setup_params_for_extend_metadata(struct logical_volume *lv,
struct lvresize_params *lp)
lvresize: support more resized LVs Add code to support more LVs to be resized through a same code path using a single lvresize_params struct. (Now it's used for thin-pool metadata resize, next user will be snapshot virtual resize). Update code to adjust percent amount resize for use_policies. Properly activate inactive thin-pool in case of any pool resize as the command should not 'deffer' this operation to next activation.
2016-06-23 00:32:35 +03:00
{
struct lv_segment *mseg = last_seg(lv);
lp->alloc = lv->alloc;
lvextend: fix resizing volumes of different segtype When resizing 2 volumes like thin-pool and it's metadata and they would be of a different type - command would be actually expecting both LVs being of a same segtype - and would throw an error in case they are different. This patch fixes is by setting a new segtype from last segment of 2nd. extented device. Also it fixes the possible 'percentage' extension setup that might have been used for 'primary' volume - while the 'secondary' LV always goes with direct size - as we do not support 'percentage' setup for them This affects maily usage of thin-pool where the extension of thin-pool data size may also lead to extension of metadata size.
2019-11-11 19:36:58 +03:00
lp->percent = PERCENT_NONE;
lp->segtype = mseg->segtype;
lvresize: support more resized LVs Add code to support more LVs to be resized through a same code path using a single lvresize_params struct. (Now it's used for thin-pool metadata resize, next user will be snapshot virtual resize). Update code to adjust percent amount resize for use_policies. Properly activate inactive thin-pool in case of any pool resize as the command should not 'deffer' this operation to next activation.
2016-06-23 00:32:35 +03:00
lp->mirrors = seg_is_mirrored(mseg) ? lv_mirror_count(lv) : 0;
lvresize: add new options and defaults for fs handling The new option "--fs String" for lvresize/lvreduce/lvextend controls the handling of file systems before/after resizing the LV. --resizefs is the same as --fs resize. The new option "--fsmode String" can be used to control mounting and unmounting of the fs during resizing. Possible --fs values: checksize Only applies to reducing size; does nothing for extend. Check the fs size and reduce the LV if the fs is not using the affected space, i.e. the fs does not need to be shrunk. Fail the command without reducing the fs or LV if the fs is using the affected space. resize Resize the fs using the fs-specific resize command. This may include mounting, unmounting, or running fsck. See --fsmode to control mounting behavior, and --nofsck to disable fsck. resize_fsadm Use the old method of calling fsadm to handle the fs (deprecated.) Warning: this option does not prevent lvreduce from destroying file systems that are unmounted (or mounted if prompts are skipped.) ignore Resize the LV without checking for or handling a file system. Warning: using ignore when reducing the LV size may destroy the file system. Possible --fsmode values: manage Mount or unmount the fs as needed to resize the fs, and attempt to restore the original mount state at the end. nochange Do not mount or unmount the fs. If mounting or unmounting is required to resize the fs, then do not resize the fs or the LV and fail the command. offline Unmount the fs if it is mounted, and resize the fs while it is unmounted. If mounting is required to resize the fs, then do not resize the fs or the LV and fail the command. Notes on lvreduce: When no --fs or --resizefs option is specified: . lvextend default behavior is fs ignore. . lvreduce default behavior is fs checksize (includes activating the LV.) With the exception of --fs resize_fsadm|ignore, lvreduce requires the recent libblkid fields FSLASTBLOCK and FSBLOCKSIZE. FSLASTBLOCK*FSBLOCKSIZE is the last byte used by the fs on the LV, which determines if reducing the fs is necessary.
2022-06-14 23:20:21 +03:00
lp->fsopt[0] = '\0';
lvresize: support more resized LVs Add code to support more LVs to be resized through a same code path using a single lvresize_params struct. (Now it's used for thin-pool metadata resize, next user will be snapshot virtual resize). Update code to adjust percent amount resize for use_policies. Properly activate inactive thin-pool in case of any pool resize as the command should not 'deffer' this operation to next activation.
2016-06-23 00:32:35 +03:00
lp->stripes = lp->mirrors ? mseg->area_count / lp->mirrors : 0;
lp->stripe_size = mseg->stripe_size;
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
}
lvresize: support more resized LVs Add code to support more LVs to be resized through a same code path using a single lvresize_params struct. (Now it's used for thin-pool metadata resize, next user will be snapshot virtual resize). Update code to adjust percent amount resize for use_policies. Properly activate inactive thin-pool in case of any pool resize as the command should not 'deffer' this operation to next activation.
2016-06-23 00:32:35 +03:00
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
static int _lv_resize_check_used(struct logical_volume *lv)
{
cov: validata top_lv Add explicit pointer check is never NULL.
2023-04-26 14:44:52 +03:00
if (!lv) {
log_error(INTERNAL_ERROR "LV is not specified.");
return 0;
}
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
if (lv_is_locked(lv)) {
log_error("Can't resize locked logical volume %s.", display_lvname(lv));
return 0;
}
if (lv_is_converting(lv)) {
log_error("Can't resize logical volume %s while lvconvert in progress.", display_lvname(lv));
return 0;
}
if (lv_component_is_active(lv)) {
log_error("Cannot resize logical volume %s with active component LV(s).", display_lvname(lv));
return 0;
}
if (lv_is_raid_with_tracking(lv)) {
log_error("Cannot resize logical volume %s while it is tracking a split image.", display_lvname(lv));
return 0;
}
vdo: resize requires active vdopool volume ATM kernel VDO target does not handle resize of inactive VDO LVs so prevent users corrupting such LVs and require active such LVs.
2023-01-15 23:27:57 +03:00
if (lv_is_vdo(lv) && !lv_is_active(lv)) {
log_error("Cannot resize inactive VDO logical volume %s.", display_lvname(lv));
return 0;
}
if (lv_is_vdo_pool(lv) && !lv_is_active(lv_lock_holder(lv))) {
log_error("Cannot resize inactive VDO POOL volume %s.", display_lvname(lv));
return 0;
}
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
if (lv_is_external_origin(lv)) {
/*
* Since external-origin can be activated read-only,
* there is no way to use extended areas.
*/
log_error("Cannot resize external origin logical volume %s.",
display_lvname(lv));
return 0;
}
return 1;
lvresize: support more resized LVs Add code to support more LVs to be resized through a same code path using a single lvresize_params struct. (Now it's used for thin-pool metadata resize, next user will be snapshot virtual resize). Update code to adjust percent amount resize for use_policies. Properly activate inactive thin-pool in case of any pool resize as the command should not 'deffer' this operation to next activation.
2016-06-23 00:32:35 +03:00
}
lvresize: add new options and defaults for fs handling The new option "--fs String" for lvresize/lvreduce/lvextend controls the handling of file systems before/after resizing the LV. --resizefs is the same as --fs resize. The new option "--fsmode String" can be used to control mounting and unmounting of the fs during resizing. Possible --fs values: checksize Only applies to reducing size; does nothing for extend. Check the fs size and reduce the LV if the fs is not using the affected space, i.e. the fs does not need to be shrunk. Fail the command without reducing the fs or LV if the fs is using the affected space. resize Resize the fs using the fs-specific resize command. This may include mounting, unmounting, or running fsck. See --fsmode to control mounting behavior, and --nofsck to disable fsck. resize_fsadm Use the old method of calling fsadm to handle the fs (deprecated.) Warning: this option does not prevent lvreduce from destroying file systems that are unmounted (or mounted if prompts are skipped.) ignore Resize the LV without checking for or handling a file system. Warning: using ignore when reducing the LV size may destroy the file system. Possible --fsmode values: manage Mount or unmount the fs as needed to resize the fs, and attempt to restore the original mount state at the end. nochange Do not mount or unmount the fs. If mounting or unmounting is required to resize the fs, then do not resize the fs or the LV and fail the command. offline Unmount the fs if it is mounted, and resize the fs while it is unmounted. If mounting is required to resize the fs, then do not resize the fs or the LV and fail the command. Notes on lvreduce: When no --fs or --resizefs option is specified: . lvextend default behavior is fs ignore. . lvreduce default behavior is fs checksize (includes activating the LV.) With the exception of --fs resize_fsadm|ignore, lvreduce requires the recent libblkid fields FSLASTBLOCK and FSBLOCKSIZE. FSLASTBLOCK*FSBLOCKSIZE is the last byte used by the fs on the LV, which determines if reducing the fs is necessary.
2022-06-14 23:20:21 +03:00
/*
* --fs checksize: check fs size and allow the lv to reduce if the fs is not
* using the affected space, i.e. the fs does not need to be
* resized. fail the command without reducing the fs or lv if
* the fs is using the affected space.
*
* --fs resize --fsmode manage: resize the fs, mounting/unmounting the fs
* as needed, but avoiding mounting/unmounted when possible.
*
* --fs resize --fsmode nochange: resize the fs without changing the current
* mount/unmount state. fail the command without reducing the
* fs or lv if the fs resize would require mounting or unmounting.
*
* --fs resize --fsmode offline: resize the fs only while it's unmounted
* unmounting the fs if needed. fail the commandn without
* reducing the fs or lv if the fs resize would require having
* the fs mounted.
*
* --fs resize_fsadm: old method using fsadm script to do everything
*/
static int _fs_reduce_allow(struct cmd_context *cmd, struct logical_volume *lv,
struct lvresize_params *lp, uint64_t newsize_bytes_lv,
uint64_t newsize_bytes_fs, struct fs_info *fsi)
{
const char *fs_reduce_cmd = "";
const char *cmp_desc = "";
int equal = 0, smaller = 0, larger = 0;
int is_ext_fstype = 0;
int confirm_mount_change = 0;
/*
* Allow reducing the LV for other fs types if the fs is not using
* space that's being reduced.
*/
if (!strcmp(fsi->fstype, "ext2") ||
!strcmp(fsi->fstype, "ext3") ||
!strcmp(fsi->fstype, "ext4") ||
!strcmp(fsi->fstype, "xfs")) {
log_debug("Found fs %s last_byte %llu newsize_bytes_fs %llu",
fsi->fstype,
(unsigned long long)fsi->fs_last_byte,
(unsigned long long)newsize_bytes_fs);
if (!strncmp(fsi->fstype, "ext", 3)) {
is_ext_fstype = 1;
fs_reduce_cmd = " resize2fs";
}
}
if (!fsi->mounted)
cleanup: correcting some log_print Correcting to log_print_unless_silent(), so -qq can do some work.
2023-04-26 15:40:11 +03:00
log_print_unless_silent("File system %s%s found on %s.",
fsi->fstype, fsi->needs_crypt ? "+crypto_LUKS" : "",
display_lvname(lv));
lvresize: add new options and defaults for fs handling The new option "--fs String" for lvresize/lvreduce/lvextend controls the handling of file systems before/after resizing the LV. --resizefs is the same as --fs resize. The new option "--fsmode String" can be used to control mounting and unmounting of the fs during resizing. Possible --fs values: checksize Only applies to reducing size; does nothing for extend. Check the fs size and reduce the LV if the fs is not using the affected space, i.e. the fs does not need to be shrunk. Fail the command without reducing the fs or LV if the fs is using the affected space. resize Resize the fs using the fs-specific resize command. This may include mounting, unmounting, or running fsck. See --fsmode to control mounting behavior, and --nofsck to disable fsck. resize_fsadm Use the old method of calling fsadm to handle the fs (deprecated.) Warning: this option does not prevent lvreduce from destroying file systems that are unmounted (or mounted if prompts are skipped.) ignore Resize the LV without checking for or handling a file system. Warning: using ignore when reducing the LV size may destroy the file system. Possible --fsmode values: manage Mount or unmount the fs as needed to resize the fs, and attempt to restore the original mount state at the end. nochange Do not mount or unmount the fs. If mounting or unmounting is required to resize the fs, then do not resize the fs or the LV and fail the command. offline Unmount the fs if it is mounted, and resize the fs while it is unmounted. If mounting is required to resize the fs, then do not resize the fs or the LV and fail the command. Notes on lvreduce: When no --fs or --resizefs option is specified: . lvextend default behavior is fs ignore. . lvreduce default behavior is fs checksize (includes activating the LV.) With the exception of --fs resize_fsadm|ignore, lvreduce requires the recent libblkid fields FSLASTBLOCK and FSBLOCKSIZE. FSLASTBLOCK*FSBLOCKSIZE is the last byte used by the fs on the LV, which determines if reducing the fs is necessary.
2022-06-14 23:20:21 +03:00
else
cleanup: correcting some log_print Correcting to log_print_unless_silent(), so -qq can do some work.
2023-04-26 15:40:11 +03:00
log_print_unless_silent("File system %s%s found on %s mounted at %s.",
fsi->fstype, fsi->needs_crypt ? "+crypto_LUKS" : "",
display_lvname(lv), fsi->mount_dir);
lvresize: add new options and defaults for fs handling The new option "--fs String" for lvresize/lvreduce/lvextend controls the handling of file systems before/after resizing the LV. --resizefs is the same as --fs resize. The new option "--fsmode String" can be used to control mounting and unmounting of the fs during resizing. Possible --fs values: checksize Only applies to reducing size; does nothing for extend. Check the fs size and reduce the LV if the fs is not using the affected space, i.e. the fs does not need to be shrunk. Fail the command without reducing the fs or LV if the fs is using the affected space. resize Resize the fs using the fs-specific resize command. This may include mounting, unmounting, or running fsck. See --fsmode to control mounting behavior, and --nofsck to disable fsck. resize_fsadm Use the old method of calling fsadm to handle the fs (deprecated.) Warning: this option does not prevent lvreduce from destroying file systems that are unmounted (or mounted if prompts are skipped.) ignore Resize the LV without checking for or handling a file system. Warning: using ignore when reducing the LV size may destroy the file system. Possible --fsmode values: manage Mount or unmount the fs as needed to resize the fs, and attempt to restore the original mount state at the end. nochange Do not mount or unmount the fs. If mounting or unmounting is required to resize the fs, then do not resize the fs or the LV and fail the command. offline Unmount the fs if it is mounted, and resize the fs while it is unmounted. If mounting is required to resize the fs, then do not resize the fs or the LV and fail the command. Notes on lvreduce: When no --fs or --resizefs option is specified: . lvextend default behavior is fs ignore. . lvreduce default behavior is fs checksize (includes activating the LV.) With the exception of --fs resize_fsadm|ignore, lvreduce requires the recent libblkid fields FSLASTBLOCK and FSBLOCKSIZE. FSLASTBLOCK*FSBLOCKSIZE is the last byte used by the fs on the LV, which determines if reducing the fs is necessary.
2022-06-14 23:20:21 +03:00
if (!fsi->fs_last_byte) {
lvresize: give special advice to reiserfs users
2022-09-28 19:52:40 +03:00
if (!strcmp(fsi->fstype, "reiserfs")) {
log_error("File system reduce for reiserfs requires --fs resize_fsadm.");
return 0;
}
log_error("File system device usage is not available from libblkid.");
lvresize: add new options and defaults for fs handling The new option "--fs String" for lvresize/lvreduce/lvextend controls the handling of file systems before/after resizing the LV. --resizefs is the same as --fs resize. The new option "--fsmode String" can be used to control mounting and unmounting of the fs during resizing. Possible --fs values: checksize Only applies to reducing size; does nothing for extend. Check the fs size and reduce the LV if the fs is not using the affected space, i.e. the fs does not need to be shrunk. Fail the command without reducing the fs or LV if the fs is using the affected space. resize Resize the fs using the fs-specific resize command. This may include mounting, unmounting, or running fsck. See --fsmode to control mounting behavior, and --nofsck to disable fsck. resize_fsadm Use the old method of calling fsadm to handle the fs (deprecated.) Warning: this option does not prevent lvreduce from destroying file systems that are unmounted (or mounted if prompts are skipped.) ignore Resize the LV without checking for or handling a file system. Warning: using ignore when reducing the LV size may destroy the file system. Possible --fsmode values: manage Mount or unmount the fs as needed to resize the fs, and attempt to restore the original mount state at the end. nochange Do not mount or unmount the fs. If mounting or unmounting is required to resize the fs, then do not resize the fs or the LV and fail the command. offline Unmount the fs if it is mounted, and resize the fs while it is unmounted. If mounting is required to resize the fs, then do not resize the fs or the LV and fail the command. Notes on lvreduce: When no --fs or --resizefs option is specified: . lvextend default behavior is fs ignore. . lvreduce default behavior is fs checksize (includes activating the LV.) With the exception of --fs resize_fsadm|ignore, lvreduce requires the recent libblkid fields FSLASTBLOCK and FSBLOCKSIZE. FSLASTBLOCK*FSBLOCKSIZE is the last byte used by the fs on the LV, which determines if reducing the fs is necessary.
2022-06-14 23:20:21 +03:00
return 0;
}
if ((equal = (fsi->fs_last_byte == newsize_bytes_fs)))
cmp_desc = "equal to";
else if ((smaller = (fsi->fs_last_byte < newsize_bytes_fs)))
cmp_desc = "smaller than";
else if ((larger = (fsi->fs_last_byte > newsize_bytes_fs)))
cmp_desc = "larger than";
cleanup: correcting some log_print Correcting to log_print_unless_silent(), so -qq can do some work.
2023-04-26 15:40:11 +03:00
log_print_unless_silent("File system size (%s) is %s the requested size (%s).",
display_size(cmd, fsi->fs_last_byte/512), cmp_desc,
display_size(cmd, newsize_bytes_fs/512));
lvresize: add new options and defaults for fs handling The new option "--fs String" for lvresize/lvreduce/lvextend controls the handling of file systems before/after resizing the LV. --resizefs is the same as --fs resize. The new option "--fsmode String" can be used to control mounting and unmounting of the fs during resizing. Possible --fs values: checksize Only applies to reducing size; does nothing for extend. Check the fs size and reduce the LV if the fs is not using the affected space, i.e. the fs does not need to be shrunk. Fail the command without reducing the fs or LV if the fs is using the affected space. resize Resize the fs using the fs-specific resize command. This may include mounting, unmounting, or running fsck. See --fsmode to control mounting behavior, and --nofsck to disable fsck. resize_fsadm Use the old method of calling fsadm to handle the fs (deprecated.) Warning: this option does not prevent lvreduce from destroying file systems that are unmounted (or mounted if prompts are skipped.) ignore Resize the LV without checking for or handling a file system. Warning: using ignore when reducing the LV size may destroy the file system. Possible --fsmode values: manage Mount or unmount the fs as needed to resize the fs, and attempt to restore the original mount state at the end. nochange Do not mount or unmount the fs. If mounting or unmounting is required to resize the fs, then do not resize the fs or the LV and fail the command. offline Unmount the fs if it is mounted, and resize the fs while it is unmounted. If mounting is required to resize the fs, then do not resize the fs or the LV and fail the command. Notes on lvreduce: When no --fs or --resizefs option is specified: . lvextend default behavior is fs ignore. . lvreduce default behavior is fs checksize (includes activating the LV.) With the exception of --fs resize_fsadm|ignore, lvreduce requires the recent libblkid fields FSLASTBLOCK and FSBLOCKSIZE. FSLASTBLOCK*FSBLOCKSIZE is the last byte used by the fs on the LV, which determines if reducing the fs is necessary.
2022-06-14 23:20:21 +03:00
/*
* FS reduce is not needed, it's not using the affected space.
*/
if (smaller || equal) {
cleanup: correcting some log_print Correcting to log_print_unless_silent(), so -qq can do some work.
2023-04-26 15:40:11 +03:00
log_print_unless_silent("File system reduce is not needed, skipping.");
lvresize: add new options and defaults for fs handling The new option "--fs String" for lvresize/lvreduce/lvextend controls the handling of file systems before/after resizing the LV. --resizefs is the same as --fs resize. The new option "--fsmode String" can be used to control mounting and unmounting of the fs during resizing. Possible --fs values: checksize Only applies to reducing size; does nothing for extend. Check the fs size and reduce the LV if the fs is not using the affected space, i.e. the fs does not need to be shrunk. Fail the command without reducing the fs or LV if the fs is using the affected space. resize Resize the fs using the fs-specific resize command. This may include mounting, unmounting, or running fsck. See --fsmode to control mounting behavior, and --nofsck to disable fsck. resize_fsadm Use the old method of calling fsadm to handle the fs (deprecated.) Warning: this option does not prevent lvreduce from destroying file systems that are unmounted (or mounted if prompts are skipped.) ignore Resize the LV without checking for or handling a file system. Warning: using ignore when reducing the LV size may destroy the file system. Possible --fsmode values: manage Mount or unmount the fs as needed to resize the fs, and attempt to restore the original mount state at the end. nochange Do not mount or unmount the fs. If mounting or unmounting is required to resize the fs, then do not resize the fs or the LV and fail the command. offline Unmount the fs if it is mounted, and resize the fs while it is unmounted. If mounting is required to resize the fs, then do not resize the fs or the LV and fail the command. Notes on lvreduce: When no --fs or --resizefs option is specified: . lvextend default behavior is fs ignore. . lvreduce default behavior is fs checksize (includes activating the LV.) With the exception of --fs resize_fsadm|ignore, lvreduce requires the recent libblkid fields FSLASTBLOCK and FSBLOCKSIZE. FSLASTBLOCK*FSBLOCKSIZE is the last byte used by the fs on the LV, which determines if reducing the fs is necessary.
2022-06-14 23:20:21 +03:00
fsi->needs_reduce = 0;
return 1;
}
/*
* FS reduce is required, but checksize does not allow it.
*/
if (!strcmp(lp->fsopt, "checksize")) {
if (is_ext_fstype)
log_error("File system reduce is required (see resize2fs or --resizefs.)");
else
log_error("File system reduce is required and not supported (%s).", fsi->fstype);
return 0;
}
/*
* FS reduce required, ext* supports it, xfs does not.
*/
if (is_ext_fstype) {
cleanup: correcting some log_print Correcting to log_print_unless_silent(), so -qq can do some work.
2023-04-26 15:40:11 +03:00
log_print_unless_silent("File system reduce is required using resize2fs.");
lvresize: give special advice to reiserfs users
2022-09-28 19:52:40 +03:00
} else if (!strcmp(fsi->fstype, "reiserfs")) {
log_error("File system reduce for reiserfs requires --fs resize_fsadm.");
return 0;
lvresize: add new options and defaults for fs handling The new option "--fs String" for lvresize/lvreduce/lvextend controls the handling of file systems before/after resizing the LV. --resizefs is the same as --fs resize. The new option "--fsmode String" can be used to control mounting and unmounting of the fs during resizing. Possible --fs values: checksize Only applies to reducing size; does nothing for extend. Check the fs size and reduce the LV if the fs is not using the affected space, i.e. the fs does not need to be shrunk. Fail the command without reducing the fs or LV if the fs is using the affected space. resize Resize the fs using the fs-specific resize command. This may include mounting, unmounting, or running fsck. See --fsmode to control mounting behavior, and --nofsck to disable fsck. resize_fsadm Use the old method of calling fsadm to handle the fs (deprecated.) Warning: this option does not prevent lvreduce from destroying file systems that are unmounted (or mounted if prompts are skipped.) ignore Resize the LV without checking for or handling a file system. Warning: using ignore when reducing the LV size may destroy the file system. Possible --fsmode values: manage Mount or unmount the fs as needed to resize the fs, and attempt to restore the original mount state at the end. nochange Do not mount or unmount the fs. If mounting or unmounting is required to resize the fs, then do not resize the fs or the LV and fail the command. offline Unmount the fs if it is mounted, and resize the fs while it is unmounted. If mounting is required to resize the fs, then do not resize the fs or the LV and fail the command. Notes on lvreduce: When no --fs or --resizefs option is specified: . lvextend default behavior is fs ignore. . lvreduce default behavior is fs checksize (includes activating the LV.) With the exception of --fs resize_fsadm|ignore, lvreduce requires the recent libblkid fields FSLASTBLOCK and FSBLOCKSIZE. FSLASTBLOCK*FSBLOCKSIZE is the last byte used by the fs on the LV, which determines if reducing the fs is necessary.
2022-06-14 23:20:21 +03:00
} else {
log_error("File system reduce is required and not supported (%s).", fsi->fstype);
return 0;
}
/*
* Set fstype-specific requirements for running fs resize command.
* ext2,3,4 require the fs to be unmounted to shrink with resize2fs,
* and they require e2fsck to be run first, unless resize2fs -f is used.
*/
if (is_ext_fstype) {
/* it's traditional to run fsck before shrink */
if (!lp->nofsck)
fsi->needs_fsck = 1;
/* ext2,3,4 require fs to be unmounted to shrink */
if (fsi->mounted)
fsi->needs_unmount = 1;
fsi->needs_reduce = 1;
} else {
/*
* Shouldn't reach here since no other fs types get this far.
* A future fs supporting shrink may require the fs to be
* mounted or unmounted to run the fs shrink command.
* set fsi->needs_unmount or fs->needs_mount according to
* the fs-specific shrink command's requirement.
*/
log_error("File system %s: fs reduce not implemented.", fsi->fstype);
return 0;
}
/*
* FS reduce may require mounting or unmounting, check the fsopt value
* from the user, and the current mount state to decide if fs resize
* can be done.
*/
if (!strcmp(lp->fsopt, "resize") && !strcmp(lp->fsmode, "nochange")) {
/* can't mount|unmount to run fs resize */
if (fsi->needs_mount) {
log_error("File system needs to be mounted to reduce fs (see --fsmode).");
return 0;
}
if (fsi->needs_unmount) {
log_error("File system needs to be unmounted to reduce fs (see --fsmode).");
return 0;
}
} else if (!strcmp(lp->fsopt, "resize") && !strcmp(lp->fsmode, "offline")) {
/* we can unmount if needed to run fs resize */
if (fsi->needs_mount) {
log_error("File system needs to be mounted to reduce fs (see --fsmode).");
return 0;
}
} else if (!strcmp(lp->fsopt, "resize") && !strcmp(lp->fsmode, "manage")) {
/* we can mount|unmount as needed to run fs resize */
/* confirm mount change unless --fsmode manage is set explicitly */
if (fsi->needs_mount || fsi->needs_unmount)
confirm_mount_change = 1;
if (lp->user_set_fsmode)
confirm_mount_change = 0;
} else {
log_error("Unknown file system resize options: --fs %s --fsmode %s", lp->fsopt, lp->fsmode);
return 0;
}
/*
* If future file systems can be reduced while mounted, then suppress
* needs_fsck here if the fs is already mounted.
*/
if (fsi->needs_unmount)
cleanup: correcting some log_print Correcting to log_print_unless_silent(), so -qq can do some work.
2023-04-26 15:40:11 +03:00
log_print_unless_silent("File system unmount is needed for reduce.");
lvresize: add new options and defaults for fs handling The new option "--fs String" for lvresize/lvreduce/lvextend controls the handling of file systems before/after resizing the LV. --resizefs is the same as --fs resize. The new option "--fsmode String" can be used to control mounting and unmounting of the fs during resizing. Possible --fs values: checksize Only applies to reducing size; does nothing for extend. Check the fs size and reduce the LV if the fs is not using the affected space, i.e. the fs does not need to be shrunk. Fail the command without reducing the fs or LV if the fs is using the affected space. resize Resize the fs using the fs-specific resize command. This may include mounting, unmounting, or running fsck. See --fsmode to control mounting behavior, and --nofsck to disable fsck. resize_fsadm Use the old method of calling fsadm to handle the fs (deprecated.) Warning: this option does not prevent lvreduce from destroying file systems that are unmounted (or mounted if prompts are skipped.) ignore Resize the LV without checking for or handling a file system. Warning: using ignore when reducing the LV size may destroy the file system. Possible --fsmode values: manage Mount or unmount the fs as needed to resize the fs, and attempt to restore the original mount state at the end. nochange Do not mount or unmount the fs. If mounting or unmounting is required to resize the fs, then do not resize the fs or the LV and fail the command. offline Unmount the fs if it is mounted, and resize the fs while it is unmounted. If mounting is required to resize the fs, then do not resize the fs or the LV and fail the command. Notes on lvreduce: When no --fs or --resizefs option is specified: . lvextend default behavior is fs ignore. . lvreduce default behavior is fs checksize (includes activating the LV.) With the exception of --fs resize_fsadm|ignore, lvreduce requires the recent libblkid fields FSLASTBLOCK and FSBLOCKSIZE. FSLASTBLOCK*FSBLOCKSIZE is the last byte used by the fs on the LV, which determines if reducing the fs is necessary.
2022-06-14 23:20:21 +03:00
if (fsi->needs_fsck)
cleanup: correcting some log_print Correcting to log_print_unless_silent(), so -qq can do some work.
2023-04-26 15:40:11 +03:00
log_print_unless_silent("File system fsck will be run before reduce.");
lvresize: add new options and defaults for fs handling The new option "--fs String" for lvresize/lvreduce/lvextend controls the handling of file systems before/after resizing the LV. --resizefs is the same as --fs resize. The new option "--fsmode String" can be used to control mounting and unmounting of the fs during resizing. Possible --fs values: checksize Only applies to reducing size; does nothing for extend. Check the fs size and reduce the LV if the fs is not using the affected space, i.e. the fs does not need to be shrunk. Fail the command without reducing the fs or LV if the fs is using the affected space. resize Resize the fs using the fs-specific resize command. This may include mounting, unmounting, or running fsck. See --fsmode to control mounting behavior, and --nofsck to disable fsck. resize_fsadm Use the old method of calling fsadm to handle the fs (deprecated.) Warning: this option does not prevent lvreduce from destroying file systems that are unmounted (or mounted if prompts are skipped.) ignore Resize the LV without checking for or handling a file system. Warning: using ignore when reducing the LV size may destroy the file system. Possible --fsmode values: manage Mount or unmount the fs as needed to resize the fs, and attempt to restore the original mount state at the end. nochange Do not mount or unmount the fs. If mounting or unmounting is required to resize the fs, then do not resize the fs or the LV and fail the command. offline Unmount the fs if it is mounted, and resize the fs while it is unmounted. If mounting is required to resize the fs, then do not resize the fs or the LV and fail the command. Notes on lvreduce: When no --fs or --resizefs option is specified: . lvextend default behavior is fs ignore. . lvreduce default behavior is fs checksize (includes activating the LV.) With the exception of --fs resize_fsadm|ignore, lvreduce requires the recent libblkid fields FSLASTBLOCK and FSBLOCKSIZE. FSLASTBLOCK*FSBLOCKSIZE is the last byte used by the fs on the LV, which determines if reducing the fs is necessary.
2022-06-14 23:20:21 +03:00
if (fsi->needs_mount)
cleanup: correcting some log_print Correcting to log_print_unless_silent(), so -qq can do some work.
2023-04-26 15:40:11 +03:00
log_print_unless_silent("File system mount is needed for reduce.");
lvresize: add new options and defaults for fs handling The new option "--fs String" for lvresize/lvreduce/lvextend controls the handling of file systems before/after resizing the LV. --resizefs is the same as --fs resize. The new option "--fsmode String" can be used to control mounting and unmounting of the fs during resizing. Possible --fs values: checksize Only applies to reducing size; does nothing for extend. Check the fs size and reduce the LV if the fs is not using the affected space, i.e. the fs does not need to be shrunk. Fail the command without reducing the fs or LV if the fs is using the affected space. resize Resize the fs using the fs-specific resize command. This may include mounting, unmounting, or running fsck. See --fsmode to control mounting behavior, and --nofsck to disable fsck. resize_fsadm Use the old method of calling fsadm to handle the fs (deprecated.) Warning: this option does not prevent lvreduce from destroying file systems that are unmounted (or mounted if prompts are skipped.) ignore Resize the LV without checking for or handling a file system. Warning: using ignore when reducing the LV size may destroy the file system. Possible --fsmode values: manage Mount or unmount the fs as needed to resize the fs, and attempt to restore the original mount state at the end. nochange Do not mount or unmount the fs. If mounting or unmounting is required to resize the fs, then do not resize the fs or the LV and fail the command. offline Unmount the fs if it is mounted, and resize the fs while it is unmounted. If mounting is required to resize the fs, then do not resize the fs or the LV and fail the command. Notes on lvreduce: When no --fs or --resizefs option is specified: . lvextend default behavior is fs ignore. . lvreduce default behavior is fs checksize (includes activating the LV.) With the exception of --fs resize_fsadm|ignore, lvreduce requires the recent libblkid fields FSLASTBLOCK and FSBLOCKSIZE. FSLASTBLOCK*FSBLOCKSIZE is the last byte used by the fs on the LV, which determines if reducing the fs is necessary.
2022-06-14 23:20:21 +03:00
if (fsi->needs_crypt)
cleanup: correcting some log_print Correcting to log_print_unless_silent(), so -qq can do some work.
2023-04-26 15:40:11 +03:00
log_print_unless_silent("cryptsetup resize is needed for reduce.");
lvresize: add new options and defaults for fs handling The new option "--fs String" for lvresize/lvreduce/lvextend controls the handling of file systems before/after resizing the LV. --resizefs is the same as --fs resize. The new option "--fsmode String" can be used to control mounting and unmounting of the fs during resizing. Possible --fs values: checksize Only applies to reducing size; does nothing for extend. Check the fs size and reduce the LV if the fs is not using the affected space, i.e. the fs does not need to be shrunk. Fail the command without reducing the fs or LV if the fs is using the affected space. resize Resize the fs using the fs-specific resize command. This may include mounting, unmounting, or running fsck. See --fsmode to control mounting behavior, and --nofsck to disable fsck. resize_fsadm Use the old method of calling fsadm to handle the fs (deprecated.) Warning: this option does not prevent lvreduce from destroying file systems that are unmounted (or mounted if prompts are skipped.) ignore Resize the LV without checking for or handling a file system. Warning: using ignore when reducing the LV size may destroy the file system. Possible --fsmode values: manage Mount or unmount the fs as needed to resize the fs, and attempt to restore the original mount state at the end. nochange Do not mount or unmount the fs. If mounting or unmounting is required to resize the fs, then do not resize the fs or the LV and fail the command. offline Unmount the fs if it is mounted, and resize the fs while it is unmounted. If mounting is required to resize the fs, then do not resize the fs or the LV and fail the command. Notes on lvreduce: When no --fs or --resizefs option is specified: . lvextend default behavior is fs ignore. . lvreduce default behavior is fs checksize (includes activating the LV.) With the exception of --fs resize_fsadm|ignore, lvreduce requires the recent libblkid fields FSLASTBLOCK and FSBLOCKSIZE. FSLASTBLOCK*FSBLOCKSIZE is the last byte used by the fs on the LV, which determines if reducing the fs is necessary.
2022-06-14 23:20:21 +03:00
/*
* Use a confirmation prompt because mount|unmount is needed, and
* no specific --fsmode was set (i.e. the user did not give specific
* direction about how to handle mounting|unmounting with --fsmode.)
*/
if (!lp->yes && confirm_mount_change) {
if (yes_no_prompt("Continue with %s file system reduce steps:%s%s%s%s%s? [y/n]:",
fsi->fstype,
fsi->needs_unmount ? " unmount," : "",
fsi->needs_fsck ? " fsck," : "",
fsi->needs_mount ? " mount," : "",
fsi->needs_crypt ? " cryptsetup," : "",
fsi->needs_reduce ? fs_reduce_cmd : "") == 'n') {
log_error("File system not reduced.");
return 0;
}
}
return 1;
}
static int _fs_extend_allow(struct cmd_context *cmd, struct logical_volume *lv,
struct lvresize_params *lp, struct fs_info *fsi)
{
const char *fs_extend_cmd = "";
int is_ext_fstype = 0;
int confirm_mount_change = 0;
if (!strcmp(fsi->fstype, "ext2") ||
!strcmp(fsi->fstype, "ext3") ||
!strcmp(fsi->fstype, "ext4") ||
!strcmp(fsi->fstype, "xfs")) {
log_debug("Found fs %s last_byte %llu",
fsi->fstype, (unsigned long long)fsi->fs_last_byte);
if (!strncmp(fsi->fstype, "ext", 3))
is_ext_fstype = 1;
lvresize: give special advice to reiserfs users
2022-09-28 19:52:40 +03:00
} else if (!strcmp(fsi->fstype, "reiserfs")) {
log_error("File system extend for reiserfs requires --fs resize_fsadm.");
return 0;
lvresize: add new options and defaults for fs handling The new option "--fs String" for lvresize/lvreduce/lvextend controls the handling of file systems before/after resizing the LV. --resizefs is the same as --fs resize. The new option "--fsmode String" can be used to control mounting and unmounting of the fs during resizing. Possible --fs values: checksize Only applies to reducing size; does nothing for extend. Check the fs size and reduce the LV if the fs is not using the affected space, i.e. the fs does not need to be shrunk. Fail the command without reducing the fs or LV if the fs is using the affected space. resize Resize the fs using the fs-specific resize command. This may include mounting, unmounting, or running fsck. See --fsmode to control mounting behavior, and --nofsck to disable fsck. resize_fsadm Use the old method of calling fsadm to handle the fs (deprecated.) Warning: this option does not prevent lvreduce from destroying file systems that are unmounted (or mounted if prompts are skipped.) ignore Resize the LV without checking for or handling a file system. Warning: using ignore when reducing the LV size may destroy the file system. Possible --fsmode values: manage Mount or unmount the fs as needed to resize the fs, and attempt to restore the original mount state at the end. nochange Do not mount or unmount the fs. If mounting or unmounting is required to resize the fs, then do not resize the fs or the LV and fail the command. offline Unmount the fs if it is mounted, and resize the fs while it is unmounted. If mounting is required to resize the fs, then do not resize the fs or the LV and fail the command. Notes on lvreduce: When no --fs or --resizefs option is specified: . lvextend default behavior is fs ignore. . lvreduce default behavior is fs checksize (includes activating the LV.) With the exception of --fs resize_fsadm|ignore, lvreduce requires the recent libblkid fields FSLASTBLOCK and FSBLOCKSIZE. FSLASTBLOCK*FSBLOCKSIZE is the last byte used by the fs on the LV, which determines if reducing the fs is necessary.
2022-06-14 23:20:21 +03:00
} else {
log_error("File system extend is not supported (%s).", fsi->fstype);
return 0;
}
if (!fsi->mounted)
cleanup: correcting some log_print Correcting to log_print_unless_silent(), so -qq can do some work.
2023-04-26 15:40:11 +03:00
log_print_unless_silent("File system %s%s found on %s.",
fsi->fstype, fsi->needs_crypt ? "+crypto_LUKS" : "",
display_lvname(lv));
lvresize: add new options and defaults for fs handling The new option "--fs String" for lvresize/lvreduce/lvextend controls the handling of file systems before/after resizing the LV. --resizefs is the same as --fs resize. The new option "--fsmode String" can be used to control mounting and unmounting of the fs during resizing. Possible --fs values: checksize Only applies to reducing size; does nothing for extend. Check the fs size and reduce the LV if the fs is not using the affected space, i.e. the fs does not need to be shrunk. Fail the command without reducing the fs or LV if the fs is using the affected space. resize Resize the fs using the fs-specific resize command. This may include mounting, unmounting, or running fsck. See --fsmode to control mounting behavior, and --nofsck to disable fsck. resize_fsadm Use the old method of calling fsadm to handle the fs (deprecated.) Warning: this option does not prevent lvreduce from destroying file systems that are unmounted (or mounted if prompts are skipped.) ignore Resize the LV without checking for or handling a file system. Warning: using ignore when reducing the LV size may destroy the file system. Possible --fsmode values: manage Mount or unmount the fs as needed to resize the fs, and attempt to restore the original mount state at the end. nochange Do not mount or unmount the fs. If mounting or unmounting is required to resize the fs, then do not resize the fs or the LV and fail the command. offline Unmount the fs if it is mounted, and resize the fs while it is unmounted. If mounting is required to resize the fs, then do not resize the fs or the LV and fail the command. Notes on lvreduce: When no --fs or --resizefs option is specified: . lvextend default behavior is fs ignore. . lvreduce default behavior is fs checksize (includes activating the LV.) With the exception of --fs resize_fsadm|ignore, lvreduce requires the recent libblkid fields FSLASTBLOCK and FSBLOCKSIZE. FSLASTBLOCK*FSBLOCKSIZE is the last byte used by the fs on the LV, which determines if reducing the fs is necessary.
2022-06-14 23:20:21 +03:00
else
cleanup: correcting some log_print Correcting to log_print_unless_silent(), so -qq can do some work.
2023-04-26 15:40:11 +03:00
log_print_unless_silent("File system %s%s found on %s mounted at %s.",
fsi->fstype, fsi->needs_crypt ? "+crypto_LUKS" : "",
display_lvname(lv), fsi->mount_dir);
lvresize: add new options and defaults for fs handling The new option "--fs String" for lvresize/lvreduce/lvextend controls the handling of file systems before/after resizing the LV. --resizefs is the same as --fs resize. The new option "--fsmode String" can be used to control mounting and unmounting of the fs during resizing. Possible --fs values: checksize Only applies to reducing size; does nothing for extend. Check the fs size and reduce the LV if the fs is not using the affected space, i.e. the fs does not need to be shrunk. Fail the command without reducing the fs or LV if the fs is using the affected space. resize Resize the fs using the fs-specific resize command. This may include mounting, unmounting, or running fsck. See --fsmode to control mounting behavior, and --nofsck to disable fsck. resize_fsadm Use the old method of calling fsadm to handle the fs (deprecated.) Warning: this option does not prevent lvreduce from destroying file systems that are unmounted (or mounted if prompts are skipped.) ignore Resize the LV without checking for or handling a file system. Warning: using ignore when reducing the LV size may destroy the file system. Possible --fsmode values: manage Mount or unmount the fs as needed to resize the fs, and attempt to restore the original mount state at the end. nochange Do not mount or unmount the fs. If mounting or unmounting is required to resize the fs, then do not resize the fs or the LV and fail the command. offline Unmount the fs if it is mounted, and resize the fs while it is unmounted. If mounting is required to resize the fs, then do not resize the fs or the LV and fail the command. Notes on lvreduce: When no --fs or --resizefs option is specified: . lvextend default behavior is fs ignore. . lvreduce default behavior is fs checksize (includes activating the LV.) With the exception of --fs resize_fsadm|ignore, lvreduce requires the recent libblkid fields FSLASTBLOCK and FSBLOCKSIZE. FSLASTBLOCK*FSBLOCKSIZE is the last byte used by the fs on the LV, which determines if reducing the fs is necessary.
2022-06-14 23:20:21 +03:00
/*
* FS extend may require mounting or unmounting, check the fsopt value
* from the user, and the current mount state to decide if fs extend
* can be done.
*/
if (is_ext_fstype) {
fs_extend_cmd = " resize2fs";
/*
* ext* can be extended while it's mounted or unmounted. If
* the fs is unmounted, it's traditional to run fsck before
* running the fs extend.
*
* --fs resize --fsmode nochange: don't change mount condition.
* if mounted: fs_extend
* if unmounted: fsck, fs_extend
*
* --fs resize --fsmode offline: extend offline, so unmount first if mounted.
* if mounted: unmount, fsck, fs_extend
* if unmounted: fsck, fs_extend
*
* --fs resize --fsmode manage: do any mount or unmount that's necessary,
* avoiding unnecessary mounting/unmounting.
* if mounted: fs_extend
* if unmounted: fsck, fs_extend
*/
if (!strcmp(lp->fsopt, "resize") && !strcmp(lp->fsmode, "nochange")) {
if (fsi->mounted)
fsi->needs_extend = 1;
else if (fsi->unmounted) {
fsi->needs_fsck = 1;
fsi->needs_extend = 1;
}
} else if (!strcmp(lp->fsopt, "resize") && !strcmp(lp->fsmode, "offline")) {
if (fsi->mounted) {
fsi->needs_unmount = 1;
fsi->needs_fsck = 1;
fsi->needs_extend = 1;
} else if (fsi->unmounted) {
fsi->needs_fsck = 1;
fsi->needs_extend = 1;
}
} else if (!strcmp(lp->fsopt, "resize") && !strcmp(lp->fsmode, "manage")) {
if (fsi->mounted)
fsi->needs_extend = 1;
else if (fsi->unmounted) {
fsi->needs_fsck = 1;
fsi->needs_extend = 1;
}
}
if (lp->nofsck)
fsi->needs_fsck = 0;
} else if (!strcmp(fsi->fstype, "xfs")) {
fs_extend_cmd = " xfs_growfs";
/*
* xfs must be mounted to extend.
*
* --fs resize --fsmode nochange: don't change mount condition.
* if mounted: fs_extend
* if unmounted: fail
*
* --fs resize --fsmode offline: extend offline, so unmount first if mounted.
* if mounted: fail
* if unmounted: fail
*
* --fs resize --fsmode manage: do any mount or unmount that's necessary,
* avoiding unnecessary mounting/unmounting.
* if mounted: fs_extend
* if unmounted: mount, fs_extend
*/
if (!strcmp(lp->fsopt, "resize") && !strcmp(lp->fsmode, "nochange")) {
if (fsi->mounted)
fsi->needs_extend = 1;
else if (fsi->unmounted) {
log_error("File system must be mounted to extend (see --fsmode).");
return 0;
}
} else if (!strcmp(lp->fsopt, "resize") && !strcmp(lp->fsmode, "offline")) {
log_error("File system must be mounted to extend (see --fsmode).");
return 0;
} else if (!strcmp(lp->fsopt, "resize") && !strcmp(lp->fsmode, "manage")) {
if (fsi->mounted)
fsi->needs_extend = 1;
else if (fsi->unmounted) {
fsi->needs_mount = 1;
fsi->needs_extend = 1;
}
}
} else {
/* shouldn't reach here */
log_error("File system type %s not handled.", fsi->fstype);
return 0;
}
/*
* Skip needs_fsck if the fs is mounted and we can extend the fs while
* it's mounted.
*/
if (fsi->mounted && !fsi->needs_unmount && fsi->needs_fsck) {
cleanup: correcting some log_print Correcting to log_print_unless_silent(), so -qq can do some work.
2023-04-26 15:40:11 +03:00
log_print_unless_silent("File system fsck skipped for extending mounted fs.");
lvresize: add new options and defaults for fs handling The new option "--fs String" for lvresize/lvreduce/lvextend controls the handling of file systems before/after resizing the LV. --resizefs is the same as --fs resize. The new option "--fsmode String" can be used to control mounting and unmounting of the fs during resizing. Possible --fs values: checksize Only applies to reducing size; does nothing for extend. Check the fs size and reduce the LV if the fs is not using the affected space, i.e. the fs does not need to be shrunk. Fail the command without reducing the fs or LV if the fs is using the affected space. resize Resize the fs using the fs-specific resize command. This may include mounting, unmounting, or running fsck. See --fsmode to control mounting behavior, and --nofsck to disable fsck. resize_fsadm Use the old method of calling fsadm to handle the fs (deprecated.) Warning: this option does not prevent lvreduce from destroying file systems that are unmounted (or mounted if prompts are skipped.) ignore Resize the LV without checking for or handling a file system. Warning: using ignore when reducing the LV size may destroy the file system. Possible --fsmode values: manage Mount or unmount the fs as needed to resize the fs, and attempt to restore the original mount state at the end. nochange Do not mount or unmount the fs. If mounting or unmounting is required to resize the fs, then do not resize the fs or the LV and fail the command. offline Unmount the fs if it is mounted, and resize the fs while it is unmounted. If mounting is required to resize the fs, then do not resize the fs or the LV and fail the command. Notes on lvreduce: When no --fs or --resizefs option is specified: . lvextend default behavior is fs ignore. . lvreduce default behavior is fs checksize (includes activating the LV.) With the exception of --fs resize_fsadm|ignore, lvreduce requires the recent libblkid fields FSLASTBLOCK and FSBLOCKSIZE. FSLASTBLOCK*FSBLOCKSIZE is the last byte used by the fs on the LV, which determines if reducing the fs is necessary.
2022-06-14 23:20:21 +03:00
fsi->needs_fsck = 0;
}
if (fsi->needs_unmount)
cleanup: correcting some log_print Correcting to log_print_unless_silent(), so -qq can do some work.
2023-04-26 15:40:11 +03:00
log_print_unless_silent("File system unmount is needed for extend.");
lvresize: add new options and defaults for fs handling The new option "--fs String" for lvresize/lvreduce/lvextend controls the handling of file systems before/after resizing the LV. --resizefs is the same as --fs resize. The new option "--fsmode String" can be used to control mounting and unmounting of the fs during resizing. Possible --fs values: checksize Only applies to reducing size; does nothing for extend. Check the fs size and reduce the LV if the fs is not using the affected space, i.e. the fs does not need to be shrunk. Fail the command without reducing the fs or LV if the fs is using the affected space. resize Resize the fs using the fs-specific resize command. This may include mounting, unmounting, or running fsck. See --fsmode to control mounting behavior, and --nofsck to disable fsck. resize_fsadm Use the old method of calling fsadm to handle the fs (deprecated.) Warning: this option does not prevent lvreduce from destroying file systems that are unmounted (or mounted if prompts are skipped.) ignore Resize the LV without checking for or handling a file system. Warning: using ignore when reducing the LV size may destroy the file system. Possible --fsmode values: manage Mount or unmount the fs as needed to resize the fs, and attempt to restore the original mount state at the end. nochange Do not mount or unmount the fs. If mounting or unmounting is required to resize the fs, then do not resize the fs or the LV and fail the command. offline Unmount the fs if it is mounted, and resize the fs while it is unmounted. If mounting is required to resize the fs, then do not resize the fs or the LV and fail the command. Notes on lvreduce: When no --fs or --resizefs option is specified: . lvextend default behavior is fs ignore. . lvreduce default behavior is fs checksize (includes activating the LV.) With the exception of --fs resize_fsadm|ignore, lvreduce requires the recent libblkid fields FSLASTBLOCK and FSBLOCKSIZE. FSLASTBLOCK*FSBLOCKSIZE is the last byte used by the fs on the LV, which determines if reducing the fs is necessary.
2022-06-14 23:20:21 +03:00
if (fsi->needs_fsck)
cleanup: correcting some log_print Correcting to log_print_unless_silent(), so -qq can do some work.
2023-04-26 15:40:11 +03:00
log_print_unless_silent("File system fsck will be run before extend.");
lvresize: add new options and defaults for fs handling The new option "--fs String" for lvresize/lvreduce/lvextend controls the handling of file systems before/after resizing the LV. --resizefs is the same as --fs resize. The new option "--fsmode String" can be used to control mounting and unmounting of the fs during resizing. Possible --fs values: checksize Only applies to reducing size; does nothing for extend. Check the fs size and reduce the LV if the fs is not using the affected space, i.e. the fs does not need to be shrunk. Fail the command without reducing the fs or LV if the fs is using the affected space. resize Resize the fs using the fs-specific resize command. This may include mounting, unmounting, or running fsck. See --fsmode to control mounting behavior, and --nofsck to disable fsck. resize_fsadm Use the old method of calling fsadm to handle the fs (deprecated.) Warning: this option does not prevent lvreduce from destroying file systems that are unmounted (or mounted if prompts are skipped.) ignore Resize the LV without checking for or handling a file system. Warning: using ignore when reducing the LV size may destroy the file system. Possible --fsmode values: manage Mount or unmount the fs as needed to resize the fs, and attempt to restore the original mount state at the end. nochange Do not mount or unmount the fs. If mounting or unmounting is required to resize the fs, then do not resize the fs or the LV and fail the command. offline Unmount the fs if it is mounted, and resize the fs while it is unmounted. If mounting is required to resize the fs, then do not resize the fs or the LV and fail the command. Notes on lvreduce: When no --fs or --resizefs option is specified: . lvextend default behavior is fs ignore. . lvreduce default behavior is fs checksize (includes activating the LV.) With the exception of --fs resize_fsadm|ignore, lvreduce requires the recent libblkid fields FSLASTBLOCK and FSBLOCKSIZE. FSLASTBLOCK*FSBLOCKSIZE is the last byte used by the fs on the LV, which determines if reducing the fs is necessary.
2022-06-14 23:20:21 +03:00
if (fsi->needs_mount)
cleanup: correcting some log_print Correcting to log_print_unless_silent(), so -qq can do some work.
2023-04-26 15:40:11 +03:00
log_print_unless_silent("File system mount is needed for extend.");
lvresize: add new options and defaults for fs handling The new option "--fs String" for lvresize/lvreduce/lvextend controls the handling of file systems before/after resizing the LV. --resizefs is the same as --fs resize. The new option "--fsmode String" can be used to control mounting and unmounting of the fs during resizing. Possible --fs values: checksize Only applies to reducing size; does nothing for extend. Check the fs size and reduce the LV if the fs is not using the affected space, i.e. the fs does not need to be shrunk. Fail the command without reducing the fs or LV if the fs is using the affected space. resize Resize the fs using the fs-specific resize command. This may include mounting, unmounting, or running fsck. See --fsmode to control mounting behavior, and --nofsck to disable fsck. resize_fsadm Use the old method of calling fsadm to handle the fs (deprecated.) Warning: this option does not prevent lvreduce from destroying file systems that are unmounted (or mounted if prompts are skipped.) ignore Resize the LV without checking for or handling a file system. Warning: using ignore when reducing the LV size may destroy the file system. Possible --fsmode values: manage Mount or unmount the fs as needed to resize the fs, and attempt to restore the original mount state at the end. nochange Do not mount or unmount the fs. If mounting or unmounting is required to resize the fs, then do not resize the fs or the LV and fail the command. offline Unmount the fs if it is mounted, and resize the fs while it is unmounted. If mounting is required to resize the fs, then do not resize the fs or the LV and fail the command. Notes on lvreduce: When no --fs or --resizefs option is specified: . lvextend default behavior is fs ignore. . lvreduce default behavior is fs checksize (includes activating the LV.) With the exception of --fs resize_fsadm|ignore, lvreduce requires the recent libblkid fields FSLASTBLOCK and FSBLOCKSIZE. FSLASTBLOCK*FSBLOCKSIZE is the last byte used by the fs on the LV, which determines if reducing the fs is necessary.
2022-06-14 23:20:21 +03:00
if (fsi->needs_crypt)
cleanup: correcting some log_print Correcting to log_print_unless_silent(), so -qq can do some work.
2023-04-26 15:40:11 +03:00
log_print_unless_silent("cryptsetup resize is needed for extend.");
lvresize: add new options and defaults for fs handling The new option "--fs String" for lvresize/lvreduce/lvextend controls the handling of file systems before/after resizing the LV. --resizefs is the same as --fs resize. The new option "--fsmode String" can be used to control mounting and unmounting of the fs during resizing. Possible --fs values: checksize Only applies to reducing size; does nothing for extend. Check the fs size and reduce the LV if the fs is not using the affected space, i.e. the fs does not need to be shrunk. Fail the command without reducing the fs or LV if the fs is using the affected space. resize Resize the fs using the fs-specific resize command. This may include mounting, unmounting, or running fsck. See --fsmode to control mounting behavior, and --nofsck to disable fsck. resize_fsadm Use the old method of calling fsadm to handle the fs (deprecated.) Warning: this option does not prevent lvreduce from destroying file systems that are unmounted (or mounted if prompts are skipped.) ignore Resize the LV without checking for or handling a file system. Warning: using ignore when reducing the LV size may destroy the file system. Possible --fsmode values: manage Mount or unmount the fs as needed to resize the fs, and attempt to restore the original mount state at the end. nochange Do not mount or unmount the fs. If mounting or unmounting is required to resize the fs, then do not resize the fs or the LV and fail the command. offline Unmount the fs if it is mounted, and resize the fs while it is unmounted. If mounting is required to resize the fs, then do not resize the fs or the LV and fail the command. Notes on lvreduce: When no --fs or --resizefs option is specified: . lvextend default behavior is fs ignore. . lvreduce default behavior is fs checksize (includes activating the LV.) With the exception of --fs resize_fsadm|ignore, lvreduce requires the recent libblkid fields FSLASTBLOCK and FSBLOCKSIZE. FSLASTBLOCK*FSBLOCKSIZE is the last byte used by the fs on the LV, which determines if reducing the fs is necessary.
2022-06-14 23:20:21 +03:00
/*
* Use a confirmation prompt when mount|unmount is needed if
* the user did not give specific direction about how to handle
* mounting|unmounting with --fsmode.
*/
if (!strcmp(lp->fsopt, "resize") && !lp->user_set_fsmode &&
(fsi->needs_mount || fsi->needs_unmount))
confirm_mount_change = 1;
if (!lp->yes && confirm_mount_change) {
if (yes_no_prompt("Continue with %s file system extend steps:%s%s%s%s%s? [y/n]:",
fsi->fstype,
fsi->needs_unmount ? " unmount," : "",
fsi->needs_fsck ? " fsck," : "",
fsi->needs_mount ? " mount," : "",
fsi->needs_crypt ? " cryptsetup," : "",
fsi->needs_extend ? fs_extend_cmd : "") == 'n') {
log_error("File system not extended.");
return 0;
}
}
return 1;
}
static int _fs_reduce(struct cmd_context *cmd, struct logical_volume *lv,
struct lvresize_params *lp)
{
struct fs_info fsinfo;
struct fs_info fsinfo2;
uint64_t newsize_bytes_lv;
uint64_t newsize_bytes_fs;
int ret = 0;
memset(&fsinfo, 0, sizeof(fsinfo));
memset(&fsinfo2, 0, sizeof(fsinfo));
if (!fs_get_info(cmd, lv, &fsinfo, 1))
goto_out;
if (fsinfo.nofs) {
ret = 1;
goto_out;
}
/* extent_size units is SECTOR_SIZE (512) */
newsize_bytes_lv = lp->extents * lv->vg->extent_size * SECTOR_SIZE;
newsize_bytes_fs = newsize_bytes_lv;
/*
* If needs_crypt, then newsize_bytes passed to fs_reduce_script() and
* crypt_resize_script() needs to be decreased by the offset of crypt
* data on the LV (usually the size of the LUKS header which is usually
* 2MB for LUKS1 and 16MB for LUKS2.)
*/
if (fsinfo.needs_crypt) {
newsize_bytes_fs -= fsinfo.crypt_offset_bytes;
cleanup: correcting some log_print Correcting to log_print_unless_silent(), so -qq can do some work.
2023-04-26 15:40:11 +03:00
log_print_unless_silent("File system size %llub is adjusted for crypt data offset %ub.",
(unsigned long long)newsize_bytes_fs, fsinfo.crypt_offset_bytes);
lvresize: add new options and defaults for fs handling The new option "--fs String" for lvresize/lvreduce/lvextend controls the handling of file systems before/after resizing the LV. --resizefs is the same as --fs resize. The new option "--fsmode String" can be used to control mounting and unmounting of the fs during resizing. Possible --fs values: checksize Only applies to reducing size; does nothing for extend. Check the fs size and reduce the LV if the fs is not using the affected space, i.e. the fs does not need to be shrunk. Fail the command without reducing the fs or LV if the fs is using the affected space. resize Resize the fs using the fs-specific resize command. This may include mounting, unmounting, or running fsck. See --fsmode to control mounting behavior, and --nofsck to disable fsck. resize_fsadm Use the old method of calling fsadm to handle the fs (deprecated.) Warning: this option does not prevent lvreduce from destroying file systems that are unmounted (or mounted if prompts are skipped.) ignore Resize the LV without checking for or handling a file system. Warning: using ignore when reducing the LV size may destroy the file system. Possible --fsmode values: manage Mount or unmount the fs as needed to resize the fs, and attempt to restore the original mount state at the end. nochange Do not mount or unmount the fs. If mounting or unmounting is required to resize the fs, then do not resize the fs or the LV and fail the command. offline Unmount the fs if it is mounted, and resize the fs while it is unmounted. If mounting is required to resize the fs, then do not resize the fs or the LV and fail the command. Notes on lvreduce: When no --fs or --resizefs option is specified: . lvextend default behavior is fs ignore. . lvreduce default behavior is fs checksize (includes activating the LV.) With the exception of --fs resize_fsadm|ignore, lvreduce requires the recent libblkid fields FSLASTBLOCK and FSBLOCKSIZE. FSLASTBLOCK*FSBLOCKSIZE is the last byte used by the fs on the LV, which determines if reducing the fs is necessary.
2022-06-14 23:20:21 +03:00
}
/*
* Based on the --fs command option, the fs type, the last block used,
* and the mount state, determine if LV reduce is allowed. If not
* returns 0 and lvreduce should fail. If allowed, returns 1 and sets
* fsinfo.needs_* for any steps that are required to reduce the LV.
*/
if (!_fs_reduce_allow(cmd, lv, lp, newsize_bytes_lv, newsize_bytes_fs, &fsinfo))
goto_out;
/*
* Uncommon special case in which the FS does not need to be shrunk,
* but the crypt dev over the LV should be shrunk to correspond with
* the LV size, so that the FS does not see an incorrect device size.
*/
lvresize: only resize crypt when fs resize is enabled There were a couple of cases where lvresize, without --fs resize, was resizing the crypt layer above the LV. Resizing the crypt layer should only be done when fs resizing is enabled (even if the fs is already small enough due to being independently reduced.) Also, check the size of the crypt device to see if it's already been reduced independently, and skip the cryptsetup resize if it's not needed.
2023-01-19 20:36:51 +03:00
if (!fsinfo.needs_reduce && fsinfo.needs_crypt) {
/* Check if the crypt device is already sufficiently reduced. */
if (fsinfo.crypt_dev_size_bytes <= newsize_bytes_fs) {
cleanup: correcting some log_print Correcting to log_print_unless_silent(), so -qq can do some work.
2023-04-26 15:40:11 +03:00
log_print_unless_silent("crypt device is already reduced to %llu bytes.",
(unsigned long long)fsinfo.crypt_dev_size_bytes);
lvresize: only resize crypt when fs resize is enabled There were a couple of cases where lvresize, without --fs resize, was resizing the crypt layer above the LV. Resizing the crypt layer should only be done when fs resizing is enabled (even if the fs is already small enough due to being independently reduced.) Also, check the size of the crypt device to see if it's already been reduced independently, and skip the cryptsetup resize if it's not needed.
2023-01-19 20:36:51 +03:00
ret = 1;
goto out;
}
if (!strcmp(lp->fsopt, "checksize")) {
Revert "lvresize: enable crypt resizing with --force" It looks like force was not being used to enable crypt resize, but rather to force an inconsistency between LV and crypt sizes, so this is either not needed or force in this case should have some other meaning. This reverts commit ed808a9b548ca59221d512bfb7ae581e8367fe50.
2023-01-25 18:30:05 +03:00
log_error("crypt reduce is required (see --resizefs or cryptsetup resize.)");
ret = 0;
goto out;
lvresize: only resize crypt when fs resize is enabled There were a couple of cases where lvresize, without --fs resize, was resizing the crypt layer above the LV. Resizing the crypt layer should only be done when fs resizing is enabled (even if the fs is already small enough due to being independently reduced.) Also, check the size of the crypt device to see if it's already been reduced independently, and skip the cryptsetup resize if it's not needed.
2023-01-19 20:36:51 +03:00
}
if (test_mode()) {
ret = 1;
goto_out;
}
lvresize: add new options and defaults for fs handling The new option "--fs String" for lvresize/lvreduce/lvextend controls the handling of file systems before/after resizing the LV. --resizefs is the same as --fs resize. The new option "--fsmode String" can be used to control mounting and unmounting of the fs during resizing. Possible --fs values: checksize Only applies to reducing size; does nothing for extend. Check the fs size and reduce the LV if the fs is not using the affected space, i.e. the fs does not need to be shrunk. Fail the command without reducing the fs or LV if the fs is using the affected space. resize Resize the fs using the fs-specific resize command. This may include mounting, unmounting, or running fsck. See --fsmode to control mounting behavior, and --nofsck to disable fsck. resize_fsadm Use the old method of calling fsadm to handle the fs (deprecated.) Warning: this option does not prevent lvreduce from destroying file systems that are unmounted (or mounted if prompts are skipped.) ignore Resize the LV without checking for or handling a file system. Warning: using ignore when reducing the LV size may destroy the file system. Possible --fsmode values: manage Mount or unmount the fs as needed to resize the fs, and attempt to restore the original mount state at the end. nochange Do not mount or unmount the fs. If mounting or unmounting is required to resize the fs, then do not resize the fs or the LV and fail the command. offline Unmount the fs if it is mounted, and resize the fs while it is unmounted. If mounting is required to resize the fs, then do not resize the fs or the LV and fail the command. Notes on lvreduce: When no --fs or --resizefs option is specified: . lvextend default behavior is fs ignore. . lvreduce default behavior is fs checksize (includes activating the LV.) With the exception of --fs resize_fsadm|ignore, lvreduce requires the recent libblkid fields FSLASTBLOCK and FSBLOCKSIZE. FSLASTBLOCK*FSBLOCKSIZE is the last byte used by the fs on the LV, which determines if reducing the fs is necessary.
2022-06-14 23:20:21 +03:00
ret = crypt_resize_script(cmd, lv, &fsinfo, newsize_bytes_fs);
goto out;
}
/*
* fs reduce is not needed to reduce the LV.
*/
if (!fsinfo.needs_reduce) {
ret = 1;
goto_out;
}
if (test_mode()) {
if (fsinfo.needs_unmount)
cleanup: correcting some log_print Correcting to log_print_unless_silent(), so -qq can do some work.
2023-04-26 15:40:11 +03:00
log_print_unless_silent("Skip unmount in test mode.");
lvresize: add new options and defaults for fs handling The new option "--fs String" for lvresize/lvreduce/lvextend controls the handling of file systems before/after resizing the LV. --resizefs is the same as --fs resize. The new option "--fsmode String" can be used to control mounting and unmounting of the fs during resizing. Possible --fs values: checksize Only applies to reducing size; does nothing for extend. Check the fs size and reduce the LV if the fs is not using the affected space, i.e. the fs does not need to be shrunk. Fail the command without reducing the fs or LV if the fs is using the affected space. resize Resize the fs using the fs-specific resize command. This may include mounting, unmounting, or running fsck. See --fsmode to control mounting behavior, and --nofsck to disable fsck. resize_fsadm Use the old method of calling fsadm to handle the fs (deprecated.) Warning: this option does not prevent lvreduce from destroying file systems that are unmounted (or mounted if prompts are skipped.) ignore Resize the LV without checking for or handling a file system. Warning: using ignore when reducing the LV size may destroy the file system. Possible --fsmode values: manage Mount or unmount the fs as needed to resize the fs, and attempt to restore the original mount state at the end. nochange Do not mount or unmount the fs. If mounting or unmounting is required to resize the fs, then do not resize the fs or the LV and fail the command. offline Unmount the fs if it is mounted, and resize the fs while it is unmounted. If mounting is required to resize the fs, then do not resize the fs or the LV and fail the command. Notes on lvreduce: When no --fs or --resizefs option is specified: . lvextend default behavior is fs ignore. . lvreduce default behavior is fs checksize (includes activating the LV.) With the exception of --fs resize_fsadm|ignore, lvreduce requires the recent libblkid fields FSLASTBLOCK and FSBLOCKSIZE. FSLASTBLOCK*FSBLOCKSIZE is the last byte used by the fs on the LV, which determines if reducing the fs is necessary.
2022-06-14 23:20:21 +03:00
if (fsinfo.needs_fsck)
cleanup: correcting some log_print Correcting to log_print_unless_silent(), so -qq can do some work.
2023-04-26 15:40:11 +03:00
log_print_unless_silent("Skip fsck in test mode.");
lvresize: add new options and defaults for fs handling The new option "--fs String" for lvresize/lvreduce/lvextend controls the handling of file systems before/after resizing the LV. --resizefs is the same as --fs resize. The new option "--fsmode String" can be used to control mounting and unmounting of the fs during resizing. Possible --fs values: checksize Only applies to reducing size; does nothing for extend. Check the fs size and reduce the LV if the fs is not using the affected space, i.e. the fs does not need to be shrunk. Fail the command without reducing the fs or LV if the fs is using the affected space. resize Resize the fs using the fs-specific resize command. This may include mounting, unmounting, or running fsck. See --fsmode to control mounting behavior, and --nofsck to disable fsck. resize_fsadm Use the old method of calling fsadm to handle the fs (deprecated.) Warning: this option does not prevent lvreduce from destroying file systems that are unmounted (or mounted if prompts are skipped.) ignore Resize the LV without checking for or handling a file system. Warning: using ignore when reducing the LV size may destroy the file system. Possible --fsmode values: manage Mount or unmount the fs as needed to resize the fs, and attempt to restore the original mount state at the end. nochange Do not mount or unmount the fs. If mounting or unmounting is required to resize the fs, then do not resize the fs or the LV and fail the command. offline Unmount the fs if it is mounted, and resize the fs while it is unmounted. If mounting is required to resize the fs, then do not resize the fs or the LV and fail the command. Notes on lvreduce: When no --fs or --resizefs option is specified: . lvextend default behavior is fs ignore. . lvreduce default behavior is fs checksize (includes activating the LV.) With the exception of --fs resize_fsadm|ignore, lvreduce requires the recent libblkid fields FSLASTBLOCK and FSBLOCKSIZE. FSLASTBLOCK*FSBLOCKSIZE is the last byte used by the fs on the LV, which determines if reducing the fs is necessary.
2022-06-14 23:20:21 +03:00
if (fsinfo.needs_mount)
cleanup: correcting some log_print Correcting to log_print_unless_silent(), so -qq can do some work.
2023-04-26 15:40:11 +03:00
log_print_unless_silent("Skip mount in test mode.");
lvresize: add new options and defaults for fs handling The new option "--fs String" for lvresize/lvreduce/lvextend controls the handling of file systems before/after resizing the LV. --resizefs is the same as --fs resize. The new option "--fsmode String" can be used to control mounting and unmounting of the fs during resizing. Possible --fs values: checksize Only applies to reducing size; does nothing for extend. Check the fs size and reduce the LV if the fs is not using the affected space, i.e. the fs does not need to be shrunk. Fail the command without reducing the fs or LV if the fs is using the affected space. resize Resize the fs using the fs-specific resize command. This may include mounting, unmounting, or running fsck. See --fsmode to control mounting behavior, and --nofsck to disable fsck. resize_fsadm Use the old method of calling fsadm to handle the fs (deprecated.) Warning: this option does not prevent lvreduce from destroying file systems that are unmounted (or mounted if prompts are skipped.) ignore Resize the LV without checking for or handling a file system. Warning: using ignore when reducing the LV size may destroy the file system. Possible --fsmode values: manage Mount or unmount the fs as needed to resize the fs, and attempt to restore the original mount state at the end. nochange Do not mount or unmount the fs. If mounting or unmounting is required to resize the fs, then do not resize the fs or the LV and fail the command. offline Unmount the fs if it is mounted, and resize the fs while it is unmounted. If mounting is required to resize the fs, then do not resize the fs or the LV and fail the command. Notes on lvreduce: When no --fs or --resizefs option is specified: . lvextend default behavior is fs ignore. . lvreduce default behavior is fs checksize (includes activating the LV.) With the exception of --fs resize_fsadm|ignore, lvreduce requires the recent libblkid fields FSLASTBLOCK and FSBLOCKSIZE. FSLASTBLOCK*FSBLOCKSIZE is the last byte used by the fs on the LV, which determines if reducing the fs is necessary.
2022-06-14 23:20:21 +03:00
if (fsinfo.needs_crypt)
cleanup: correcting some log_print Correcting to log_print_unless_silent(), so -qq can do some work.
2023-04-26 15:40:11 +03:00
log_print_unless_silent("Skip cryptsetup in test mode.");
log_print_unless_silent("Skip fs reduce in test mode.");
lvresize: add new options and defaults for fs handling The new option "--fs String" for lvresize/lvreduce/lvextend controls the handling of file systems before/after resizing the LV. --resizefs is the same as --fs resize. The new option "--fsmode String" can be used to control mounting and unmounting of the fs during resizing. Possible --fs values: checksize Only applies to reducing size; does nothing for extend. Check the fs size and reduce the LV if the fs is not using the affected space, i.e. the fs does not need to be shrunk. Fail the command without reducing the fs or LV if the fs is using the affected space. resize Resize the fs using the fs-specific resize command. This may include mounting, unmounting, or running fsck. See --fsmode to control mounting behavior, and --nofsck to disable fsck. resize_fsadm Use the old method of calling fsadm to handle the fs (deprecated.) Warning: this option does not prevent lvreduce from destroying file systems that are unmounted (or mounted if prompts are skipped.) ignore Resize the LV without checking for or handling a file system. Warning: using ignore when reducing the LV size may destroy the file system. Possible --fsmode values: manage Mount or unmount the fs as needed to resize the fs, and attempt to restore the original mount state at the end. nochange Do not mount or unmount the fs. If mounting or unmounting is required to resize the fs, then do not resize the fs or the LV and fail the command. offline Unmount the fs if it is mounted, and resize the fs while it is unmounted. If mounting is required to resize the fs, then do not resize the fs or the LV and fail the command. Notes on lvreduce: When no --fs or --resizefs option is specified: . lvextend default behavior is fs ignore. . lvreduce default behavior is fs checksize (includes activating the LV.) With the exception of --fs resize_fsadm|ignore, lvreduce requires the recent libblkid fields FSLASTBLOCK and FSBLOCKSIZE. FSLASTBLOCK*FSBLOCKSIZE is the last byte used by the fs on the LV, which determines if reducing the fs is necessary.
2022-06-14 23:20:21 +03:00
ret = 1;
goto out;
}
/*
* mounting, unmounting, fsck, and shrink command can all take a long
* time to run, and this lvm command should not block other lvm
* commands from running during that time, so release the vg lock
* around the long-running steps, and reacquire after.
*/
unlock_vg(cmd, lv->vg, lv->vg->name);
if (!fs_reduce_script(cmd, lv, &fsinfo, newsize_bytes_fs, lp->fsmode))
goto_out;
if (!lock_vol(cmd, lv->vg->name, LCK_VG_WRITE, NULL)) {
log_error("Failed to lock VG, cannot reduce LV.");
ret = 0;
goto out;
}
/*
* Check that the vg wasn't changed while it was unlocked.
* (can_use_one_scan: check just one mda in the vg for changes)
*/
cmd->can_use_one_scan = 1;
if (scan_text_mismatch(cmd, lv->vg->name, NULL)) {
cleanup: correcting some log_print Correcting to log_print_unless_silent(), so -qq can do some work.
2023-04-26 15:40:11 +03:00
log_print_unless_silent("VG was changed during fs operations, restarting.");
lvresize: add new options and defaults for fs handling The new option "--fs String" for lvresize/lvreduce/lvextend controls the handling of file systems before/after resizing the LV. --resizefs is the same as --fs resize. The new option "--fsmode String" can be used to control mounting and unmounting of the fs during resizing. Possible --fs values: checksize Only applies to reducing size; does nothing for extend. Check the fs size and reduce the LV if the fs is not using the affected space, i.e. the fs does not need to be shrunk. Fail the command without reducing the fs or LV if the fs is using the affected space. resize Resize the fs using the fs-specific resize command. This may include mounting, unmounting, or running fsck. See --fsmode to control mounting behavior, and --nofsck to disable fsck. resize_fsadm Use the old method of calling fsadm to handle the fs (deprecated.) Warning: this option does not prevent lvreduce from destroying file systems that are unmounted (or mounted if prompts are skipped.) ignore Resize the LV without checking for or handling a file system. Warning: using ignore when reducing the LV size may destroy the file system. Possible --fsmode values: manage Mount or unmount the fs as needed to resize the fs, and attempt to restore the original mount state at the end. nochange Do not mount or unmount the fs. If mounting or unmounting is required to resize the fs, then do not resize the fs or the LV and fail the command. offline Unmount the fs if it is mounted, and resize the fs while it is unmounted. If mounting is required to resize the fs, then do not resize the fs or the LV and fail the command. Notes on lvreduce: When no --fs or --resizefs option is specified: . lvextend default behavior is fs ignore. . lvreduce default behavior is fs checksize (includes activating the LV.) With the exception of --fs resize_fsadm|ignore, lvreduce requires the recent libblkid fields FSLASTBLOCK and FSBLOCKSIZE. FSLASTBLOCK*FSBLOCKSIZE is the last byte used by the fs on the LV, which determines if reducing the fs is necessary.
2022-06-14 23:20:21 +03:00
lp->vg_changed_error = 1;
ret = 0;
goto out;
}
/*
* Re-check the fs last block which should now be less than the
* requested (reduced) LV size.
*/
if (!fs_get_info(cmd, lv, &fsinfo2, 0))
goto_out;
if (fsinfo.fs_last_byte && (fsinfo2.fs_last_byte > newsize_bytes_fs)) {
log_error("File system last byte %llu is greater than new size %llu bytes.",
(unsigned long long)fsinfo2.fs_last_byte,
(unsigned long long)newsize_bytes_fs);
goto_out;
}
ret = 1;
out:
return ret;
}
static int _fs_extend(struct cmd_context *cmd, struct logical_volume *lv,
struct lvresize_params *lp)
{
struct fs_info fsinfo;
uint64_t newsize_bytes_lv;
uint64_t newsize_bytes_fs;
int ret = 0;
memset(&fsinfo, 0, sizeof(fsinfo));
if (!fs_get_info(cmd, lv, &fsinfo, 1))
goto_out;
if (fsinfo.nofs) {
ret = 1;
goto_out;
}
/*
* Note: here in the case of extend, newsize_bytes_lv/newsize_bytes_fs
* are only calculated and used for log messages. The extend commands
* do not use these values, they just extend to the new LV size that
* is visible to them.
*/
/* extent_size units is SECTOR_SIZE (512) */
newsize_bytes_lv = lp->extents * lv->vg->extent_size * SECTOR_SIZE;
newsize_bytes_fs = newsize_bytes_lv;
if (fsinfo.needs_crypt) {
newsize_bytes_fs -= fsinfo.crypt_offset_bytes;
cleanup: correcting some log_print Correcting to log_print_unless_silent(), so -qq can do some work.
2023-04-26 15:40:11 +03:00
log_print_unless_silent("File system size %llub is adjusted for crypt data offset %ub.",
(unsigned long long)newsize_bytes_fs, fsinfo.crypt_offset_bytes);
lvresize: add new options and defaults for fs handling The new option "--fs String" for lvresize/lvreduce/lvextend controls the handling of file systems before/after resizing the LV. --resizefs is the same as --fs resize. The new option "--fsmode String" can be used to control mounting and unmounting of the fs during resizing. Possible --fs values: checksize Only applies to reducing size; does nothing for extend. Check the fs size and reduce the LV if the fs is not using the affected space, i.e. the fs does not need to be shrunk. Fail the command without reducing the fs or LV if the fs is using the affected space. resize Resize the fs using the fs-specific resize command. This may include mounting, unmounting, or running fsck. See --fsmode to control mounting behavior, and --nofsck to disable fsck. resize_fsadm Use the old method of calling fsadm to handle the fs (deprecated.) Warning: this option does not prevent lvreduce from destroying file systems that are unmounted (or mounted if prompts are skipped.) ignore Resize the LV without checking for or handling a file system. Warning: using ignore when reducing the LV size may destroy the file system. Possible --fsmode values: manage Mount or unmount the fs as needed to resize the fs, and attempt to restore the original mount state at the end. nochange Do not mount or unmount the fs. If mounting or unmounting is required to resize the fs, then do not resize the fs or the LV and fail the command. offline Unmount the fs if it is mounted, and resize the fs while it is unmounted. If mounting is required to resize the fs, then do not resize the fs or the LV and fail the command. Notes on lvreduce: When no --fs or --resizefs option is specified: . lvextend default behavior is fs ignore. . lvreduce default behavior is fs checksize (includes activating the LV.) With the exception of --fs resize_fsadm|ignore, lvreduce requires the recent libblkid fields FSLASTBLOCK and FSBLOCKSIZE. FSLASTBLOCK*FSBLOCKSIZE is the last byte used by the fs on the LV, which determines if reducing the fs is necessary.
2022-06-14 23:20:21 +03:00
}
/*
* Decide if fs should be extended based on the --fs option,
* the fs type and the mount state.
*/
if (!_fs_extend_allow(cmd, lv, lp, &fsinfo))
goto_out;
/*
* fs extend is not needed
*/
if (!fsinfo.needs_extend) {
ret = 1;
goto_out;
}
if (test_mode()) {
if (fsinfo.needs_unmount)
cleanup: correcting some log_print Correcting to log_print_unless_silent(), so -qq can do some work.
2023-04-26 15:40:11 +03:00
log_print_unless_silent("Skip unmount in test mode.");
lvresize: add new options and defaults for fs handling The new option "--fs String" for lvresize/lvreduce/lvextend controls the handling of file systems before/after resizing the LV. --resizefs is the same as --fs resize. The new option "--fsmode String" can be used to control mounting and unmounting of the fs during resizing. Possible --fs values: checksize Only applies to reducing size; does nothing for extend. Check the fs size and reduce the LV if the fs is not using the affected space, i.e. the fs does not need to be shrunk. Fail the command without reducing the fs or LV if the fs is using the affected space. resize Resize the fs using the fs-specific resize command. This may include mounting, unmounting, or running fsck. See --fsmode to control mounting behavior, and --nofsck to disable fsck. resize_fsadm Use the old method of calling fsadm to handle the fs (deprecated.) Warning: this option does not prevent lvreduce from destroying file systems that are unmounted (or mounted if prompts are skipped.) ignore Resize the LV without checking for or handling a file system. Warning: using ignore when reducing the LV size may destroy the file system. Possible --fsmode values: manage Mount or unmount the fs as needed to resize the fs, and attempt to restore the original mount state at the end. nochange Do not mount or unmount the fs. If mounting or unmounting is required to resize the fs, then do not resize the fs or the LV and fail the command. offline Unmount the fs if it is mounted, and resize the fs while it is unmounted. If mounting is required to resize the fs, then do not resize the fs or the LV and fail the command. Notes on lvreduce: When no --fs or --resizefs option is specified: . lvextend default behavior is fs ignore. . lvreduce default behavior is fs checksize (includes activating the LV.) With the exception of --fs resize_fsadm|ignore, lvreduce requires the recent libblkid fields FSLASTBLOCK and FSBLOCKSIZE. FSLASTBLOCK*FSBLOCKSIZE is the last byte used by the fs on the LV, which determines if reducing the fs is necessary.
2022-06-14 23:20:21 +03:00
if (fsinfo.needs_fsck)
cleanup: correcting some log_print Correcting to log_print_unless_silent(), so -qq can do some work.
2023-04-26 15:40:11 +03:00
log_print_unless_silent("Skip fsck in test mode.");
lvresize: add new options and defaults for fs handling The new option "--fs String" for lvresize/lvreduce/lvextend controls the handling of file systems before/after resizing the LV. --resizefs is the same as --fs resize. The new option "--fsmode String" can be used to control mounting and unmounting of the fs during resizing. Possible --fs values: checksize Only applies to reducing size; does nothing for extend. Check the fs size and reduce the LV if the fs is not using the affected space, i.e. the fs does not need to be shrunk. Fail the command without reducing the fs or LV if the fs is using the affected space. resize Resize the fs using the fs-specific resize command. This may include mounting, unmounting, or running fsck. See --fsmode to control mounting behavior, and --nofsck to disable fsck. resize_fsadm Use the old method of calling fsadm to handle the fs (deprecated.) Warning: this option does not prevent lvreduce from destroying file systems that are unmounted (or mounted if prompts are skipped.) ignore Resize the LV without checking for or handling a file system. Warning: using ignore when reducing the LV size may destroy the file system. Possible --fsmode values: manage Mount or unmount the fs as needed to resize the fs, and attempt to restore the original mount state at the end. nochange Do not mount or unmount the fs. If mounting or unmounting is required to resize the fs, then do not resize the fs or the LV and fail the command. offline Unmount the fs if it is mounted, and resize the fs while it is unmounted. If mounting is required to resize the fs, then do not resize the fs or the LV and fail the command. Notes on lvreduce: When no --fs or --resizefs option is specified: . lvextend default behavior is fs ignore. . lvreduce default behavior is fs checksize (includes activating the LV.) With the exception of --fs resize_fsadm|ignore, lvreduce requires the recent libblkid fields FSLASTBLOCK and FSBLOCKSIZE. FSLASTBLOCK*FSBLOCKSIZE is the last byte used by the fs on the LV, which determines if reducing the fs is necessary.
2022-06-14 23:20:21 +03:00
if (fsinfo.needs_mount)
cleanup: correcting some log_print Correcting to log_print_unless_silent(), so -qq can do some work.
2023-04-26 15:40:11 +03:00
log_print_unless_silent("Skip mount in test mode.");
lvresize: add new options and defaults for fs handling The new option "--fs String" for lvresize/lvreduce/lvextend controls the handling of file systems before/after resizing the LV. --resizefs is the same as --fs resize. The new option "--fsmode String" can be used to control mounting and unmounting of the fs during resizing. Possible --fs values: checksize Only applies to reducing size; does nothing for extend. Check the fs size and reduce the LV if the fs is not using the affected space, i.e. the fs does not need to be shrunk. Fail the command without reducing the fs or LV if the fs is using the affected space. resize Resize the fs using the fs-specific resize command. This may include mounting, unmounting, or running fsck. See --fsmode to control mounting behavior, and --nofsck to disable fsck. resize_fsadm Use the old method of calling fsadm to handle the fs (deprecated.) Warning: this option does not prevent lvreduce from destroying file systems that are unmounted (or mounted if prompts are skipped.) ignore Resize the LV without checking for or handling a file system. Warning: using ignore when reducing the LV size may destroy the file system. Possible --fsmode values: manage Mount or unmount the fs as needed to resize the fs, and attempt to restore the original mount state at the end. nochange Do not mount or unmount the fs. If mounting or unmounting is required to resize the fs, then do not resize the fs or the LV and fail the command. offline Unmount the fs if it is mounted, and resize the fs while it is unmounted. If mounting is required to resize the fs, then do not resize the fs or the LV and fail the command. Notes on lvreduce: When no --fs or --resizefs option is specified: . lvextend default behavior is fs ignore. . lvreduce default behavior is fs checksize (includes activating the LV.) With the exception of --fs resize_fsadm|ignore, lvreduce requires the recent libblkid fields FSLASTBLOCK and FSBLOCKSIZE. FSLASTBLOCK*FSBLOCKSIZE is the last byte used by the fs on the LV, which determines if reducing the fs is necessary.
2022-06-14 23:20:21 +03:00
if (fsinfo.needs_crypt)
cleanup: correcting some log_print Correcting to log_print_unless_silent(), so -qq can do some work.
2023-04-26 15:40:11 +03:00
log_print_unless_silent("Skip cryptsetup in test mode.");
log_print_unless_silent("Skip fs extend in test mode.");
lvresize: add new options and defaults for fs handling The new option "--fs String" for lvresize/lvreduce/lvextend controls the handling of file systems before/after resizing the LV. --resizefs is the same as --fs resize. The new option "--fsmode String" can be used to control mounting and unmounting of the fs during resizing. Possible --fs values: checksize Only applies to reducing size; does nothing for extend. Check the fs size and reduce the LV if the fs is not using the affected space, i.e. the fs does not need to be shrunk. Fail the command without reducing the fs or LV if the fs is using the affected space. resize Resize the fs using the fs-specific resize command. This may include mounting, unmounting, or running fsck. See --fsmode to control mounting behavior, and --nofsck to disable fsck. resize_fsadm Use the old method of calling fsadm to handle the fs (deprecated.) Warning: this option does not prevent lvreduce from destroying file systems that are unmounted (or mounted if prompts are skipped.) ignore Resize the LV without checking for or handling a file system. Warning: using ignore when reducing the LV size may destroy the file system. Possible --fsmode values: manage Mount or unmount the fs as needed to resize the fs, and attempt to restore the original mount state at the end. nochange Do not mount or unmount the fs. If mounting or unmounting is required to resize the fs, then do not resize the fs or the LV and fail the command. offline Unmount the fs if it is mounted, and resize the fs while it is unmounted. If mounting is required to resize the fs, then do not resize the fs or the LV and fail the command. Notes on lvreduce: When no --fs or --resizefs option is specified: . lvextend default behavior is fs ignore. . lvreduce default behavior is fs checksize (includes activating the LV.) With the exception of --fs resize_fsadm|ignore, lvreduce requires the recent libblkid fields FSLASTBLOCK and FSBLOCKSIZE. FSLASTBLOCK*FSBLOCKSIZE is the last byte used by the fs on the LV, which determines if reducing the fs is necessary.
2022-06-14 23:20:21 +03:00
ret = 1;
goto out;
}
/*
* mounting, unmounting and extend command can all take a long
* time to run, and this lvm command should not block other lvm
* commands from running during that time, so release the vg
* lock around the long-running steps.
*/
unlock_vg(cmd, lv->vg, lv->vg->name);
if (!fs_extend_script(cmd, lv, &fsinfo, newsize_bytes_fs, lp->fsmode))
goto_out;
ret = 1;
out:
return ret;
}
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
int lv_resize(struct cmd_context *cmd, struct logical_volume *lv,
struct lvresize_params *lp)
lvresize: separate validation from action Start separating the validation from the action in the basic lvresize code moved to the library. Remove incorrect use of command line error codes from lvresize library functions. Move errors.h to tools directory to reinforce this, exporting public versions of the error codes in lvm2cmd.h for dmeventd plugins to use.
2013-07-06 06:28:21 +04:00
{
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
struct lvresize_params lp_meta;
lvresize: separate validation from action Start separating the validation from the action in the basic lvresize code moved to the library. Remove incorrect use of command line error codes from lvresize library functions. Move errors.h to tools directory to reinforce this, exporting public versions of the error codes in lvm2cmd.h for dmeventd plugins to use.
2013-07-06 06:28:21 +04:00
struct volume_group *vg = lv->vg;
lvreduce/lvresize: add ability to reduce the size of a RaidLV - support shrinking of raid0/1/4/5/6/10 LVs - enhance lvresize-raid.sh tests: add raid0* and raid10 - fix have_raid4 in aux.sh to allow lv_resize-raid.sh and other scripts to test raid4 Resolves: rhbz1394048
2017-02-10 00:41:28 +03:00
struct lv_segment *seg = first_seg(lv);
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
struct logical_volume *lv_top = NULL;
struct logical_volume *lv_main = NULL;
struct logical_volume *lv_meta = NULL;
struct logical_volume *lv_main_layer = NULL;
struct logical_volume *lv_meta_layer = NULL;
int main_size_matches = 0;
int meta_size_matches = 0;
int is_extend = (lp->resize == LV_EXTEND);
int is_reduce = (lp->resize == LV_REDUCE);
lvresize: add new options and defaults for fs handling The new option "--fs String" for lvresize/lvreduce/lvextend controls the handling of file systems before/after resizing the LV. --resizefs is the same as --fs resize. The new option "--fsmode String" can be used to control mounting and unmounting of the fs during resizing. Possible --fs values: checksize Only applies to reducing size; does nothing for extend. Check the fs size and reduce the LV if the fs is not using the affected space, i.e. the fs does not need to be shrunk. Fail the command without reducing the fs or LV if the fs is using the affected space. resize Resize the fs using the fs-specific resize command. This may include mounting, unmounting, or running fsck. See --fsmode to control mounting behavior, and --nofsck to disable fsck. resize_fsadm Use the old method of calling fsadm to handle the fs (deprecated.) Warning: this option does not prevent lvreduce from destroying file systems that are unmounted (or mounted if prompts are skipped.) ignore Resize the LV without checking for or handling a file system. Warning: using ignore when reducing the LV size may destroy the file system. Possible --fsmode values: manage Mount or unmount the fs as needed to resize the fs, and attempt to restore the original mount state at the end. nochange Do not mount or unmount the fs. If mounting or unmounting is required to resize the fs, then do not resize the fs or the LV and fail the command. offline Unmount the fs if it is mounted, and resize the fs while it is unmounted. If mounting is required to resize the fs, then do not resize the fs or the LV and fail the command. Notes on lvreduce: When no --fs or --resizefs option is specified: . lvextend default behavior is fs ignore. . lvreduce default behavior is fs checksize (includes activating the LV.) With the exception of --fs resize_fsadm|ignore, lvreduce requires the recent libblkid fields FSLASTBLOCK and FSBLOCKSIZE. FSLASTBLOCK*FSBLOCKSIZE is the last byte used by the fs on the LV, which determines if reducing the fs is necessary.
2022-06-14 23:20:21 +03:00
int is_active = 0;
lvresize: support more resized LVs Add code to support more LVs to be resized through a same code path using a single lvresize_params struct. (Now it's used for thin-pool metadata resize, next user will be snapshot virtual resize). Update code to adjust percent amount resize for use_policies. Properly activate inactive thin-pool in case of any pool resize as the command should not 'deffer' this operation to next activation.
2016-06-23 00:32:35 +03:00
int activated = 0;
lvresize: add new options and defaults for fs handling The new option "--fs String" for lvresize/lvreduce/lvextend controls the handling of file systems before/after resizing the LV. --resizefs is the same as --fs resize. The new option "--fsmode String" can be used to control mounting and unmounting of the fs during resizing. Possible --fs values: checksize Only applies to reducing size; does nothing for extend. Check the fs size and reduce the LV if the fs is not using the affected space, i.e. the fs does not need to be shrunk. Fail the command without reducing the fs or LV if the fs is using the affected space. resize Resize the fs using the fs-specific resize command. This may include mounting, unmounting, or running fsck. See --fsmode to control mounting behavior, and --nofsck to disable fsck. resize_fsadm Use the old method of calling fsadm to handle the fs (deprecated.) Warning: this option does not prevent lvreduce from destroying file systems that are unmounted (or mounted if prompts are skipped.) ignore Resize the LV without checking for or handling a file system. Warning: using ignore when reducing the LV size may destroy the file system. Possible --fsmode values: manage Mount or unmount the fs as needed to resize the fs, and attempt to restore the original mount state at the end. nochange Do not mount or unmount the fs. If mounting or unmounting is required to resize the fs, then do not resize the fs or the LV and fail the command. offline Unmount the fs if it is mounted, and resize the fs while it is unmounted. If mounting is required to resize the fs, then do not resize the fs or the LV and fail the command. Notes on lvreduce: When no --fs or --resizefs option is specified: . lvextend default behavior is fs ignore. . lvreduce default behavior is fs checksize (includes activating the LV.) With the exception of --fs resize_fsadm|ignore, lvreduce requires the recent libblkid fields FSLASTBLOCK and FSBLOCKSIZE. FSLASTBLOCK*FSBLOCKSIZE is the last byte used by the fs on the LV, which determines if reducing the fs is necessary.
2022-06-14 23:20:21 +03:00
int activated_checksize = 0;
lvresize: fix zero size extension Commit ca878a3426197b629c76e98cfc049948da470cd7 changed behavior or resize operation. Later the code has been futher changed to skip fs resize completely when size of LV is already matching and finaly at the most recent resize changeset for resize the check for matching size has been eliminated as well so we ended with a request call to resize fs to 0 size in some cases. This commit reoders some test so the prompt happens just once before resize of possibly 2 related volumes. Also extra test for having LV already given size is added, and whole metadata update is skipped for this case as the only result would be an increment of seqno. However the filesystem is still resized when requested, so if the LV has some size and the resize is resolved to the same size, the filesystem resize is called so in case FS would not match, the resize will happen.
2016-07-13 17:23:25 +03:00
int status;
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
int ret = 0;
lvresize: separate validation from action Start separating the validation from the action in the basic lvresize code moved to the library. Remove incorrect use of command line error codes from lvresize library functions. Move errors.h to tools directory to reinforce this, exporting public versions of the error codes in lvm2cmd.h for dmeventd plugins to use.
2013-07-06 06:28:21 +04:00
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
memset(&lp_meta, 0, sizeof(lp_meta));
/*
* Some checks apply to the LV command arg (don't require top/bottom
* LVs in a stack), and don't require knowing if the command is doing
* extend or reduce (determined later).
*/
if (lp->stripe_size && !_validate_stripesize(vg, lp))
return_0;
/*
* The only types of !visible/internal/non-top LVs that can be directly
* resized via the command arg. Other internal LVs are resized
* indirectly when resizing a top LV.
*/
if (!lv_is_visible(lv) &&
!lv_is_thin_pool_data(lv) &&
!lv_is_thin_pool_metadata(lv) &&
!lv_is_vdo_pool_data(lv) &&
!lv_is_lockd_sanlock_lv(lv)) {
log_error("Can't resize internal logical volume %s.", display_lvname(lv));
return 0;
}
/*
* Figure out which LVs are going to be extended, and set params
* to the requested extents/size for each. Some LVs are extended
* only by extending an underlying LV. Extending some top level
* LVs results in extending multiple underlying LVs.
*
* lv_top is the top level LV in stack.
* lv_main is the main LV to be resized.
* lv_meta is always a thin pool metadata LV.
*
* lv_main_layer/lv_meta_layer may be LV types (like cache) that are
* layered over the main/meta LVs. These layer LVs are skipped over
* by get_resizable_layer_lv() which finds the bottom-most layer
* which is originally resized. The layer LVs are resized indirectly
* as a result of the lower data-holding LVs being resized.
*
* In the simplest case there is no layering/stacking, and
* lv == lv_main == lv_main_layer == lv_top
*/
lvresize: fixes for recent commit Merging process and patch rework missed some bits - fix them.
2016-06-24 01:24:26 +03:00
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
if (cmd->command_enum == lvextend_policy_CMD) {
/* lvextend --use-policies may extend main or meta or both */
lv_top = lv;
if (lv_is_thin_pool(lv)) {
if (lp->policy_percent_main) {
lv_main = seg_lv(first_seg(lv), 0); /* thin pool data */
lp->percent_value = lp->policy_percent_main;
}
if (lp->policy_percent_meta) {
lv_meta = first_seg(lv)->metadata_lv; /* thin pool metadata */
_setup_params_for_extend_metadata(lv_meta, &lp_meta);
/* override setup function which isn't right for policy use */
lp_meta.percent = PERCENT_LV;
lp_meta.sign = SIGN_PLUS;
lp_meta.percent_value = lp->policy_percent_meta;
lp_meta.pvh = lp->pvh;
}
} else if (lv_is_vdo_pool(lv)) {
lv_main = seg_lv(first_seg(lv), 0); /* vdo pool data */
lp->percent_value = lp->policy_percent_main;
} else if (lv_is_cow(lv)) {
lv_main = lv;
lp->percent_value = lp->policy_percent_main;
} else
lvresize: support more resized LVs Add code to support more LVs to be resized through a same code path using a single lvresize_params struct. (Now it's used for thin-pool metadata resize, next user will be snapshot virtual resize). Update code to adjust percent amount resize for use_policies. Properly activate inactive thin-pool in case of any pool resize as the command should not 'deffer' this operation to next activation.
2016-06-23 00:32:35 +03:00
return_0;
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
} else if ((cmd->command_enum == lvextend_pool_metadata_CMD) ||
(cmd->command_enum == lvresize_pool_metadata_CMD)) {
/* lvresize|lvextend --poolmetadatasize, extends only thin pool metadata */
if (lv_is_thin_pool(lv)) {
lv_top = lv;
lv_meta = first_seg(lv)->metadata_lv; /* thin pool metadata */
} else if (lv_is_thin_pool_metadata(lv)) {
lv_top = _get_top_layer_lv(lv); /* thin pool LV */
lv_meta = lv;
} else {
lv_resize: support resizing of cached volumes Automatically figure out resizable layer in the LV stack and resize it online. Split check for reshaped raids and postpone removal of unused space after finished reshaping after metadata archiving. Drop warning about unsupported automatic resize of monitored thin-pool. Currently there is not yet support for resize of writecache.
2021-02-07 22:12:00 +03:00
log_error("--poolmetadatasize can be used only with thin pools.");
return 0;
}
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
lp_meta = *lp;
_setup_params_for_extend_metadata(lv_meta, &lp_meta);
lp_meta.size = lp->poolmetadata_size;
lp_meta.sign = lp->poolmetadata_sign;
lp->poolmetadata_size = 0;
lp->poolmetadata_sign = 0;
} else if (lv_is_thin_pool(lv) && lp->poolmetadata_size) {
/* extend both thin pool data and metadata */
lv_top = lv;
lv_main = seg_lv(first_seg(lv), 0); /* thin pool data */
lv_meta = first_seg(lv)->metadata_lv; /* thin pool metadata */
lp_meta = *lp;
_setup_params_for_extend_metadata(lv_meta, &lp_meta);
lp_meta.size = lp->poolmetadata_size;
lp_meta.sign = lp->poolmetadata_sign;
lp->poolmetadata_size = 0;
lp->poolmetadata_sign = 0;
} else if (lv_is_thin_pool_metadata(lv)) {
/* extend only thin pool metadata */
lv_top = _get_top_layer_lv(lv); /* thin pool LV */
lv_meta = lv;
lp_meta = *lp;
_setup_params_for_extend_metadata(lv_meta, &lp_meta);
if (lp->poolmetadata_size) {
lp_meta.size = lp->poolmetadata_size;
lp_meta.size = lp->poolmetadata_sign;
lv_resize: support resizing of cached volumes Automatically figure out resizable layer in the LV stack and resize it online. Split check for reshaped raids and postpone removal of unused space after finished reshaping after metadata archiving. Drop warning about unsupported automatic resize of monitored thin-pool. Currently there is not yet support for resize of writecache.
2021-02-07 22:12:00 +03:00
lp->poolmetadata_size = 0;
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
lp->poolmetadata_sign = 0;
lvresize: support more resized LVs Add code to support more LVs to be resized through a same code path using a single lvresize_params struct. (Now it's used for thin-pool metadata resize, next user will be snapshot virtual resize). Update code to adjust percent amount resize for use_policies. Properly activate inactive thin-pool in case of any pool resize as the command should not 'deffer' this operation to next activation.
2016-06-23 00:32:35 +03:00
}
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
/* else lp_meta.extents|size from lp->extents|size above */
} else if (lv_is_thin_pool(lv)) {
/* extend thin pool data and possibly metadata */
lv_top = lv;
lv_main = seg_lv(first_seg(lv), 0);
/* Do not set lv_meta to the thin pool metadata here.
See below "Possibly enable lv_meta extend". */
cache: Disallow resizing of cache related LVs For now, disallow lvextend/lvreduce/lvresize of cache LVs, cache pool LVs, and cache pool sub-LVs.
2014-02-24 20:19:50 +04:00
}
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
/*
* None of the special cases above (selecting which LVs to extend
* depending on options set and type of LV) have applied, so this
* is the standard case.
*/
if (!lv_main && !lv_meta) {
lv_top = _get_top_layer_lv(lv);
lv_main_layer = lv;
lv_main = _get_resizable_layer_lv(lv_main_layer);
} else {
lv_main_layer = lv_main;
lv_meta_layer = lv_meta;
if (lv_main)
lv_main = _get_resizable_layer_lv(lv_main_layer);
if (lv_meta)
lv_meta = _get_resizable_layer_lv(lv_meta_layer);
}
/* Clear layer variables if no layer exists. */
if (lv_main_layer == lv_main)
lv_main_layer = NULL;
if (lv_meta_layer == lv_meta)
lv_meta_layer = NULL;
lv_resize: support resizing of cached volumes Automatically figure out resizable layer in the LV stack and resize it online. Split check for reshaped raids and postpone removal of unused space after finished reshaping after metadata archiving. Drop warning about unsupported automatic resize of monitored thin-pool. Currently there is not yet support for resize of writecache.
2021-02-07 22:12:00 +03:00
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
/*
* LVs to work with are now determined:
* lv_top is always set, it is not used to resize, but is used
* to reload dm devices for the lv.
* If lv_main is set, it is resized.
* If lv_meta is set, it is resized.
* If lv_meta is not set, it may be set below and resized.
*/
Add lvmlockd
2015-03-05 23:00:44 +03:00
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
if (!_lv_resize_check_used(lv_top))
thin: fix resize of stacked thin pool volume When the pool is created from non-linear target the more complex rules have to be used and stacking needs to properly decode args for _tdata LV. Also proper allocation policies are being used according to those set in lvm2 metadata for data and metadata LVs. Also properly check for active pool and extra code to active it temporarily. With this fix it's now possible to use: lvcreate -L20 -m2 -n pool vg --alloc anywhere lvcreate -L10 -m2 -n poolm vg --alloc anywhere lvconvert --thinpool vg/pool --poolmetadata vg/poolm lvresize -L+10 vg/pool
2013-09-06 12:54:50 +04:00
return_0;
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
if (lv_main && (lv_main != lv_top) && !_lv_resize_check_used(lv_main))
lv_resize: support resizing of cached volumes Automatically figure out resizable layer in the LV stack and resize it online. Split check for reshaped raids and postpone removal of unused space after finished reshaping after metadata archiving. Drop warning about unsupported automatic resize of monitored thin-pool. Currently there is not yet support for resize of writecache.
2021-02-07 22:12:00 +03:00
return_0;
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
/*
* Set a new size for lv_main.
*/
if (lv_main) {
/* sets lp extents and lp resize */
if (!_lv_resize_adjust_size(lv_main, lp, &main_size_matches))
return_0;
/* sanity check the result of adjust_size */
if (lp->extents == 0)
return_0;
/* adjust_size resolves LV_ANY to EXTEND|REDUCE */
if (lp->resize == LV_ANY)
return_0;
if (is_extend && (lp->resize != LV_EXTEND))
return_0;
if (is_reduce && (lp->resize != LV_REDUCE))
return_0;
is_extend = (lp->resize == LV_EXTEND);
is_reduce = (lp->resize == LV_REDUCE);
lvresize: fix zero size extension Commit ca878a3426197b629c76e98cfc049948da470cd7 changed behavior or resize operation. Later the code has been futher changed to skip fs resize completely when size of LV is already matching and finaly at the most recent resize changeset for resize the check for matching size has been eliminated as well so we ended with a request call to resize fs to 0 size in some cases. This commit reoders some test so the prompt happens just once before resize of possibly 2 related volumes. Also extra test for having LV already given size is added, and whole metadata update is skipped for this case as the only result would be an increment of seqno. However the filesystem is still resized when requested, so if the LV has some size and the resize is resolved to the same size, the filesystem resize is called so in case FS would not match, the resize will happen.
2016-07-13 17:23:25 +03:00
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
if (!_lv_resize_check_type(lv_main, lp))
return_0;
}
lvresize: fix zero size extension Commit ca878a3426197b629c76e98cfc049948da470cd7 changed behavior or resize operation. Later the code has been futher changed to skip fs resize completely when size of LV is already matching and finaly at the most recent resize changeset for resize the check for matching size has been eliminated as well so we ended with a request call to resize fs to 0 size in some cases. This commit reoders some test so the prompt happens just once before resize of possibly 2 related volumes. Also extra test for having LV already given size is added, and whole metadata update is skipped for this case as the only result would be an increment of seqno. However the filesystem is still resized when requested, so if the LV has some size and the resize is resolved to the same size, the filesystem resize is called so in case FS would not match, the resize will happen.
2016-07-13 17:23:25 +03:00
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
/*
* Possibly enable lv_meta extend if not already enabled. If lv_meta
* for a thin pool is not already being extended, and user requested
* extending the thin pool, then we may need to automatically include
* extending lv_meta in addition to lv_main (data), so that the
* metadata size is sufficient for the extended data size.
*
* If specific PVs were named to extend, this is taken to mean that
* only the thin pool data should be extended (using those PVs), and
* the thin pool metadata should not be automatically extended (since
* it would likely want to be extended using different PVs.)
*/
if (lv_is_thin_pool(lv_top) && is_extend && lv_main && !lv_meta && (&vg->pvs == lp->pvh)) {
struct lv_segment *tpseg = first_seg(lv_top);
uint64_t meta_size = estimate_thin_pool_metadata_size(lp->extents, vg->extent_size, tpseg->chunk_size);
if (meta_size > tpseg->metadata_lv->size) {
log_verbose("Extending thin pool metadata to %llu for larger data", (unsigned long long)meta_size);
lv_meta = tpseg->metadata_lv;
lp_meta = *lp;
_setup_params_for_extend_metadata(lv_meta, &lp_meta);
lp_meta.size = meta_size;
lp_meta.sign = SIGN_NONE;
/* meta may have a layer over it */
lv_meta_layer = lv_meta;
lv_meta = _get_resizable_layer_lv(lv_meta_layer);
if (lv_meta == lv_meta_layer)
lv_meta_layer = NULL;
lvresize: fix zero size extension Commit ca878a3426197b629c76e98cfc049948da470cd7 changed behavior or resize operation. Later the code has been futher changed to skip fs resize completely when size of LV is already matching and finaly at the most recent resize changeset for resize the check for matching size has been eliminated as well so we ended with a request call to resize fs to 0 size in some cases. This commit reoders some test so the prompt happens just once before resize of possibly 2 related volumes. Also extra test for having LV already given size is added, and whole metadata update is skipped for this case as the only result would be an increment of seqno. However the filesystem is still resized when requested, so if the LV has some size and the resize is resolved to the same size, the filesystem resize is called so in case FS would not match, the resize will happen.
2016-07-13 17:23:25 +03:00
}
}
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
/*
* Set a new size for lv_meta (extend only.)
*/
if (lv_meta) {
/* sets lp extents and lp resize */
if (!_lv_resize_adjust_size(lv_meta, &lp_meta, &meta_size_matches))
return_0;
/* sanity check the result of adjust_size */
if (lp_meta.extents == 0)
return_0;
/* adjust_size resolves lp_meta.resize to EXTEND|REDUCE */
/* _lv_resize_check_type errors if resize is EXTEND for thin meta */
if (!_lv_resize_check_type(lv_meta, &lp_meta))
return_0;
lvresize: fix zero size extension Commit ca878a3426197b629c76e98cfc049948da470cd7 changed behavior or resize operation. Later the code has been futher changed to skip fs resize completely when size of LV is already matching and finaly at the most recent resize changeset for resize the check for matching size has been eliminated as well so we ended with a request call to resize fs to 0 size in some cases. This commit reoders some test so the prompt happens just once before resize of possibly 2 related volumes. Also extra test for having LV already given size is added, and whole metadata update is skipped for this case as the only result would be an increment of seqno. However the filesystem is still resized when requested, so if the LV has some size and the resize is resolved to the same size, the filesystem resize is called so in case FS would not match, the resize will happen.
2016-07-13 17:23:25 +03:00
}
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
/*
* No resizing is needed.
*/
if ((main_size_matches && meta_size_matches) ||
(main_size_matches && !lv_meta) ||
(meta_size_matches && !lv_main)) {
log_error("No size change.");
return 0;
}
lvresize: support more resized LVs Add code to support more LVs to be resized through a same code path using a single lvresize_params struct. (Now it's used for thin-pool metadata resize, next user will be snapshot virtual resize). Update code to adjust percent amount resize for use_policies. Properly activate inactive thin-pool in case of any pool resize as the command should not 'deffer' this operation to next activation.
2016-06-23 00:32:35 +03:00
lvresize: move the lockd_lv earlier the lock should cover any potential activation, not just the resizing changes
2022-09-30 20:16:32 +03:00
/*
* If the LV is locked due to being active, this lock call is a no-op.
* Otherwise, this acquires a transient lock on the lv (not PERSISTENT)
*/
if (!lockd_lv_resize(cmd, lv_top, "ex", 0, lp))
return_0;
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
/*
* Active 'hidden' -tpool can be waiting for resize, but the pool LV
* itself might be inactive. Here plain suspend/resume would not work.
* So active temporarily pool LV (with on disk metadata) then use
* suspend and resume and deactivate pool LV, instead of searching for
* an active thin volume.
lvresize: add new options and defaults for fs handling The new option "--fs String" for lvresize/lvreduce/lvextend controls the handling of file systems before/after resizing the LV. --resizefs is the same as --fs resize. The new option "--fsmode String" can be used to control mounting and unmounting of the fs during resizing. Possible --fs values: checksize Only applies to reducing size; does nothing for extend. Check the fs size and reduce the LV if the fs is not using the affected space, i.e. the fs does not need to be shrunk. Fail the command without reducing the fs or LV if the fs is using the affected space. resize Resize the fs using the fs-specific resize command. This may include mounting, unmounting, or running fsck. See --fsmode to control mounting behavior, and --nofsck to disable fsck. resize_fsadm Use the old method of calling fsadm to handle the fs (deprecated.) Warning: this option does not prevent lvreduce from destroying file systems that are unmounted (or mounted if prompts are skipped.) ignore Resize the LV without checking for or handling a file system. Warning: using ignore when reducing the LV size may destroy the file system. Possible --fsmode values: manage Mount or unmount the fs as needed to resize the fs, and attempt to restore the original mount state at the end. nochange Do not mount or unmount the fs. If mounting or unmounting is required to resize the fs, then do not resize the fs or the LV and fail the command. offline Unmount the fs if it is mounted, and resize the fs while it is unmounted. If mounting is required to resize the fs, then do not resize the fs or the LV and fail the command. Notes on lvreduce: When no --fs or --resizefs option is specified: . lvextend default behavior is fs ignore. . lvreduce default behavior is fs checksize (includes activating the LV.) With the exception of --fs resize_fsadm|ignore, lvreduce requires the recent libblkid fields FSLASTBLOCK and FSBLOCKSIZE. FSLASTBLOCK*FSBLOCKSIZE is the last byte used by the fs on the LV, which determines if reducing the fs is necessary.
2022-06-14 23:20:21 +03:00
*
* FIXME: why are thin pools activated where other LV types return
* error if inactive?
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
*/
if (lv_is_thin_pool(lv_top) && !lv_is_active(lv_top)) {
lvresize: add new options and defaults for fs handling The new option "--fs String" for lvresize/lvreduce/lvextend controls the handling of file systems before/after resizing the LV. --resizefs is the same as --fs resize. The new option "--fsmode String" can be used to control mounting and unmounting of the fs during resizing. Possible --fs values: checksize Only applies to reducing size; does nothing for extend. Check the fs size and reduce the LV if the fs is not using the affected space, i.e. the fs does not need to be shrunk. Fail the command without reducing the fs or LV if the fs is using the affected space. resize Resize the fs using the fs-specific resize command. This may include mounting, unmounting, or running fsck. See --fsmode to control mounting behavior, and --nofsck to disable fsck. resize_fsadm Use the old method of calling fsadm to handle the fs (deprecated.) Warning: this option does not prevent lvreduce from destroying file systems that are unmounted (or mounted if prompts are skipped.) ignore Resize the LV without checking for or handling a file system. Warning: using ignore when reducing the LV size may destroy the file system. Possible --fsmode values: manage Mount or unmount the fs as needed to resize the fs, and attempt to restore the original mount state at the end. nochange Do not mount or unmount the fs. If mounting or unmounting is required to resize the fs, then do not resize the fs or the LV and fail the command. offline Unmount the fs if it is mounted, and resize the fs while it is unmounted. If mounting is required to resize the fs, then do not resize the fs or the LV and fail the command. Notes on lvreduce: When no --fs or --resizefs option is specified: . lvextend default behavior is fs ignore. . lvreduce default behavior is fs checksize (includes activating the LV.) With the exception of --fs resize_fsadm|ignore, lvreduce requires the recent libblkid fields FSLASTBLOCK and FSBLOCKSIZE. FSLASTBLOCK*FSBLOCKSIZE is the last byte used by the fs on the LV, which determines if reducing the fs is necessary.
2022-06-14 23:20:21 +03:00
if (!activation()) {
log_error("Cannot activate to resize %s without using device-mapper kernel driver.",
display_lvname(lv_top));
return 0;
lvresize: support more resized LVs Add code to support more LVs to be resized through a same code path using a single lvresize_params struct. (Now it's used for thin-pool metadata resize, next user will be snapshot virtual resize). Update code to adjust percent amount resize for use_policies. Properly activate inactive thin-pool in case of any pool resize as the command should not 'deffer' this operation to next activation.
2016-06-23 00:32:35 +03:00
}
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
if (!activate_lv(cmd, lv_top)) {
log_error("Failed to activate %s.", display_lvname(lv_top));
lvresize: add new options and defaults for fs handling The new option "--fs String" for lvresize/lvreduce/lvextend controls the handling of file systems before/after resizing the LV. --resizefs is the same as --fs resize. The new option "--fsmode String" can be used to control mounting and unmounting of the fs during resizing. Possible --fs values: checksize Only applies to reducing size; does nothing for extend. Check the fs size and reduce the LV if the fs is not using the affected space, i.e. the fs does not need to be shrunk. Fail the command without reducing the fs or LV if the fs is using the affected space. resize Resize the fs using the fs-specific resize command. This may include mounting, unmounting, or running fsck. See --fsmode to control mounting behavior, and --nofsck to disable fsck. resize_fsadm Use the old method of calling fsadm to handle the fs (deprecated.) Warning: this option does not prevent lvreduce from destroying file systems that are unmounted (or mounted if prompts are skipped.) ignore Resize the LV without checking for or handling a file system. Warning: using ignore when reducing the LV size may destroy the file system. Possible --fsmode values: manage Mount or unmount the fs as needed to resize the fs, and attempt to restore the original mount state at the end. nochange Do not mount or unmount the fs. If mounting or unmounting is required to resize the fs, then do not resize the fs or the LV and fail the command. offline Unmount the fs if it is mounted, and resize the fs while it is unmounted. If mounting is required to resize the fs, then do not resize the fs or the LV and fail the command. Notes on lvreduce: When no --fs or --resizefs option is specified: . lvextend default behavior is fs ignore. . lvreduce default behavior is fs checksize (includes activating the LV.) With the exception of --fs resize_fsadm|ignore, lvreduce requires the recent libblkid fields FSLASTBLOCK and FSBLOCKSIZE. FSLASTBLOCK*FSBLOCKSIZE is the last byte used by the fs on the LV, which determines if reducing the fs is necessary.
2022-06-14 23:20:21 +03:00
return 0;
thin: fix resize of stacked thin pool volume When the pool is created from non-linear target the more complex rules have to be used and stacking needs to properly decode args for _tdata LV. Also proper allocation policies are being used according to those set in lvm2 metadata for data and metadata LVs. Also properly check for active pool and extra code to active it temporarily. With this fix it's now possible to use: lvcreate -L20 -m2 -n pool vg --alloc anywhere lvcreate -L10 -m2 -n poolm vg --alloc anywhere lvconvert --thinpool vg/pool --poolmetadata vg/poolm lvresize -L+10 vg/pool
2013-09-06 12:54:50 +04:00
}
lvresize: add new options and defaults for fs handling The new option "--fs String" for lvresize/lvreduce/lvextend controls the handling of file systems before/after resizing the LV. --resizefs is the same as --fs resize. The new option "--fsmode String" can be used to control mounting and unmounting of the fs during resizing. Possible --fs values: checksize Only applies to reducing size; does nothing for extend. Check the fs size and reduce the LV if the fs is not using the affected space, i.e. the fs does not need to be shrunk. Fail the command without reducing the fs or LV if the fs is using the affected space. resize Resize the fs using the fs-specific resize command. This may include mounting, unmounting, or running fsck. See --fsmode to control mounting behavior, and --nofsck to disable fsck. resize_fsadm Use the old method of calling fsadm to handle the fs (deprecated.) Warning: this option does not prevent lvreduce from destroying file systems that are unmounted (or mounted if prompts are skipped.) ignore Resize the LV without checking for or handling a file system. Warning: using ignore when reducing the LV size may destroy the file system. Possible --fsmode values: manage Mount or unmount the fs as needed to resize the fs, and attempt to restore the original mount state at the end. nochange Do not mount or unmount the fs. If mounting or unmounting is required to resize the fs, then do not resize the fs or the LV and fail the command. offline Unmount the fs if it is mounted, and resize the fs while it is unmounted. If mounting is required to resize the fs, then do not resize the fs or the LV and fail the command. Notes on lvreduce: When no --fs or --resizefs option is specified: . lvextend default behavior is fs ignore. . lvreduce default behavior is fs checksize (includes activating the LV.) With the exception of --fs resize_fsadm|ignore, lvreduce requires the recent libblkid fields FSLASTBLOCK and FSBLOCKSIZE. FSLASTBLOCK*FSBLOCKSIZE is the last byte used by the fs on the LV, which determines if reducing the fs is necessary.
2022-06-14 23:20:21 +03:00
if (!sync_local_dev_names(cmd))
stack;
lvresize: support more resized LVs Add code to support more LVs to be resized through a same code path using a single lvresize_params struct. (Now it's used for thin-pool metadata resize, next user will be snapshot virtual resize). Update code to adjust percent amount resize for use_policies. Properly activate inactive thin-pool in case of any pool resize as the command should not 'deffer' this operation to next activation.
2016-06-23 00:32:35 +03:00
activated = 1;
thin: fix resize of stacked thin pool volume When the pool is created from non-linear target the more complex rules have to be used and stacking needs to properly decode args for _tdata LV. Also proper allocation policies are being used according to those set in lvm2 metadata for data and metadata LVs. Also properly check for active pool and extra code to active it temporarily. With this fix it's now possible to use: lvcreate -L20 -m2 -n pool vg --alloc anywhere lvcreate -L10 -m2 -n poolm vg --alloc anywhere lvconvert --thinpool vg/pool --poolmetadata vg/poolm lvresize -L+10 vg/pool
2013-09-06 12:54:50 +04:00
}
lvresize: add new options and defaults for fs handling The new option "--fs String" for lvresize/lvreduce/lvextend controls the handling of file systems before/after resizing the LV. --resizefs is the same as --fs resize. The new option "--fsmode String" can be used to control mounting and unmounting of the fs during resizing. Possible --fs values: checksize Only applies to reducing size; does nothing for extend. Check the fs size and reduce the LV if the fs is not using the affected space, i.e. the fs does not need to be shrunk. Fail the command without reducing the fs or LV if the fs is using the affected space. resize Resize the fs using the fs-specific resize command. This may include mounting, unmounting, or running fsck. See --fsmode to control mounting behavior, and --nofsck to disable fsck. resize_fsadm Use the old method of calling fsadm to handle the fs (deprecated.) Warning: this option does not prevent lvreduce from destroying file systems that are unmounted (or mounted if prompts are skipped.) ignore Resize the LV without checking for or handling a file system. Warning: using ignore when reducing the LV size may destroy the file system. Possible --fsmode values: manage Mount or unmount the fs as needed to resize the fs, and attempt to restore the original mount state at the end. nochange Do not mount or unmount the fs. If mounting or unmounting is required to resize the fs, then do not resize the fs or the LV and fail the command. offline Unmount the fs if it is mounted, and resize the fs while it is unmounted. If mounting is required to resize the fs, then do not resize the fs or the LV and fail the command. Notes on lvreduce: When no --fs or --resizefs option is specified: . lvextend default behavior is fs ignore. . lvreduce default behavior is fs checksize (includes activating the LV.) With the exception of --fs resize_fsadm|ignore, lvreduce requires the recent libblkid fields FSLASTBLOCK and FSBLOCKSIZE. FSLASTBLOCK*FSBLOCKSIZE is the last byte used by the fs on the LV, which determines if reducing the fs is necessary.
2022-06-14 23:20:21 +03:00
/*
* Disable fsopt checksize for lvextend.
*/
if (is_extend && !strcmp(lp->fsopt, "checksize"))
lp->fsopt[0] = '\0';
/*
* Disable fsopt if LV type cannot hold a file system.
*/
if (lp->fsopt[0] &&
!(lv_is_linear(lv) || lv_is_striped(lv) || lv_is_raid(lv) ||
lv_is_mirror(lv) || lv_is_thin_volume(lv) || lv_is_vdo(lv) ||
lv_is_cache(lv) || lv_is_writecache(lv))) {
log_print_unless_silent("Ignoring fs resizing options for LV type %s.",
seg ? seg->segtype->name : "unknown");
lp->fsopt[0] = '\0';
}
/*
* Using an option to resize the fs has always/traditionally required
* the LV to already be active, so keep that behavior. Reducing an
* inactive LV will activate the LV to look for a fs that would be
* damaged.
*/
is_active = lv_is_active(lv_top);
if (is_reduce && !is_active && !strcmp(lp->fsopt, "checksize")) {
lvreduce: require active LV when no fs option is used Without an --fs option set, make lvreduce of an inactive LV fail and report that the LV must be active.
2022-10-11 19:50:47 +03:00
if (!lp->user_set_fs) {
lvreduce: change error message about --fs options
2022-10-12 18:05:14 +03:00
log_error("The LV must be active to safely reduce (see --fs options.)");
lvreduce: require active LV when no fs option is used Without an --fs option set, make lvreduce of an inactive LV fail and report that the LV must be active.
2022-10-11 19:50:47 +03:00
goto out;
}
lvreduce: use temporary flag when activating lv to check for fs This flag is meant to suppress udev processing of the LV.
2022-09-27 20:59:17 +03:00
lv_top->status |= LV_TEMPORARY;
lvresize: add new options and defaults for fs handling The new option "--fs String" for lvresize/lvreduce/lvextend controls the handling of file systems before/after resizing the LV. --resizefs is the same as --fs resize. The new option "--fsmode String" can be used to control mounting and unmounting of the fs during resizing. Possible --fs values: checksize Only applies to reducing size; does nothing for extend. Check the fs size and reduce the LV if the fs is not using the affected space, i.e. the fs does not need to be shrunk. Fail the command without reducing the fs or LV if the fs is using the affected space. resize Resize the fs using the fs-specific resize command. This may include mounting, unmounting, or running fsck. See --fsmode to control mounting behavior, and --nofsck to disable fsck. resize_fsadm Use the old method of calling fsadm to handle the fs (deprecated.) Warning: this option does not prevent lvreduce from destroying file systems that are unmounted (or mounted if prompts are skipped.) ignore Resize the LV without checking for or handling a file system. Warning: using ignore when reducing the LV size may destroy the file system. Possible --fsmode values: manage Mount or unmount the fs as needed to resize the fs, and attempt to restore the original mount state at the end. nochange Do not mount or unmount the fs. If mounting or unmounting is required to resize the fs, then do not resize the fs or the LV and fail the command. offline Unmount the fs if it is mounted, and resize the fs while it is unmounted. If mounting is required to resize the fs, then do not resize the fs or the LV and fail the command. Notes on lvreduce: When no --fs or --resizefs option is specified: . lvextend default behavior is fs ignore. . lvreduce default behavior is fs checksize (includes activating the LV.) With the exception of --fs resize_fsadm|ignore, lvreduce requires the recent libblkid fields FSLASTBLOCK and FSBLOCKSIZE. FSLASTBLOCK*FSBLOCKSIZE is the last byte used by the fs on the LV, which determines if reducing the fs is necessary.
2022-06-14 23:20:21 +03:00
if (!activate_lv(cmd, lv_top)) {
log_error("Failed to activate %s to check for fs.", display_lvname(lv_top));
goto out;
}
lvreduce: use temporary flag when activating lv to check for fs This flag is meant to suppress udev processing of the LV.
2022-09-27 20:59:17 +03:00
lv_top->status &= ~LV_TEMPORARY;
lvresize: add new options and defaults for fs handling The new option "--fs String" for lvresize/lvreduce/lvextend controls the handling of file systems before/after resizing the LV. --resizefs is the same as --fs resize. The new option "--fsmode String" can be used to control mounting and unmounting of the fs during resizing. Possible --fs values: checksize Only applies to reducing size; does nothing for extend. Check the fs size and reduce the LV if the fs is not using the affected space, i.e. the fs does not need to be shrunk. Fail the command without reducing the fs or LV if the fs is using the affected space. resize Resize the fs using the fs-specific resize command. This may include mounting, unmounting, or running fsck. See --fsmode to control mounting behavior, and --nofsck to disable fsck. resize_fsadm Use the old method of calling fsadm to handle the fs (deprecated.) Warning: this option does not prevent lvreduce from destroying file systems that are unmounted (or mounted if prompts are skipped.) ignore Resize the LV without checking for or handling a file system. Warning: using ignore when reducing the LV size may destroy the file system. Possible --fsmode values: manage Mount or unmount the fs as needed to resize the fs, and attempt to restore the original mount state at the end. nochange Do not mount or unmount the fs. If mounting or unmounting is required to resize the fs, then do not resize the fs or the LV and fail the command. offline Unmount the fs if it is mounted, and resize the fs while it is unmounted. If mounting is required to resize the fs, then do not resize the fs or the LV and fail the command. Notes on lvreduce: When no --fs or --resizefs option is specified: . lvextend default behavior is fs ignore. . lvreduce default behavior is fs checksize (includes activating the LV.) With the exception of --fs resize_fsadm|ignore, lvreduce requires the recent libblkid fields FSLASTBLOCK and FSBLOCKSIZE. FSLASTBLOCK*FSBLOCKSIZE is the last byte used by the fs on the LV, which determines if reducing the fs is necessary.
2022-06-14 23:20:21 +03:00
if (!sync_local_dev_names(cmd))
stack;
activated_checksize = 1;
} else if (lp->fsopt[0] && !is_active) {
log_error("Logical volume %s must be active for file system %s.",
display_lvname(lv_top), lp->fsopt);
goto out;
}
/*
* Return an error without resizing the LV if the user requested
* a file system resize when no file system exists on the LV.
* (fs checksize does not require a fs to exist.)
*/
if (lp->fsopt[0] && strcmp(lp->fsopt, "checksize") && lp->user_set_fs) {
char lv_path[PATH_MAX];
char fstype[FSTYPE_MAX];
int nofs = 0;
if (dm_snprintf(lv_path, sizeof(lv_path), "%s%s/%s", cmd->dev_dir,
lv_top->vg->name, lv_top->name) < 0) {
log_error("Couldn't create LV path for %s.", display_lvname(lv_top));
goto out;
}
if (!fs_block_size_and_type(lv_path, NULL, fstype, &nofs) || nofs) {
log_error("File system not found for --resizefs or --fs options.");
goto out;
}
lvresize: fail early if crypt device is missing If extending an LV with crypto_LUKS on it, and the crypt device is missing, then fail the command before extending the LV.
2023-01-31 02:12:11 +03:00
if (!strcmp(fstype, "crypto_LUKS") && !lv_crypt_is_active(cmd, lv_path)) {
log_error("LUKS dm-crypt device must be active for fs resize.");
goto out;
}
lvresize: fail early if mounted LV was renamed If a mounted LV is renamed, then fs resizing utilities will fail, so detect this condition and fail the command before any changes are made.
2023-01-26 23:00:00 +03:00
/* FS utils will fail if LVs were renamed while mounted. */
if (fs_mount_state_is_misnamed(cmd, lv_top, lv_path, fstype))
goto_out;
lvresize: add new options and defaults for fs handling The new option "--fs String" for lvresize/lvreduce/lvextend controls the handling of file systems before/after resizing the LV. --resizefs is the same as --fs resize. The new option "--fsmode String" can be used to control mounting and unmounting of the fs during resizing. Possible --fs values: checksize Only applies to reducing size; does nothing for extend. Check the fs size and reduce the LV if the fs is not using the affected space, i.e. the fs does not need to be shrunk. Fail the command without reducing the fs or LV if the fs is using the affected space. resize Resize the fs using the fs-specific resize command. This may include mounting, unmounting, or running fsck. See --fsmode to control mounting behavior, and --nofsck to disable fsck. resize_fsadm Use the old method of calling fsadm to handle the fs (deprecated.) Warning: this option does not prevent lvreduce from destroying file systems that are unmounted (or mounted if prompts are skipped.) ignore Resize the LV without checking for or handling a file system. Warning: using ignore when reducing the LV size may destroy the file system. Possible --fsmode values: manage Mount or unmount the fs as needed to resize the fs, and attempt to restore the original mount state at the end. nochange Do not mount or unmount the fs. If mounting or unmounting is required to resize the fs, then do not resize the fs or the LV and fail the command. offline Unmount the fs if it is mounted, and resize the fs while it is unmounted. If mounting is required to resize the fs, then do not resize the fs or the LV and fail the command. Notes on lvreduce: When no --fs or --resizefs option is specified: . lvextend default behavior is fs ignore. . lvreduce default behavior is fs checksize (includes activating the LV.) With the exception of --fs resize_fsadm|ignore, lvreduce requires the recent libblkid fields FSLASTBLOCK and FSBLOCKSIZE. FSLASTBLOCK*FSBLOCKSIZE is the last byte used by the fs on the LV, which determines if reducing the fs is necessary.
2022-06-14 23:20:21 +03:00
}
/*
* Warn and confirm if checksize has been disabled for reduce.
*/
if (is_reduce && !lp->fsopt[0] && !_lv_reduce_confirmation(lv_top, lp))
goto_out;
/* Part of old approach to fs handling using fsadm. */
if (!strcmp(lp->fsopt, "resize_fsadm") && !lp->nofsck &&
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
!_fsadm_cmd(FSADM_CMD_CHECK, lv_top, 0, lp->yes, lp->force, &status)) {
if (status != FSADM_CHECK_FAILS_FOR_MOUNTED) {
log_error("Filesystem check failed.");
goto out;
vdo: discard reduced area Implement sending discard to reduced LV area.
2019-01-21 14:20:07 +03:00
}
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
}
lvresize: add new options and defaults for fs handling The new option "--fs String" for lvresize/lvreduce/lvextend controls the handling of file systems before/after resizing the LV. --resizefs is the same as --fs resize. The new option "--fsmode String" can be used to control mounting and unmounting of the fs during resizing. Possible --fs values: checksize Only applies to reducing size; does nothing for extend. Check the fs size and reduce the LV if the fs is not using the affected space, i.e. the fs does not need to be shrunk. Fail the command without reducing the fs or LV if the fs is using the affected space. resize Resize the fs using the fs-specific resize command. This may include mounting, unmounting, or running fsck. See --fsmode to control mounting behavior, and --nofsck to disable fsck. resize_fsadm Use the old method of calling fsadm to handle the fs (deprecated.) Warning: this option does not prevent lvreduce from destroying file systems that are unmounted (or mounted if prompts are skipped.) ignore Resize the LV without checking for or handling a file system. Warning: using ignore when reducing the LV size may destroy the file system. Possible --fsmode values: manage Mount or unmount the fs as needed to resize the fs, and attempt to restore the original mount state at the end. nochange Do not mount or unmount the fs. If mounting or unmounting is required to resize the fs, then do not resize the fs or the LV and fail the command. offline Unmount the fs if it is mounted, and resize the fs while it is unmounted. If mounting is required to resize the fs, then do not resize the fs or the LV and fail the command. Notes on lvreduce: When no --fs or --resizefs option is specified: . lvextend default behavior is fs ignore. . lvreduce default behavior is fs checksize (includes activating the LV.) With the exception of --fs resize_fsadm|ignore, lvreduce requires the recent libblkid fields FSLASTBLOCK and FSBLOCKSIZE. FSLASTBLOCK*FSBLOCKSIZE is the last byte used by the fs on the LV, which determines if reducing the fs is necessary.
2022-06-14 23:20:21 +03:00
if (is_reduce && lp->fsopt[0]) {
if (!strcmp(lp->fsopt, "resize_fsadm")) {
/* Old approach to fs handling using fsadm. */
if (!_fsadm_cmd(FSADM_CMD_RESIZE, lv_top, lp->extents, lp->yes, lp->force, NULL)) {
log_error("Filesystem resize failed.");
goto out;
}
} else {
/* New approach to fs handling using fs info. */
if (!_fs_reduce(cmd, lv_top, lp))
goto_out;
}
if (activated_checksize && !deactivate_lv(cmd, lv_top))
log_warn("Problem deactivating %s.", display_lvname(lv_top));
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
}
vdo: discard reduced area Implement sending discard to reduced LV area.
2019-01-21 14:20:07 +03:00
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
/*
* Send DISCARD/TRIM to reduced area of VDO volumes
* TODO: enable thin and provide
* TODO2: we need polling method
*/
if (is_reduce && lv_is_vdo(lv_top) && !_lv_reduce_vdo_discard(cmd, lv_top, lp))
goto_out;
vdo: discard reduced area Implement sending discard to reduced LV area.
2019-01-21 14:20:07 +03:00
lvresize: support more resized LVs Add code to support more LVs to be resized through a same code path using a single lvresize_params struct. (Now it's used for thin-pool metadata resize, next user will be snapshot virtual resize). Update code to adjust percent amount resize for use_policies. Properly activate inactive thin-pool in case of any pool resize as the command should not 'deffer' this operation to next activation.
2016-06-23 00:32:35 +03:00
/*
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
* Remove any striped raid reshape space for LV resizing (not common).
lvresize: support more resized LVs Add code to support more LVs to be resized through a same code path using a single lvresize_params struct. (Now it's used for thin-pool metadata resize, next user will be snapshot virtual resize). Update code to adjust percent amount resize for use_policies. Properly activate inactive thin-pool in case of any pool resize as the command should not 'deffer' this operation to next activation.
2016-06-23 00:32:35 +03:00
*/
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
if (lv_meta && first_seg(lv_meta)->reshape_len && !lv_raid_free_reshape_space(lv_meta))
lvresize: add new options and defaults for fs handling The new option "--fs String" for lvresize/lvreduce/lvextend controls the handling of file systems before/after resizing the LV. --resizefs is the same as --fs resize. The new option "--fsmode String" can be used to control mounting and unmounting of the fs during resizing. Possible --fs values: checksize Only applies to reducing size; does nothing for extend. Check the fs size and reduce the LV if the fs is not using the affected space, i.e. the fs does not need to be shrunk. Fail the command without reducing the fs or LV if the fs is using the affected space. resize Resize the fs using the fs-specific resize command. This may include mounting, unmounting, or running fsck. See --fsmode to control mounting behavior, and --nofsck to disable fsck. resize_fsadm Use the old method of calling fsadm to handle the fs (deprecated.) Warning: this option does not prevent lvreduce from destroying file systems that are unmounted (or mounted if prompts are skipped.) ignore Resize the LV without checking for or handling a file system. Warning: using ignore when reducing the LV size may destroy the file system. Possible --fsmode values: manage Mount or unmount the fs as needed to resize the fs, and attempt to restore the original mount state at the end. nochange Do not mount or unmount the fs. If mounting or unmounting is required to resize the fs, then do not resize the fs or the LV and fail the command. offline Unmount the fs if it is mounted, and resize the fs while it is unmounted. If mounting is required to resize the fs, then do not resize the fs or the LV and fail the command. Notes on lvreduce: When no --fs or --resizefs option is specified: . lvextend default behavior is fs ignore. . lvreduce default behavior is fs checksize (includes activating the LV.) With the exception of --fs resize_fsadm|ignore, lvreduce requires the recent libblkid fields FSLASTBLOCK and FSBLOCKSIZE. FSLASTBLOCK*FSBLOCKSIZE is the last byte used by the fs on the LV, which determines if reducing the fs is necessary.
2022-06-14 23:20:21 +03:00
goto_out;
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
if (lv_main && first_seg(lv_main)->reshape_len && !lv_raid_free_reshape_space(lv_main))
lvresize: add new options and defaults for fs handling The new option "--fs String" for lvresize/lvreduce/lvextend controls the handling of file systems before/after resizing the LV. --resizefs is the same as --fs resize. The new option "--fsmode String" can be used to control mounting and unmounting of the fs during resizing. Possible --fs values: checksize Only applies to reducing size; does nothing for extend. Check the fs size and reduce the LV if the fs is not using the affected space, i.e. the fs does not need to be shrunk. Fail the command without reducing the fs or LV if the fs is using the affected space. resize Resize the fs using the fs-specific resize command. This may include mounting, unmounting, or running fsck. See --fsmode to control mounting behavior, and --nofsck to disable fsck. resize_fsadm Use the old method of calling fsadm to handle the fs (deprecated.) Warning: this option does not prevent lvreduce from destroying file systems that are unmounted (or mounted if prompts are skipped.) ignore Resize the LV without checking for or handling a file system. Warning: using ignore when reducing the LV size may destroy the file system. Possible --fsmode values: manage Mount or unmount the fs as needed to resize the fs, and attempt to restore the original mount state at the end. nochange Do not mount or unmount the fs. If mounting or unmounting is required to resize the fs, then do not resize the fs or the LV and fail the command. offline Unmount the fs if it is mounted, and resize the fs while it is unmounted. If mounting is required to resize the fs, then do not resize the fs or the LV and fail the command. Notes on lvreduce: When no --fs or --resizefs option is specified: . lvextend default behavior is fs ignore. . lvreduce default behavior is fs checksize (includes activating the LV.) With the exception of --fs resize_fsadm|ignore, lvreduce requires the recent libblkid fields FSLASTBLOCK and FSBLOCKSIZE. FSLASTBLOCK*FSBLOCKSIZE is the last byte used by the fs on the LV, which determines if reducing the fs is necessary.
2022-06-14 23:20:21 +03:00
goto_out;
lvresize: support more resized LVs Add code to support more LVs to be resized through a same code path using a single lvresize_params struct. (Now it's used for thin-pool metadata resize, next user will be snapshot virtual resize). Update code to adjust percent amount resize for use_policies. Properly activate inactive thin-pool in case of any pool resize as the command should not 'deffer' this operation to next activation.
2016-06-23 00:32:35 +03:00
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
/*
* The core of the actual lv resizing.
* Allocate or free extents in the VG, adjust LV segments to reflect
* new requested size, write VG metadata, reload the dm device stack
* (reload from the top LV.) Do lv_meta first.
* When extending lv_meta, also extend (or create) the pool's spare
* meta lv to match the size of lv_meta (only do this when the
* command is not limited to allocating from specific PVs.)
*/
lvresize: support more resized LVs Add code to support more LVs to be resized through a same code path using a single lvresize_params struct. (Now it's used for thin-pool metadata resize, next user will be snapshot virtual resize). Update code to adjust percent amount resize for use_policies. Properly activate inactive thin-pool in case of any pool resize as the command should not 'deffer' this operation to next activation.
2016-06-23 00:32:35 +03:00
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
if (!lv_meta)
goto do_main;
if (!_lv_resize_volume(lv_meta, &lp_meta, lp->pvh))
goto_out;
if (!lp_meta.size_changed)
goto do_main;
if ((&vg->pvs == lp->pvh) && !handle_pool_metadata_spare(vg, 0, lp->pvh, 1))
stack;
if (!lv_update_and_reload(lv_top))
goto_out;
log_debug("Resized thin pool metadata %s to %u extents.", display_lvname(lv_meta), lp_meta.extents);
lvresize: support more resized LVs Add code to support more LVs to be resized through a same code path using a single lvresize_params struct. (Now it's used for thin-pool metadata resize, next user will be snapshot virtual resize). Update code to adjust percent amount resize for use_policies. Properly activate inactive thin-pool in case of any pool resize as the command should not 'deffer' this operation to next activation.
2016-06-23 00:32:35 +03:00
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
do_main:
lvresize: support more resized LVs Add code to support more LVs to be resized through a same code path using a single lvresize_params struct. (Now it's used for thin-pool metadata resize, next user will be snapshot virtual resize). Update code to adjust percent amount resize for use_policies. Properly activate inactive thin-pool in case of any pool resize as the command should not 'deffer' this operation to next activation.
2016-06-23 00:32:35 +03:00
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
if (!lv_main)
goto end_main;
if (!_lv_resize_volume(lv_main, lp, lp->pvh))
goto_out;
lvresize: fix zero size extension Commit ca878a3426197b629c76e98cfc049948da470cd7 changed behavior or resize operation. Later the code has been futher changed to skip fs resize completely when size of LV is already matching and finaly at the most recent resize changeset for resize the check for matching size has been eliminated as well so we ended with a request call to resize fs to 0 size in some cases. This commit reoders some test so the prompt happens just once before resize of possibly 2 related volumes. Also extra test for having LV already given size is added, and whole metadata update is skipped for this case as the only result would be an increment of seqno. However the filesystem is still resized when requested, so if the LV has some size and the resize is resolved to the same size, the filesystem resize is called so in case FS would not match, the resize will happen.
2016-07-13 17:23:25 +03:00
if (!lp->size_changed)
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
goto_out;
if (!lv_update_and_reload(lv_top))
goto_out;
log_debug("Resized %s to %u extents.", display_lvname(lv_main), lp->extents);
lvresize: fix zero size extension Commit ca878a3426197b629c76e98cfc049948da470cd7 changed behavior or resize operation. Later the code has been futher changed to skip fs resize completely when size of LV is already matching and finaly at the most recent resize changeset for resize the check for matching size has been eliminated as well so we ended with a request call to resize fs to 0 size in some cases. This commit reoders some test so the prompt happens just once before resize of possibly 2 related volumes. Also extra test for having LV already given size is added, and whole metadata update is skipped for this case as the only result would be an increment of seqno. However the filesystem is still resized when requested, so if the LV has some size and the resize is resolved to the same size, the filesystem resize is called so in case FS would not match, the resize will happen.
2016-07-13 17:23:25 +03:00
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
end_main:
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
/*
* other maintenance:
* - update lvm pool metadata (drop messages).
* - print warnings about overprovisioning.
* - stop monitoring cow snapshot larger than origin
*/
if (lv_is_thin_pool(lv_top)) {
if (!update_thin_pool_lv(lv_top, 1))
goto_out;
}
lvextend: fix overprovisioning check for thin lvs 18722dfdf4d3 lvresize: restructure code mistakenly changed the overprovisioning check from applying to all lv_is_thin_type lvs to only lv_is_thin_pool lvs, so it no longer applied when extending thin lvs. The result was missing warning messages when extending thin lvs.
2022-12-15 18:57:04 +03:00
if (lv_is_thin_type(lv_top) && is_extend)
thin_pool_check_overprovisioning(lv_top);
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
if (lv_main && lv_is_cow_covering_origin(lv_main)) {
if (!monitor_dev_for_events(cmd, lv_main, 0, 0))
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
stack;
thin: fix resize of stacked thin pool volume When the pool is created from non-linear target the more complex rules have to be used and stacking needs to properly decode args for _tdata LV. Also proper allocation policies are being used according to those set in lvm2 metadata for data and metadata LVs. Also properly check for active pool and extra code to active it temporarily. With this fix it's now possible to use: lvcreate -L20 -m2 -n pool vg --alloc anywhere lvcreate -L10 -m2 -n poolm vg --alloc anywhere lvconvert --thinpool vg/pool --poolmetadata vg/poolm lvresize -L+10 vg/pool
2013-09-06 12:54:50 +04:00
}
thin: check for overprovisioning only once
2021-02-07 02:37:37 +03:00
lvresize: add new options and defaults for fs handling The new option "--fs String" for lvresize/lvreduce/lvextend controls the handling of file systems before/after resizing the LV. --resizefs is the same as --fs resize. The new option "--fsmode String" can be used to control mounting and unmounting of the fs during resizing. Possible --fs values: checksize Only applies to reducing size; does nothing for extend. Check the fs size and reduce the LV if the fs is not using the affected space, i.e. the fs does not need to be shrunk. Fail the command without reducing the fs or LV if the fs is using the affected space. resize Resize the fs using the fs-specific resize command. This may include mounting, unmounting, or running fsck. See --fsmode to control mounting behavior, and --nofsck to disable fsck. resize_fsadm Use the old method of calling fsadm to handle the fs (deprecated.) Warning: this option does not prevent lvreduce from destroying file systems that are unmounted (or mounted if prompts are skipped.) ignore Resize the LV without checking for or handling a file system. Warning: using ignore when reducing the LV size may destroy the file system. Possible --fsmode values: manage Mount or unmount the fs as needed to resize the fs, and attempt to restore the original mount state at the end. nochange Do not mount or unmount the fs. If mounting or unmounting is required to resize the fs, then do not resize the fs or the LV and fail the command. offline Unmount the fs if it is mounted, and resize the fs while it is unmounted. If mounting is required to resize the fs, then do not resize the fs or the LV and fail the command. Notes on lvreduce: When no --fs or --resizefs option is specified: . lvextend default behavior is fs ignore. . lvreduce default behavior is fs checksize (includes activating the LV.) With the exception of --fs resize_fsadm|ignore, lvreduce requires the recent libblkid fields FSLASTBLOCK and FSBLOCKSIZE. FSLASTBLOCK*FSBLOCKSIZE is the last byte used by the fs on the LV, which determines if reducing the fs is necessary.
2022-06-14 23:20:21 +03:00
if (is_extend && lp->fsopt[0]) {
if (!strcmp(lp->fsopt, "resize_fsadm")) {
/* Old approach to fs handling using fsadm. */
if (!_fsadm_cmd(FSADM_CMD_RESIZE, lv_top, lp->extents, lp->yes, lp->force, NULL)) {
log_error("File system extend error.");
lp->extend_fs_error = 1;
goto out;
}
} else {
/* New approach to fs handling using fs info. */
if (!_fs_extend(cmd, lv_top, lp)) {
log_error("File system extend error.");
lp->extend_fs_error = 1;
goto out;
}
}
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
}
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
lvresize: support more resized LVs Add code to support more LVs to be resized through a same code path using a single lvresize_params struct. (Now it's used for thin-pool metadata resize, next user will be snapshot virtual resize). Update code to adjust percent amount resize for use_policies. Properly activate inactive thin-pool in case of any pool resize as the command should not 'deffer' this operation to next activation.
2016-06-23 00:32:35 +03:00
ret = 1;
lv_manip: add synchronizations New udev in rawhide seems to be 'dropping' udev rule operations for devices that are no longer existing - while this is 'probably' a bug - it's revealing moments in lvm2 that likely should not run in a single transaction and we should wait for a cookie before submitting more work. TODO: it seem more 'error' paths should always include synchronization before starting deactivating 'just activated' devices. We should probably figure out some 'automatic' solution for this instead of placing sync_local_dev_name() all over the place...
2019-08-26 14:28:17 +03:00
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
out:
lvresize: add new options and defaults for fs handling The new option "--fs String" for lvresize/lvreduce/lvextend controls the handling of file systems before/after resizing the LV. --resizefs is the same as --fs resize. The new option "--fsmode String" can be used to control mounting and unmounting of the fs during resizing. Possible --fs values: checksize Only applies to reducing size; does nothing for extend. Check the fs size and reduce the LV if the fs is not using the affected space, i.e. the fs does not need to be shrunk. Fail the command without reducing the fs or LV if the fs is using the affected space. resize Resize the fs using the fs-specific resize command. This may include mounting, unmounting, or running fsck. See --fsmode to control mounting behavior, and --nofsck to disable fsck. resize_fsadm Use the old method of calling fsadm to handle the fs (deprecated.) Warning: this option does not prevent lvreduce from destroying file systems that are unmounted (or mounted if prompts are skipped.) ignore Resize the LV without checking for or handling a file system. Warning: using ignore when reducing the LV size may destroy the file system. Possible --fsmode values: manage Mount or unmount the fs as needed to resize the fs, and attempt to restore the original mount state at the end. nochange Do not mount or unmount the fs. If mounting or unmounting is required to resize the fs, then do not resize the fs or the LV and fail the command. offline Unmount the fs if it is mounted, and resize the fs while it is unmounted. If mounting is required to resize the fs, then do not resize the fs or the LV and fail the command. Notes on lvreduce: When no --fs or --resizefs option is specified: . lvextend default behavior is fs ignore. . lvreduce default behavior is fs checksize (includes activating the LV.) With the exception of --fs resize_fsadm|ignore, lvreduce requires the recent libblkid fields FSLASTBLOCK and FSBLOCKSIZE. FSLASTBLOCK*FSBLOCKSIZE is the last byte used by the fs on the LV, which determines if reducing the fs is necessary.
2022-06-14 23:20:21 +03:00
if (activated || activated_checksize) {
lvresize: restructure code Rewrite top level resize function to prepare for adding new fs resizing.
2022-09-10 00:07:07 +03:00
if (!sync_local_dev_names(cmd))
stack;
if (!deactivate_lv(cmd, lv_top))
log_warn("Problem deactivating %s.", display_lvname(lv_top));
lvresize: support more resized LVs Add code to support more LVs to be resized through a same code path using a single lvresize_params struct. (Now it's used for thin-pool metadata resize, next user will be snapshot virtual resize). Update code to adjust percent amount resize for use_policies. Properly activate inactive thin-pool in case of any pool resize as the command should not 'deffer' this operation to next activation.
2016-06-23 00:32:35 +03:00
}
thin: fix resize of stacked thin pool volume When the pool is created from non-linear target the more complex rules have to be used and stacking needs to properly decode args for _tdata LV. Also proper allocation policies are being used according to those set in lvm2 metadata for data and metadata LVs. Also properly check for active pool and extra code to active it temporarily. With this fix it's now possible to use: lvcreate -L20 -m2 -n pool vg --alloc anywhere lvcreate -L10 -m2 -n poolm vg --alloc anywhere lvconvert --thinpool vg/pool --poolmetadata vg/poolm lvresize -L+10 vg/pool
2013-09-06 12:54:50 +04:00
lvresize: support more resized LVs Add code to support more LVs to be resized through a same code path using a single lvresize_params struct. (Now it's used for thin-pool metadata resize, next user will be snapshot virtual resize). Update code to adjust percent amount resize for use_policies. Properly activate inactive thin-pool in case of any pool resize as the command should not 'deffer' this operation to next activation.
2016-06-23 00:32:35 +03:00
return ret;
lvm2app: Move core lv re-size code (v6) Moved to allow use from command line and for library use. v3,v4,v5,v6: rebase changes Signed-off-by: Tony Asleson <tasleson@redhat.com>
2013-03-14 02:00:29 +04:00
}
Always insert an intermediate layer for mirrors. Suppress hidden LVs from reports unless --all is given. Use square brackets for hidden LVs in reports. Centralise restrictions on LV names.
2005-06-03 18:49:51 +04:00
char *generate_lv_name(struct volume_group *vg, const char *format,
char *buffer, size_t len)
o lvcreate no longer needs the explicit -n flag o disabled zeroing of lv until bug's worked out
2001-11-14 15:07:37 +03:00
{
Fix contiguous allocations with linear.
2005-05-11 20:46:59 +04:00
struct lv_list *lvl;
metadata: also look at historical LVs when checking LV name availability Live LVs and historical LVs are in one namespace and the name needs to be unique in whole VG.
2016-03-01 17:31:48 +03:00
struct glv_list *glvl;
o Get format-text.c compiling.
2002-01-07 12:16:20 +03:00
int high = -1, i;
o lvcreate no longer needs the explicit -n flag o disabled zeroing of lv until bug's worked out
2001-11-14 15:07:37 +03:00
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
dm_list_iterate_items(lvl, &vg->lvs) {
Fix contiguous allocations with linear.
2005-05-11 20:46:59 +04:00
if (sscanf(lvl->lv->name, format, &i) != 1)
o lvcreate no longer needs the explicit -n flag o disabled zeroing of lv until bug's worked out
2001-11-14 15:07:37 +03:00
continue;
if (i > high)
Avoid generating duplicate lv names
2001-11-14 17:12:01 +03:00
high = i;
o lvcreate no longer needs the explicit -n flag o disabled zeroing of lv until bug's worked out
2001-11-14 15:07:37 +03:00
}
metadata: also look at historical LVs when checking LV name availability Live LVs and historical LVs are in one namespace and the name needs to be unique in whole VG.
2016-03-01 17:31:48 +03:00
dm_list_iterate_items(glvl, &vg->historical_lvs) {
if (sscanf(glvl->glv->historical->name, format, &i) != 1)
continue;
if (i > high)
high = i;
}
Move lvm_snprintf into libdevmapper.
2006-08-21 16:54:53 +04:00
if (dm_snprintf(buffer, len, format, high + 1) < 0)
o lvcreate no longer needs the explicit -n flag o disabled zeroing of lv until bug's worked out
2001-11-14 15:07:37 +03:00
return NULL;
return buffer;
}
metadata: add get_or_create_glv and get_or_create_glvl The get_or_create_glv is helper function that retrieves any existing generic_logical_volume wrapper for the LV. If the wrapper does not exist yet, it's created. The get_org_create_glvl is the same as get_or_create_glv but it creates the glv_list wrapper in addition so it can be added to a list.
2016-03-01 17:19:23 +03:00
struct generic_logical_volume *get_or_create_glv(struct dm_pool*mem, struct logical_volume *lv, int *glv_created)
{
struct generic_logical_volume *glv;
if (!(glv = lv->this_glv)) {
if (!(glv = dm_pool_zalloc(mem, sizeof(struct generic_logical_volume)))) {
log_error("Failed to allocate generic logical volume structure.");
return NULL;
}
glv->live = lv;
lv->this_glv = glv;
if (glv_created)
*glv_created = 1;
} else if (glv_created)
*glv_created = 0;
return glv;
}
struct glv_list *get_or_create_glvl(struct dm_pool *mem, struct logical_volume *lv, int *glv_created)
{
struct glv_list *glvl;
if (!(glvl = dm_pool_zalloc(mem, sizeof(struct glv_list)))) {
log_error("Failed to allocate generic logical volume list item.");
return NULL;
}
if (!(glvl->glv = get_or_create_glv(mem, lv, glv_created))) {
dm_pool_free(mem, glvl);
return_NULL;
}
return glvl;
}
metadata: add add_glv_to_indirect_glvs and remove_glv_from_indirect_glvs The add_glv_to_indirect_glvs is a helper function that registers a volume represented by struct generic_logical_volume instance ("glv") as an indirect user of another volume ("origin_glv") and vice versa - it also registers the other volume ("origin_glv") as indirect_origin of user volume ("glv"). The remove_glv_from_indirect_glvs does the opposite.
2016-03-01 17:19:57 +03:00
int add_glv_to_indirect_glvs(struct dm_pool *mem,
struct generic_logical_volume *origin_glv,
struct generic_logical_volume *glv)
{
struct glv_list *glvl;
if (!(glvl = dm_pool_zalloc(mem, sizeof(struct glv_list)))) {
log_error("Failed to allocate generic volume list item "
"for indirect glv %s", glv->is_historical ? glv->historical->name
: glv->live->name);
return 0;
}
glvl->glv = glv;
if (glv->is_historical)
glv->historical->indirect_origin = origin_glv;
else
first_seg(glv->live)->indirect_origin = origin_glv;
if (origin_glv) {
if (origin_glv->is_historical)
dm_list_add(&origin_glv->historical->indirect_glvs, &glvl->list);
else
dm_list_add(&origin_glv->live->indirect_glvs, &glvl->list);
}
return 1;
}
int remove_glv_from_indirect_glvs(struct generic_logical_volume *origin_glv,
struct generic_logical_volume *glv)
{
struct glv_list *glvl, *tglvl;
struct dm_list *list = origin_glv->is_historical ? &origin_glv->historical->indirect_glvs
: &origin_glv->live->indirect_glvs;
dm_list_iterate_items_safe(glvl, tglvl, list) {
if (glvl->glv != glv)
continue;
dm_list_del(&glvl->list);
if (glvl->glv->is_historical)
glvl->glv->historical->indirect_origin = NULL;
else
first_seg(glvl->glv->live)->indirect_origin = NULL;
return 1;
}
log_error(INTERNAL_ERROR "%s logical volume %s is not a user of %s.",
glv->is_historical ? "historical" : "Live",
glv->is_historical ? glv->historical->name : glv->live->name,
origin_glv->is_historical ? origin_glv->historical->name : origin_glv->live->name);
return 0;
}
Consolidate LV allocation into alloc_lv().
2009-09-28 21:46:15 +04:00
struct logical_volume *alloc_lv(struct dm_pool *mem)
{
struct logical_volume *lv;
if (!(lv = dm_pool_zalloc(mem, sizeof(*lv)))) {
log_error("Unable to allocate logical volume structure");
return NULL;
}
dm_list_init(&lv->snapshot_segs);
dm_list_init(&lv->segments);
dm_list_init(&lv->tags);
dm_list_init(&lv->segs_using_this_lv);
metadata: add infrastructure to track LV history Add new structures and new fields in existing structures to support tracking history of LVs (the LVs which don't exist - the have been removed already): - new "struct historical_logical_volume" This structure keeps information specific to historical LVs (historical LV is very reduced form of struct logical_volume + it contains a few specific fields to track historical LV properties like removal time and connections among other LVs). - new "struct generic_logical_volume" Wrapper for "struct historical_logical_volume" and "struct logical_volume" to make it possible to handle volumes in uniform way, no matter if it's live or historical one. - new "struct glv_list" Wrapper for "struct generic_logical_volume" so it can be added to a list. - new "indirect_glvs" field in "struct logical_volume" List that stores references to all indirect users of this LV - this interconnects live LV with historical descendant LVs or even live descendant LVs. - new "indirect_origin" field in "struct lv_segment" Reference to indirect origin of this segment - this interconnects live LV (segment) with historical ancestor. - new "this_glv" field in "struct logical_volume" This references an existing generic_logical_volume wrapper for this LV, if used. It can be NULL if not needed - which means we're not handling historical LVs at all. - new "historical_lvs" field in "struct volume group List of all historical LVs read from VG metadata.
2016-03-01 17:18:42 +03:00
dm_list_init(&lv->indirect_glvs);
Consolidate LV allocation into alloc_lv().
2009-09-28 21:46:15 +04:00
return lv;
}
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
/*
* Create a new empty LV.
*/
Non-functional change - refactor lv_create_empty(). Remove struct format_instance param - we can safely obtain this from vg->fid inside the function.
2007-10-11 23:20:38 +04:00
struct logical_volume *lv_create_empty(const char *name,
add lvid to lv_create_empty
2005-04-07 16:29:46 +04:00
union lvid *lvid,
Switch status from 32-bit to 64-bit The physical_volume, volume_group, logical_volume and lv_segment structures' 'status' member is now uint64_t. The alignment of these structures was also audited to remove holes. The movement of some members in 'volume_group' and 'lv_segment' eliminates holes. The 'physical_volume' structure still has one 4-byte hole after 'pe_size'; the other structures no longer have any holes. Each structures' size has not changed.
2009-11-25 01:55:55 +03:00
uint64_t status,
o Metadata area struct change. o Support physical extent restrictions on PV lists for allocations e.g. lvcreate -l 200 vg1 /dev/sda1:100-199:300-399
2003-04-25 02:23:24 +04:00
alloc_policy_t alloc,
struct volume_group *vg)
o lv_manip.c will contain the code for lv_create, lv_extend and lv_reduce.
2001-11-06 13:29:56 +03:00
{
Non-functional change - refactor lv_create_empty(). Remove struct format_instance param - we can safely obtain this from vg->fid inside the function.
2007-10-11 23:20:38 +04:00
struct format_instance *fi = vg->fid;
o lv_manip.c will contain the code for lv_create, lv_extend and lv_reduce.
2001-11-06 13:29:56 +03:00
struct logical_volume *lv;
Fix create mirror with name longer than 22 chars.
2007-01-05 18:53:40 +03:00
char dname[NAME_LEN];
metadata: also look at historical LVs when checking LV name availability Live LVs and historical LVs are in one namespace and the name needs to be unique in whole VG.
2016-03-01 17:31:48 +03:00
int historical;
o lv_manip.c will contain the code for lv_create, lv_extend and lv_reduce.
2001-11-06 13:29:56 +03:00
Check max_lv on only place and force the check only for new volume. We can temporarily violate max_lv during mirror conversion etc. (If the operation fails, orphan mirror images are visible to administrator for manual remove for example. Not that this should ever happen:-) Force limit only for lvcreate (and vg merge) command. Patch also adds simple max_lv tests into testsuite
2009-05-14 01:29:10 +04:00
if (vg_max_lv_reached(vg))
stack;
o lv_manip.c will contain the code for lv_create, lv_extend and lv_reduce.
2001-11-06 13:29:56 +03:00
Always insert an intermediate layer for mirrors. Suppress hidden LVs from reports unless --all is given. Use square brackets for hidden LVs in reports. Centralise restrictions on LV names.
2005-06-03 18:49:51 +04:00
if (strstr(name, "%d") &&
!(name = generate_lv_name(vg, name, dname, sizeof(dname)))) {
Miscellaneous tidying
2001-11-14 16:52:38 +03:00
log_error("Failed to generate unique name for the new "
"logical volume");
o lvcreate no longer needs the explicit -n flag o disabled zeroing of lv until bug's worked out
2001-11-14 15:07:37 +03:00
return NULL;
tidy: prefer not using else after return clang-tidy: avoid using 'else' after return - give more readable code, and also saves indention level.
2017-07-19 17:16:12 +03:00
}
if (lv_name_is_used_in_vg(vg, name, &historical)) {
When creating new LV, double-check that name is not already in use.
2009-05-28 05:59:37 +04:00
log_error("Unable to create LV %s in Volume Group %s: "
metadata: also look at historical LVs when checking LV name availability Live LVs and historical LVs are in one namespace and the name needs to be unique in whole VG.
2016-03-01 17:31:48 +03:00
"name already in use%s.", name, vg->name,
historical ? " by historical LV" : "");
When creating new LV, double-check that name is not already in use.
2009-05-28 05:59:37 +04:00
return NULL;
o lvcreate no longer needs the explicit -n flag o disabled zeroing of lv until bug's worked out
2001-11-14 15:07:37 +03:00
}
Remove unneeded import parameter from lv_create_empty.
2009-05-14 01:28:31 +04:00
log_verbose("Creating logical volume %s", name);
o lvcreate no longer needs the explicit -n flag o disabled zeroing of lv until bug's worked out
2001-11-14 15:07:37 +03:00
Consolidate LV allocation into alloc_lv().
2009-09-28 21:46:15 +04:00
if (!(lv = alloc_lv(vg->vgmem)))
Introduce link_lv_to_vg and unlink_lv_from_vg functions. link_lv_to_vg and unlink_lv_from_vg are the only functions for adding/removing logical volume from volume group. Only these function should manipulate with vg->lvs list.
2009-05-14 01:25:01 +04:00
return_NULL;
o lv_manip.c will contain the code for lv_create, lv_extend and lv_reduce.
2001-11-06 13:29:56 +03:00
Introduce link_lv_to_vg and unlink_lv_from_vg functions. link_lv_to_vg and unlink_lv_from_vg are the only functions for adding/removing logical volume from volume group. Only these function should manipulate with vg->lvs list.
2009-05-14 01:25:01 +04:00
if (!(lv->name = dm_pool_strdup(vg->vgmem, name)))
goto_bad;
o lv_manip.c will contain the code for lv_create, lv_extend and lv_reduce.
2001-11-06 13:29:56 +03:00
lv->status = status;
i) There's now a seperate field in struct logical_volume that stores the allocation policy. This can currently take one of three values: typedef enum { ALLOC_NEXT_FREE, ALLOC_STRICT, ALLOC_CONTIGUOUS } alloc_policy_t; Notice that 'SIMPLE' has turned into the slightly more meaningful NEXT_FREE. ii) Put code into display.[hc] for converting one of these enums to a text representation and back again. ii) Updated the text format so this also has the alloc_policy field.
2002-07-11 18:21:49 +04:00
lv->alloc = alloc;
Enhance the management of readahead settings.
2007-11-09 19:51:54 +03:00
lv->read_ahead = vg->cmd->default_settings.read_ahead;
Allow for specification of major number as well as minor.
2003-04-02 23:14:43 +04:00
lv->major = -1;
Basic support for persistent minor numbers; slightly different from the current LVM1 method. lvcreate --persistent y --minor 10 (to specify when created) lvchange --persistent n (to turn off) lvchange --persistent y --minor 11 (to change) --persistent uses a new LV status flag stored on disk minor number is stored on disk the same way as LVM1 does (but major number stored is 0; any LVM1 major/minor setting gets lost) lvchange -ay --minor 12 (to activate using minor 12, regardless of the on-disk setting, which doesn't get changed) --minor == -m --persistent == -M
2002-02-01 20:54:39 +03:00
lv->minor = -1;
o Metadata area struct change. o Support physical extent restrictions on PV lists for allocations e.g. lvcreate -l 200 vg1 /dev/sda1:100-199:300-399
2003-04-25 02:23:24 +04:00
lv->size = UINT64_C(0);
lv->le_count = 0;
o lv_manip.c will contain the code for lv_create, lv_extend and lv_reduce.
2001-11-06 13:29:56 +03:00
add lvid to lv_create_empty
2005-04-07 16:29:46 +04:00
if (lvid)
lv->lvid = *lvid;
Introduce link_lv_to_vg and unlink_lv_from_vg functions. link_lv_to_vg and unlink_lv_from_vg are the only functions for adding/removing logical volume from volume group. Only these function should manipulate with vg->lvs list.
2009-05-14 01:25:01 +04:00
if (!link_lv_to_vg(vg, lv))
goto_bad;
Add support to keep info about creation time and host for each LV Basic support to keep info when the LV was created. Host and time is stored into LV mda section. FIXME: Current version doesn't support configurable string via lvm.conf and used fixed version strftime "%Y-%m-%d %T %z".
2012-01-19 19:31:45 +04:00
if (!lv_set_creation(lv, NULL, 0))
goto_bad;
cleanup: spaces
2016-01-11 16:11:37 +03:00
Introduce link_lv_to_vg and unlink_lv_from_vg functions. link_lv_to_vg and unlink_lv_from_vg are the only functions for adding/removing logical volume from volume group. Only these function should manipulate with vg->lvs list.
2009-05-14 01:25:01 +04:00
if (fi->fmt->ops->lv_setup && !fi->fmt->ops->lv_setup(fi, lv))
goto_bad;
profile: move profile assignment to common lv_create_empty fn
2013-07-17 13:31:54 +04:00
if (vg->fid->fmt->features & FMT_CONFIG_PROFILE)
config: differentiate command and metadata profiles and consolidate profile handling code - When defining configuration source, the code now uses separate CONFIG_PROFILE_COMMAND and CONFIG_PROFILE_METADATA markers (before, it was just CONFIG_PROFILE that did not make the difference between the two). This helps when checking the configuration if it contains correct set of options which are all in either command-profilable or metadata-profilable group without mixing these groups together - so it's a firm distinction. The "command profile" can't contain "metadata profile" and vice versa! This is strictly checked and if the settings are mixed, such profile is rejected and it's not used. So in the end, the CONFIG_PROFILE_COMMAND set of options and CONFIG_PROFILE_METADATA are mutually exclusive sets. - Marking configuration with one or the other marker will also determine the way these configuration sources are positioned in the configuration cascade which is now: CONFIG_STRING -> CONFIG_PROFILE_COMMAND -> CONFIG_PROFILE_METADATA -> CONFIG_FILE/CONFIG_MERGED_FILES - Marking configuration with one or the other marker will also make it possible to issue a command context refresh (will be probably a part of a future patch) if needed for settings in global profile set. For settings in metadata profile set this is impossible since we can't refresh cmd context in the middle of reading VG/LV metadata and for each VG/LV separately because each VG/LV can have a different metadata profile assinged and it's not possible to change these settings at this level. - When command profile is incorrect, it's rejected *and also* the command exits immediately - the profile *must* be correct for the command that was run with a profile to be executed. Before this patch, when the profile was found incorrect, there was just the warning message and the command continued without profile applied. But it's more correct to exit immediately in this case. - When metadata profile is incorrect, we reject it during command runtime (as we know the profile name from metadata and not early from command line as it is in case of command profiles) and we *do continue* with the command as we're in the middle of operation. Also, the metadata profile is applied directly and on the fly on find_config_tree_* fn call and even if the metadata profile is found incorrect, we still need to return the non-profiled value as found in the other configuration provided or default value. To exit immediately even in this case, we'd need to refactor existing find_config_tree_* fns so they can return error. Currently, these fns return only config values (which end up with default values in the end if the config is not found). - To check the profile validity before use to be sure it's correct, one can use : lvm dumpconfig --commandprofile/--metadataprofile ProfileName --validate (the --commandprofile/--metadataprofile for dumpconfig will come as part of the subsequent patch) - This patch also adds a reference to --commandprofile and --metadataprofile in the cmd help string (which was missing before for the --profile for some commands). We do not mention --profile now as people should use --commandprofile or --metadataprofile directly. However, the --profile is still supported for backward compatibility and it's translated as: --profile == --metadataprofile for lvcreate, vgcreate, lvchange and vgchange (as these commands are able to attach profile to metadata) --profile == --commandprofile for all the other commands (--metadataprofile is not allowed there as it makes no sense) - This patch also contains some cleanups to make the code handling the profiles more readable...
2014-05-20 16:13:10 +04:00
lv->profile = vg->cmd->profile_params->global_metadata_profile;
cleanup: spaces
2016-01-11 16:11:37 +03:00
o lv_manip.c will contain the code for lv_create, lv_extend and lv_reduce.
2001-11-06 13:29:56 +03:00
return lv;
Introduce link_lv_to_vg and unlink_lv_from_vg functions. link_lv_to_vg and unlink_lv_from_vg are the only functions for adding/removing logical volume from volume group. Only these function should manipulate with vg->lvs list.
2009-05-14 01:25:01 +04:00
bad:
dm_pool_free(vg->vgmem, lv);
return NULL;
o Metadata area struct change. o Support physical extent restrictions on PV lists for allocations e.g. lvcreate -l 200 vg1 /dev/sda1:100-199:300-399
2003-04-25 02:23:24 +04:00
}
preparation for parallel_areas changes to allocation code
2005-11-24 23:58:44 +03:00
check_contiguous to use for_each_pv
2006-10-08 03:40:36 +04:00
static int _add_pvs(struct cmd_context *cmd, struct pv_segment *peg,
Use __attribute__ consistently throughout.
2010-07-09 19:34:40 +04:00
uint32_t s __attribute__((unused)), void *data)
Determine parallel PVs to avoid with ALLOC_NORMAL allocation. (untested)
2005-11-28 23:01:00 +03:00
{
Extend _check_contiguous() to detect single-area LVs. Include mirror log (untested) in _for_each_pv() processing. Use MIRROR_LOG_SIZE constant. Remove struct seg_pvs from _for_each_pv() for generalisation. Avoid adding duplicates to list of parallel PVs to avoid.
2006-09-12 01:14:56 +04:00
struct seg_pvs *spvs = (struct seg_pvs *) data;
Determine parallel PVs to avoid with ALLOC_NORMAL allocation. (untested)
2005-11-28 23:01:00 +03:00
struct pv_list *pvl;
Extend _check_contiguous() to detect single-area LVs. Include mirror log (untested) in _for_each_pv() processing. Use MIRROR_LOG_SIZE constant. Remove struct seg_pvs from _for_each_pv() for generalisation. Avoid adding duplicates to list of parallel PVs to avoid.
2006-09-12 01:14:56 +04:00
/* Don't add again if it's already on list. */
Add find_lv_in_lv_list() and find_pv_in_pv_list(). Update _add_pvs() to call find_pv_in_pv_list().
2008-03-28 22:08:23 +03:00
if (find_pv_in_pv_list(&spvs->pvs, peg->pv))
alloc: Refactor area reservation code. No functional changes intended to be included in this patch.
2014-04-10 23:48:59 +04:00
return 1;
Determine parallel PVs to avoid with ALLOC_NORMAL allocation. (untested)
2005-11-28 23:01:00 +03:00
lvmanip: uninitialized members in struct pv_list (#10) Scenario: Given an existed LV `lvol0`, I want to create another LV on the PVs used by `lvol0`. I use `build_parallel_areas_from_lv()` to obtain the `pv_list` of each segments. However, the returned `pv_list` is not properly initialized, which causes segfault in subsequent operations.
2018-12-14 12:51:51 +03:00
if (!(pvl = dm_pool_zalloc(cmd->mem, sizeof(*pvl)))) {
Determine parallel PVs to avoid with ALLOC_NORMAL allocation. (untested)
2005-11-28 23:01:00 +03:00
log_error("pv_list allocation failed");
return 0;
}
pvl->pv = peg->pv;
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
dm_list_add(&spvs->pvs, &pvl->list);
Determine parallel PVs to avoid with ALLOC_NORMAL allocation. (untested)
2005-11-28 23:01:00 +03:00
return 1;
}
preparation for parallel_areas changes to allocation code
2005-11-24 23:58:44 +03:00
/*
raid/misc: Allow creation of parallel areas by LV vs segment I've changed build_parallel_areas_from_lv to take a new parameter that allows the caller to build parallel areas by LV vs by segment. Previously, the function created a list of parallel areas for each segment in the given LV. When it came time for allocation, the parallel areas were honored on a segment basis. This was problematic for RAID because any new RAID image must avoid being placed on any PVs used by other images in the RAID. For example, if we have a linear LV that has half its space on one PV and half on another, we do not want an up-convert to use either of those PVs. It should especially not wind up with the following, where the first portion of one LV is paired up with the second portion of the other: ------PV1------- ------PV2------- [ 2of2 image_1 ] [ 1of2 image_1 ] [ 1of2 image_0 ] [ 2of2 image_0 ] ---------------- ---------------- Previously, it was possible for this to happen. The change makes it so that the returned parallel areas list contains one "super" segment (seg_pvs) with a list of all the PVs from every actual segment in the given LV and covering the entire logical extent range. This change allows RAID conversions to function properly when there are existing images that contain multiple segments that span more than one PV.
2014-06-26 06:20:41 +04:00
* build_parallel_areas_from_lv
* @lv
* @use_pvmove_parent_lv
* @create_single_list
*
* For each segment in an LV, create a list of PVs used by the segment.
* Thus, the returned list is really a list of segments (seg_pvs)
* containing a list of PVs that are in use by that segment.
*
* use_pvmove_parent_lv: For pvmove we use the *parent* LV so we can
* pick up stripes & existing mirrors etc.
* create_single_list : Instead of creating a list of segments that
* each contain a list of PVs, return a list
* containing just one segment (i.e. seg_pvs)
* that contains a list of all the PVs used by
* the entire LV and all it's segments.
preparation for parallel_areas changes to allocation code
2005-11-24 23:58:44 +03:00
*/
Remove and unneeded parameter from build_parallel_areas_from_lv()
2011-07-19 20:37:42 +04:00
struct dm_list *build_parallel_areas_from_lv(struct logical_volume *lv,
raid/misc: Allow creation of parallel areas by LV vs segment I've changed build_parallel_areas_from_lv to take a new parameter that allows the caller to build parallel areas by LV vs by segment. Previously, the function created a list of parallel areas for each segment in the given LV. When it came time for allocation, the parallel areas were honored on a segment basis. This was problematic for RAID because any new RAID image must avoid being placed on any PVs used by other images in the RAID. For example, if we have a linear LV that has half its space on one PV and half on another, we do not want an up-convert to use either of those PVs. It should especially not wind up with the following, where the first portion of one LV is paired up with the second portion of the other: ------PV1------- ------PV2------- [ 2of2 image_1 ] [ 1of2 image_1 ] [ 1of2 image_0 ] [ 2of2 image_0 ] ---------------- ---------------- Previously, it was possible for this to happen. The change makes it so that the returned parallel areas list contains one "super" segment (seg_pvs) with a list of all the PVs from every actual segment in the given LV and covering the entire logical extent range. This change allows RAID conversions to function properly when there are existing images that contain multiple segments that span more than one PV.
2014-06-26 06:20:41 +04:00
unsigned use_pvmove_parent_lv,
unsigned create_single_list)
preparation for parallel_areas changes to allocation code
2005-11-24 23:58:44 +03:00
{
Remove and unneeded parameter from build_parallel_areas_from_lv()
2011-07-19 20:37:42 +04:00
struct cmd_context *cmd = lv->vg->cmd;
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
struct dm_list *parallel_areas;
raid/misc: Allow creation of parallel areas by LV vs segment I've changed build_parallel_areas_from_lv to take a new parameter that allows the caller to build parallel areas by LV vs by segment. Previously, the function created a list of parallel areas for each segment in the given LV. When it came time for allocation, the parallel areas were honored on a segment basis. This was problematic for RAID because any new RAID image must avoid being placed on any PVs used by other images in the RAID. For example, if we have a linear LV that has half its space on one PV and half on another, we do not want an up-convert to use either of those PVs. It should especially not wind up with the following, where the first portion of one LV is paired up with the second portion of the other: ------PV1------- ------PV2------- [ 2of2 image_1 ] [ 1of2 image_1 ] [ 1of2 image_0 ] [ 2of2 image_0 ] ---------------- ---------------- Previously, it was possible for this to happen. The change makes it so that the returned parallel areas list contains one "super" segment (seg_pvs) with a list of all the PVs from every actual segment in the given LV and covering the entire logical extent range. This change allows RAID conversions to function properly when there are existing images that contain multiple segments that span more than one PV.
2014-06-26 06:20:41 +04:00
struct seg_pvs *spvs = NULL;
Determine parallel PVs to avoid with ALLOC_NORMAL allocation. (untested)
2005-11-28 23:01:00 +03:00
uint32_t current_le = 0;
*** empty log message ***
2012-02-22 21:14:38 +04:00
uint32_t raid_multiple;
struct lv_segment *seg = first_seg(lv);
preparation for parallel_areas changes to allocation code
2005-11-24 23:58:44 +03:00
lv_manip: use vgmem pool Switch to vgmem pool for allocation associated with modification of particular VG.
2018-06-23 12:59:35 +03:00
if (!(parallel_areas = dm_pool_alloc(lv->vg->vgmem, sizeof(*parallel_areas)))) {
preparation for parallel_areas changes to allocation code
2005-11-24 23:58:44 +03:00
log_error("parallel_areas allocation failed");
return NULL;
}
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
dm_list_init(parallel_areas);
preparation for parallel_areas changes to allocation code
2005-11-24 23:58:44 +03:00
Determine parallel PVs to avoid with ALLOC_NORMAL allocation. (untested)
2005-11-28 23:01:00 +03:00
do {
raid/misc: Allow creation of parallel areas by LV vs segment I've changed build_parallel_areas_from_lv to take a new parameter that allows the caller to build parallel areas by LV vs by segment. Previously, the function created a list of parallel areas for each segment in the given LV. When it came time for allocation, the parallel areas were honored on a segment basis. This was problematic for RAID because any new RAID image must avoid being placed on any PVs used by other images in the RAID. For example, if we have a linear LV that has half its space on one PV and half on another, we do not want an up-convert to use either of those PVs. It should especially not wind up with the following, where the first portion of one LV is paired up with the second portion of the other: ------PV1------- ------PV2------- [ 2of2 image_1 ] [ 1of2 image_1 ] [ 1of2 image_0 ] [ 2of2 image_0 ] ---------------- ---------------- Previously, it was possible for this to happen. The change makes it so that the returned parallel areas list contains one "super" segment (seg_pvs) with a list of all the PVs from every actual segment in the given LV and covering the entire logical extent range. This change allows RAID conversions to function properly when there are existing images that contain multiple segments that span more than one PV.
2014-06-26 06:20:41 +04:00
if (!spvs || !create_single_list) {
lv_manip: use vgmem pool Switch to vgmem pool for allocation associated with modification of particular VG.
2018-06-23 12:59:35 +03:00
if (!(spvs = dm_pool_zalloc(lv->vg->vgmem, sizeof(*spvs)))) {
raid/misc: Allow creation of parallel areas by LV vs segment I've changed build_parallel_areas_from_lv to take a new parameter that allows the caller to build parallel areas by LV vs by segment. Previously, the function created a list of parallel areas for each segment in the given LV. When it came time for allocation, the parallel areas were honored on a segment basis. This was problematic for RAID because any new RAID image must avoid being placed on any PVs used by other images in the RAID. For example, if we have a linear LV that has half its space on one PV and half on another, we do not want an up-convert to use either of those PVs. It should especially not wind up with the following, where the first portion of one LV is paired up with the second portion of the other: ------PV1------- ------PV2------- [ 2of2 image_1 ] [ 1of2 image_1 ] [ 1of2 image_0 ] [ 2of2 image_0 ] ---------------- ---------------- Previously, it was possible for this to happen. The change makes it so that the returned parallel areas list contains one "super" segment (seg_pvs) with a list of all the PVs from every actual segment in the given LV and covering the entire logical extent range. This change allows RAID conversions to function properly when there are existing images that contain multiple segments that span more than one PV.
2014-06-26 06:20:41 +04:00
log_error("allocation failed");
return NULL;
}
Determine parallel PVs to avoid with ALLOC_NORMAL allocation. (untested)
2005-11-28 23:01:00 +03:00
raid/misc: Allow creation of parallel areas by LV vs segment I've changed build_parallel_areas_from_lv to take a new parameter that allows the caller to build parallel areas by LV vs by segment. Previously, the function created a list of parallel areas for each segment in the given LV. When it came time for allocation, the parallel areas were honored on a segment basis. This was problematic for RAID because any new RAID image must avoid being placed on any PVs used by other images in the RAID. For example, if we have a linear LV that has half its space on one PV and half on another, we do not want an up-convert to use either of those PVs. It should especially not wind up with the following, where the first portion of one LV is paired up with the second portion of the other: ------PV1------- ------PV2------- [ 2of2 image_1 ] [ 1of2 image_1 ] [ 1of2 image_0 ] [ 2of2 image_0 ] ---------------- ---------------- Previously, it was possible for this to happen. The change makes it so that the returned parallel areas list contains one "super" segment (seg_pvs) with a list of all the PVs from every actual segment in the given LV and covering the entire logical extent range. This change allows RAID conversions to function properly when there are existing images that contain multiple segments that span more than one PV.
2014-06-26 06:20:41 +04:00
dm_list_init(&spvs->pvs);
dm_list_add(parallel_areas, &spvs->list);
}
Determine parallel PVs to avoid with ALLOC_NORMAL allocation. (untested)
2005-11-28 23:01:00 +03:00
spvs->le = current_le;
spvs->len = lv->le_count - current_le;
raid/misc: Allow creation of parallel areas by LV vs segment I've changed build_parallel_areas_from_lv to take a new parameter that allows the caller to build parallel areas by LV vs by segment. Previously, the function created a list of parallel areas for each segment in the given LV. When it came time for allocation, the parallel areas were honored on a segment basis. This was problematic for RAID because any new RAID image must avoid being placed on any PVs used by other images in the RAID. For example, if we have a linear LV that has half its space on one PV and half on another, we do not want an up-convert to use either of those PVs. It should especially not wind up with the following, where the first portion of one LV is paired up with the second portion of the other: ------PV1------- ------PV2------- [ 2of2 image_1 ] [ 1of2 image_1 ] [ 1of2 image_0 ] [ 2of2 image_0 ] ---------------- ---------------- Previously, it was possible for this to happen. The change makes it so that the returned parallel areas list contains one "super" segment (seg_pvs) with a list of all the PVs from every actual segment in the given LV and covering the entire logical extent range. This change allows RAID conversions to function properly when there are existing images that contain multiple segments that span more than one PV.
2014-06-26 06:20:41 +04:00
if (use_pvmove_parent_lv &&
!(seg = find_seg_by_le(lv, current_le))) {
Fix pvmove allocation to take existing parallel stripes into account. When moving parts of striped LVs, pvmove wouldn't care about leaving you with two stripes on the same disk. Now --alloc anywhere is needed for that. (Tried and gave up on two alternative approaches before the one committed here.)
2010-04-08 04:28:57 +04:00
log_error("Failed to find segment for %s extent %" PRIu32,
lv->name, current_le);
return 0;
}
Determine parallel PVs to avoid with ALLOC_NORMAL allocation. (untested)
2005-11-28 23:01:00 +03:00
/* Find next segment end */
/* FIXME Unnecessary nesting! */
Fix pvmove allocation to take existing parallel stripes into account. When moving parts of striped LVs, pvmove wouldn't care about leaving you with two stripes on the same disk. Now --alloc anywhere is needed for that. (Tried and gave up on two alternative approaches before the one committed here.)
2010-04-08 04:28:57 +04:00
if (!_for_each_pv(cmd, use_pvmove_parent_lv ? seg->pvmove_source_seg->lv : lv,
use_pvmove_parent_lv ? seg->pvmove_source_seg->le : current_le,
Permit mimage LVs to be striped in lvcreate and lvresize.
2010-04-09 05:00:10 +04:00
use_pvmove_parent_lv ? spvs->len * _calc_area_multiple(seg->pvmove_source_seg->segtype, seg->pvmove_source_seg->area_count, 0) : spvs->len,
missing ?:
2010-04-08 04:56:26 +04:00
use_pvmove_parent_lv ? seg->pvmove_source_seg : NULL,
Fix pvmove allocation to take existing parallel stripes into account. When moving parts of striped LVs, pvmove wouldn't care about leaving you with two stripes on the same disk. Now --alloc anywhere is needed for that. (Tried and gave up on two alternative approaches before the one committed here.)
2010-04-08 04:28:57 +04:00
&spvs->len,
Use stack return macros throughout.
2008-01-30 16:19:47 +03:00
0, 0, -1, 0, _add_pvs, (void *) spvs))
return_NULL;
Determine parallel PVs to avoid with ALLOC_NORMAL allocation. (untested)
2005-11-28 23:01:00 +03:00
current_le = spvs->le + spvs->len;
*** empty log message ***
2012-02-22 21:14:38 +04:00
raid_multiple = (seg->segtype->parity_devs) ?
seg->area_count - seg->segtype->parity_devs : 1;
} while ((current_le * raid_multiple) < lv->le_count);
Determine parallel PVs to avoid with ALLOC_NORMAL allocation. (untested)
2005-11-28 23:01:00 +03:00
raid/misc: Allow creation of parallel areas by LV vs segment I've changed build_parallel_areas_from_lv to take a new parameter that allows the caller to build parallel areas by LV vs by segment. Previously, the function created a list of parallel areas for each segment in the given LV. When it came time for allocation, the parallel areas were honored on a segment basis. This was problematic for RAID because any new RAID image must avoid being placed on any PVs used by other images in the RAID. For example, if we have a linear LV that has half its space on one PV and half on another, we do not want an up-convert to use either of those PVs. It should especially not wind up with the following, where the first portion of one LV is paired up with the second portion of the other: ------PV1------- ------PV2------- [ 2of2 image_1 ] [ 1of2 image_1 ] [ 1of2 image_0 ] [ 2of2 image_0 ] ---------------- ---------------- Previously, it was possible for this to happen. The change makes it so that the returned parallel areas list contains one "super" segment (seg_pvs) with a list of all the PVs from every actual segment in the given LV and covering the entire logical extent range. This change allows RAID conversions to function properly when there are existing images that contain multiple segments that span more than one PV.
2014-06-26 06:20:41 +04:00
if (create_single_list) {
spvs->le = 0;
spvs->len = lv->le_count;
}
/*
* FIXME: Merge adjacent segments with identical PV lists
* (avoids need for contiguous allocation attempts between
* successful allocations)
*/
Determine parallel PVs to avoid with ALLOC_NORMAL allocation. (untested)
2005-11-28 23:01:00 +03:00
preparation for parallel_areas changes to allocation code
2005-11-24 23:58:44 +03:00
return parallel_areas;
}
Move lv_remove_single() into library (lv_manip.c, metadata-exported.h). Move yes_no_prompt() into library (display.c, display.h). Fixup includes as a result of movement of prior two functions. Fixup force_t enum to be more descriptive.
2007-08-20 21:04:53 +04:00
Introduce lv_set_visible & lv_set_invisible and use lv_is_visible always. The vg->lv_count parameter now includes always number of visible logical volumes. Note that virtual snapshot volume (snapshotX) is never visible, but it is stored in metadata with visible flag.
2009-05-14 01:26:45 +04:00
void lv_set_visible(struct logical_volume *lv)
{
if (lv_is_visible(lv))
return;
lv->status |= VISIBLE_LV;
logging: classify log_debug messages Place most log_debug() messages into a class.
2013-01-08 02:30:29 +04:00
log_debug_metadata("LV %s in VG %s is now visible.", lv->name, lv->vg->name);
Introduce lv_set_visible & lv_set_invisible and use lv_is_visible always. The vg->lv_count parameter now includes always number of visible logical volumes. Note that virtual snapshot volume (snapshotX) is never visible, but it is stored in metadata with visible flag.
2009-05-14 01:26:45 +04:00
}
Pre-release cleanups.
2009-05-21 07:04:52 +04:00
void lv_set_hidden(struct logical_volume *lv)
Introduce lv_set_visible & lv_set_invisible and use lv_is_visible always. The vg->lv_count parameter now includes always number of visible logical volumes. Note that virtual snapshot volume (snapshotX) is never visible, but it is stored in metadata with visible flag.
2009-05-14 01:26:45 +04:00
{
if (!lv_is_visible(lv))
return;
lv->status &= ~VISIBLE_LV;
logging: classify log_debug messages Place most log_debug() messages into a class.
2013-01-08 02:30:29 +04:00
log_debug_metadata("LV %s in VG %s is now hidden.", lv->name, lv->vg->name);
Introduce lv_set_visible & lv_set_invisible and use lv_is_visible always. The vg->lv_count parameter now includes always number of visible logical volumes. Note that virtual snapshot volume (snapshotX) is never visible, but it is stored in metadata with visible flag.
2009-05-14 01:26:45 +04:00
}
lvremove: use common routine for prompting Move code for prompting about removed LV to a single function and use it also to prompt for removal of origin and all its thick snapshots and also when removing merging origin. Function does handle postponed write_and_commit so there is no 'in-flight' operation while waiting on [y|n] answer.
2021-03-14 15:17:03 +03:00
static int _lv_remove_check_in_use(struct logical_volume *lv, force_t force)
{
struct volume_group *vg = lv->vg;
const char *volume_type = "";
cov: fix typo and reduce stack usage Buffer on stack was for single LV name plus some short text around. Use of 50* was a typo so use correly 50+.
2021-04-22 16:27:58 +03:00
char buffer[50 + NAME_LEN * 2] = "";
lvremove: use common routine for prompting Move code for prompting about removed LV to a single function and use it also to prompt for removal of origin and all its thick snapshots and also when removing merging origin. Function does handle postponed write_and_commit so there is no 'in-flight' operation while waiting on [y|n] answer.
2021-03-14 15:17:03 +03:00
int active;
int issue_discards =
(vg->cmd->current_settings.issue_discards &&
!lv_is_thin_volume(lv) &&
!lv_is_vdo(lv) &&
!lv_is_virtual_origin(lv)) ? 1 : 0;
switch (lv_check_not_in_use(lv, 1)) {
case 2: /* Not active, prompt when discarding real LVs */
if (!issue_discards ||
lv_is_historical(lv))
return 1;
active = 0;
break;
case 1: /* Active, not in use, prompt when visible */
if (!lv_is_visible(lv) ||
lv_is_pending_delete(lv))
return 1;
active = 1;
break;
default: /* Active, in use, can't remove */
return_0;
}
if (force == PROMPT) {
if (vg->needs_write_and_commit && (!vg_write(vg) || !vg_commit(vg)))
return_0;
if (lv_is_origin(lv)) {
volume_type = " origin";
(void) dm_snprintf(buffer, sizeof(buffer), " with %u snapshots(s)",
lv->origin_count);
} else if (lv_is_merging_origin(lv)) {
volume_type = " merging origin";
(void) dm_snprintf(buffer, sizeof(buffer), " with snapshot %s",
display_lvname(find_snapshot(lv)->lv));
}
if (yes_no_prompt("Do you really want to remove%s%s%s%s "
"logical volume %s%s? [y/n]: ",
issue_discards ? " and DISCARD" : "",
active ? " active" : "",
vg_is_clustered(vg) ? " clustered" : "",
volume_type, display_lvname(lv),
buffer) == 'n') {
lv->to_remove = 0;
log_error("Logical volume %s not removed.", display_lvname(lv));
return 0;
}
}
return 1;
}
Move lv_remove_single() into library (lv_manip.c, metadata-exported.h). Move yes_no_prompt() into library (display.c, display.h). Fixup includes as a result of movement of prior two functions. Fixup force_t enum to be more descriptive.
2007-08-20 21:04:53 +04:00
int lv_remove_single(struct cmd_context *cmd, struct logical_volume *lv,
lv_remove_single: update parameter name Since we have already a meaning for 'silent' replace its name with more explanator suppress_remove_message (updates recent commit).
2013-12-05 15:39:02 +04:00
force_t force, int suppress_remove_message)
Move lv_remove_single() into library (lv_manip.c, metadata-exported.h). Move yes_no_prompt() into library (display.c, display.h). Fixup includes as a result of movement of prior two functions. Fixup force_t enum to be more descriptive.
2007-08-20 21:04:53 +04:00
{
struct volume_group *vg;
commands: lvremove: also process historical LVs
2016-03-01 17:27:08 +03:00
int visible, historical;
Thin clear stacked message for thin pool Before removing thin pool LV always make sure, stacked message for previous run are cleared - but allow to remove any device that should have been created (i.e. creation of snapshot failed - so the message for snapshot creation may be replaced with delete message within unfinished transaction). Also commit messages after lv remove - so free space is released in pool.
2012-01-25 15:27:42 +04:00
struct logical_volume *pool_lv = NULL;
Add lvmlockd
2015-03-05 23:00:44 +03:00
struct logical_volume *lock_lv = lv;
cache: Code changes to allow creation of cache pools This patch allows the creation and removal of cache pools. Users are not yet able to create cache LVs. They are only able to define the space used for the cache and its characteristics (chunk_size and cache mode ATM) by creating the cache pool.
2014-02-04 21:57:08 +04:00
struct lv_segment *cache_seg = NULL;
cache: use LV_PENDING_DELETE
2014-11-10 12:56:43 +03:00
struct seg_list *sl;
raid: fix raid LV resizing The lv_extend/_lv_reduce API doesn't cope with resizing RaidLVs with allocated reshape space and ongoing conversions. Prohibit resizing during conversions and remove the reshape space before processing resize. Add missing seg->data_copies initialisation. Fix typo/comment.
2017-03-08 00:05:23 +03:00
struct lv_segment *seg = first_seg(lv);
lv_remove: reduce commits for removed LVs This patch postpones update of lvm metadata for each removed LV for later moment depending on LV type. It also queues messages to be printed after such write & commit. As such there is some change in the behavior - although before prompt we do make write&commit happens automatically in some other error case we rather keep 'existing' state - so there could be difference in amount of removed & commited LVs. IMHO introduce logic is slightly better and more save. But some cases still need the early commit - i.e. thin-removal and fixing this needs some more thinking. TODO: improve removal at least with the case of the whole thin-pool. i.e. we can simply recognize removal of 'all LVs/whole VG'.
2021-03-05 18:21:50 +03:00
char msg[NAME_LEN + 300], *msg_dup;
Move lv_remove_single() into library (lv_manip.c, metadata-exported.h). Move yes_no_prompt() into library (display.c, display.h). Fixup includes as a result of movement of prior two functions. Fixup force_t enum to be more descriptive.
2007-08-20 21:04:53 +04:00
vg = lv->vg;
if (!vg_check_status(vg, LVM_WRITE))
Missing stack printing
2011-11-13 02:51:20 +04:00
return_0;
Move lv_remove_single() into library (lv_manip.c, metadata-exported.h). Move yes_no_prompt() into library (display.c, display.h). Fixup includes as a result of movement of prior two functions. Fixup force_t enum to be more descriptive.
2007-08-20 21:04:53 +04:00
if (lv_is_origin(lv)) {
debug: use display_lvname
2016-05-20 12:28:23 +03:00
log_error("Can't remove logical volume %s under snapshot.",
display_lvname(lv));
Move lv_remove_single() into library (lv_manip.c, metadata-exported.h). Move yes_no_prompt() into library (display.c, display.h). Fixup includes as a result of movement of prior two functions. Fixup force_t enum to be more descriptive.
2007-08-20 21:04:53 +04:00
return 0;
}
thin: removal of external_origin
2013-02-20 19:14:24 +04:00
if (lv_is_external_origin(lv)) {
debug: use display_lvname
2016-05-20 12:28:23 +03:00
log_error("Can't remove external origin logical volume %s.",
display_lvname(lv));
thin: removal of external_origin
2013-02-20 19:14:24 +04:00
return 0;
}
cleanup: Use lv_is_ macros. Use lv_is_* macros throughout the code base, introducing lv_is_pvmove, lv_is_locked, lv_is_converting and lv_is_merging. lv_is_mirror_type no longer includes pvmove.
2014-09-16 00:33:53 +04:00
if (lv_is_mirror_image(lv)) {
debug: use display_lvname
2016-05-20 12:28:23 +03:00
log_error("Can't remove logical volume %s used by a mirror.",
display_lvname(lv));
Move lv_remove_single() into library (lv_manip.c, metadata-exported.h). Move yes_no_prompt() into library (display.c, display.h). Fixup includes as a result of movement of prior two functions. Fixup force_t enum to be more descriptive.
2007-08-20 21:04:53 +04:00
return 0;
}
cleanup: Use lv_is_ macros. Use lv_is_* macros throughout the code base, introducing lv_is_pvmove, lv_is_locked, lv_is_converting and lv_is_merging. lv_is_mirror_type no longer includes pvmove.
2014-09-16 00:33:53 +04:00
if (lv_is_mirror_log(lv)) {
debug: use display_lvname
2016-05-20 12:28:23 +03:00
log_error("Can't remove logical volume %s used as mirror log.",
display_lvname(lv));
Move lv_remove_single() into library (lv_manip.c, metadata-exported.h). Move yes_no_prompt() into library (display.c, display.h). Fixup includes as a result of movement of prior two functions. Fixup force_t enum to be more descriptive.
2007-08-20 21:04:53 +04:00
return 0;
}
cleanup: Use lv_is_ macros. Use lv_is_* macros throughout the code base, introducing lv_is_pvmove, lv_is_locked, lv_is_converting and lv_is_merging. lv_is_mirror_type no longer includes pvmove.
2014-09-16 00:33:53 +04:00
if (lv_is_raid_metadata(lv) || lv_is_raid_image(lv)) {
debug: use display_lvname
2016-05-20 12:28:23 +03:00
log_error("Can't remove logical volume %s used as RAID device.",
display_lvname(lv));
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
return 0;
}
cleanup: cache reuse code for pool test Using same error message for pool associated devices.
2014-04-01 22:06:54 +04:00
if (lv_is_thin_pool_data(lv) || lv_is_thin_pool_metadata(lv) ||
lv_is_cache_pool_data(lv) || lv_is_cache_pool_metadata(lv)) {
log_error("Can't remove logical volume %s used by a pool.",
debug: use display_lvname
2016-05-20 12:28:23 +03:00
display_lvname(lv));
Thin prevent removal of its data and metadata LVs LVs cannot be removed while there are linked to thin pool. (Gives better error message, than validation).
2012-01-25 12:57:25 +04:00
return 0;
tidy: prefer not using else after return clang-tidy: avoid using 'else' after return - give more readable code, and also saves indention level.
2017-07-19 17:16:12 +03:00
}
if (lv_is_thin_volume(lv)) {
coverity: add few internal errors Mark impossible paths with internal errors. Also replace 'strcmp() with more readable seg_is...()
2015-11-13 11:49:59 +03:00
if (!(pool_lv = first_seg(lv)->pool_lv)) {
log_error(INTERNAL_ERROR "Thin LV %s without pool.",
display_lvname(lv));
return 0;
}
Add lvmlockd
2015-03-05 23:00:44 +03:00
lock_lv = pool_lv;
lvremove: support faster removal of thin-pools When lvremove/vgremove removes thin volumes with its thin-pool as well, try to skip any updates of such thin-pool, so when everything properly deactivates, there is no message send to this thin-pool and whole thin-pool is removed with a single commit.
2021-03-11 01:19:25 +03:00
if (pool_lv->to_remove)
/* Thin pool is to be removed so skip updating it when possible */
pool_lv = NULL;
Add lvmlockd
2015-03-05 23:00:44 +03:00
}
Thin prevent removal of its data and metadata LVs LVs cannot be removed while there are linked to thin pool. (Gives better error message, than validation).
2012-01-25 12:57:25 +04:00
cleanup: Use lv_is_ macros. Use lv_is_* macros throughout the code base, introducing lv_is_pvmove, lv_is_locked, lv_is_converting and lv_is_merging. lv_is_mirror_type no longer includes pvmove.
2014-09-16 00:33:53 +04:00
if (lv_is_locked(lv)) {
debug: use display_lvname
2016-05-20 12:28:23 +03:00
log_error("Can't remove locked logical volume %s.", display_lvname(lv));
Move lv_remove_single() into library (lv_manip.c, metadata-exported.h). Move yes_no_prompt() into library (display.c, display.h). Fixup includes as a result of movement of prior two functions. Fixup force_t enum to be more descriptive.
2007-08-20 21:04:53 +04:00
return 0;
}
Add lvmlockd
2015-03-05 23:00:44 +03:00
if (!lockd_lv(cmd, lock_lv, "ex", LDLV_PERSISTENT))
return_0;
lvremove: reduce ioctl count Just like with deactivation, call of 'lv_is_not_in_use()' now has embeded report for inactivate LV. Note: this patch cannot be backported to stable-2.02 - as there lv_is_active() has 'cluster' meaning and differs from lvinfo().
2021-03-08 16:22:43 +03:00
if (!lv_is_cache_vol(lv)) {
lvremove: use common routine for prompting Move code for prompting about removed LV to a single function and use it also to prompt for removal of origin and all its thick snapshots and also when removing merging origin. Function does handle postponed write_and_commit so there is no 'in-flight' operation while waiting on [y|n] answer.
2021-03-14 15:17:03 +03:00
if (!_lv_remove_check_in_use(lv, force))
return_0;
fix new lvremove checks - mustn't fail when activation is disabled
2007-11-04 19:28:57 +03:00
}
Modify lvremove to prompt for removal if LV active on other cluster nodes. Add '-f' to vgremove to force removal of VG even if LVs exist. Update vgremove man page for '-f'.
2007-08-28 20:14:49 +04:00
lvremove: fix removing thin pool with writecache on data
2021-05-25 00:08:27 +03:00
/* if thin pool data lv is writecache, then detach and remove the writecache */
if (lv_is_thin_pool(lv)) {
struct logical_volume *data_lv = data_lv_from_thin_pool(lv);
if (data_lv && lv_is_writecache(data_lv)) {
struct logical_volume *cachevol_lv = first_seg(data_lv)->writecache;
if (!lv_detach_writecache_cachevol(data_lv, 1)) {
log_error("Failed to detach writecache from %s", display_lvname(data_lv));
return 0;
}
if (!lv_remove_single(cmd, cachevol_lv, force, 1)) {
log_error("Failed to remove cachevol %s.", display_lvname(cachevol_lv));
return 0;
}
}
}
writecache: allow removing LV with attached writecache
2019-09-24 23:33:09 +03:00
if (lv_is_writecache(lv)) {
struct logical_volume *cachevol_lv = first_seg(lv)->writecache;
if (!deactivate_lv(cmd, lv)) {
log_error("Failed to deactivate LV %s", display_lvname(lv));
return 0;
}
if (!lv_detach_writecache_cachevol(lv, 1)) {
log_error("Failed to detach writecache from %s", display_lvname(lv));
return 0;
}
if (!lv_remove_single(cmd, cachevol_lv, force, suppress_remove_message)) {
log_error("Failed to remove cachevol %s.", display_lvname(cachevol_lv));
return 0;
}
}
lvremove: Ask before discarding data areas.
2012-09-26 14:23:44 +04:00
metadata: add historical_glv_remove
2016-03-01 17:26:57 +03:00
/* Used cache pool, COW or historical LV cannot be activated */
cleanup: use lv_is_used_cache_pool Use lv_is_used_cache_pool() to simplify the code. Function was introduced later and this code missed to use it.
2018-02-28 19:38:43 +03:00
if (!lv_is_used_cache_pool(lv) &&
cachevol: support removal of cachevol Removal of cachevol is equivalent of lvconvert --uncache and works the same way as with cachepool.
2019-10-17 13:48:56 +03:00
!lv_is_cache_vol(lv) &&
metadata: add historical_glv_remove
2016-03-01 17:26:57 +03:00
!lv_is_cow(lv) && !lv_is_historical(lv) &&
lvremove: ensure no subLV is active Since component activation is going to be enabled, enusure, no subLV is active when we deactivate LV.
2018-03-03 00:07:14 +03:00
!deactivate_lv_with_sub_lv(lv))
pool: fix removal of pool metadata spare Since we support device stack of pools over pool (thin-pool with cache data volume) the existing code is no longer able to detect orphan _pmspare. So instead do a _pmspare check after volume removal, and remove spare afterwards.
2014-11-13 15:09:07 +03:00
/* FIXME Review and fix the snapshot error paths! */
lvremove: ensure no subLV is active Since component activation is going to be enabled, enusure, no subLV is active when we deactivate LV.
2018-03-03 00:07:14 +03:00
return_0;
cache: lvremoved cached LV removes cache pool When we remove cached volume, whole tree must go down. There is 'lvconvert --splitcache' to preserve cache pool.
2014-10-04 01:36:11 +04:00
raid: move VG update after archiving happened Update of LV le_count needs to happen after archive().
2018-03-06 15:38:00 +03:00
/* Special case removing a striped raid LV with allocated reshape space */
if (seg && seg->reshape_len) {
if (!(seg->segtype = get_segtype_from_string(cmd, SEG_TYPE_NAME_STRIPED)))
return_0;
lv->le_count = seg->len = seg->area_len = seg_lv(seg, 0)->le_count * seg->area_count;
}
pool: fix removal of pool metadata spare Since we support device stack of pools over pool (thin-pool with cache data volume) the existing code is no longer able to detect orphan _pmspare. So instead do a _pmspare check after volume removal, and remove spare afterwards.
2014-11-13 15:09:07 +03:00
/* Clear thin pool stacked messages */
thin: rename internal function Names matching internal code layout. Functionc in thin_manip.c uses thin_pool in its name. Keep 'pool' only for function working for both cache and thin pools. No change of functionality.
2022-08-24 16:02:07 +03:00
if (pool_lv && thin_pool_has_message(first_seg(pool_lv), lv, 0) &&
!update_thin_pool_lv(pool_lv, 1)) {
pool: fix removal of pool metadata spare Since we support device stack of pools over pool (thin-pool with cache data volume) the existing code is no longer able to detect orphan _pmspare. So instead do a _pmspare check after volume removal, and remove spare afterwards.
2014-11-13 15:09:07 +03:00
if (force < DONT_PROMPT_OVERRIDE) {
log_error("Failed to update pool %s.", display_lvname(pool_lv));
return 0;
}
log_print_unless_silent("Ignoring update failure of pool %s.",
display_lvname(pool_lv));
pool_lv = NULL; /* Do not retry */
}
cache: use LV_PENDING_DELETE
2014-11-10 12:56:43 +03:00
/* When referenced by the LV with pending delete flag, remove this deleted LV first */
dm_list_iterate_items(sl, &lv->segs_using_this_lv)
if (lv_is_pending_delete(sl->seg->lv) && !lv_remove(sl->seg->lv)) {
log_error("Error releasing logical volume %s with pending delete.",
display_lvname(sl->seg->lv));
return 0;
}
Move lv_remove_single() into library (lv_manip.c, metadata-exported.h). Move yes_no_prompt() into library (display.c, display.h). Fixup includes as a result of movement of prior two functions. Fixup force_t enum to be more descriptive.
2007-08-20 21:04:53 +04:00
if (lv_is_cow(lv)) {
debug: use display_lvname
2016-05-20 12:28:23 +03:00
log_verbose("Removing snapshot volume %s.", display_lvname(lv));
Move snapshot deactivation logic into lib/activate, fixing the teardown sequence. (Previously the snapshot was deactivated while its origin was active and before its removal was committed to disk, so restarting after a crash at the point would leave corruption.)
2011-07-08 16:48:41 +04:00
/* vg_remove_snapshot() will preload origin/former snapshots */
Use stack return macros throughout.
2008-01-30 16:19:47 +03:00
if (!vg_remove_snapshot(lv))
return_0;
Refactor snapshot-merge deptree and device removal to support info-by-uuid Add a merging snapshot to the deptree, using the "error" target, rather than avoid adding it entirely. This allows proper cleanup of the -cow device without having to rename the -cow to use the origin's name as a prefix. Move the preloading of the origin LV, after a merge, from lv_remove_single() to vg_remove_snapshot(). Having vg_remove_snapshot() preload the origin allows the -cow device to be released so that it can be removed via deactivate_lv(). lv_remove_single()'s deactivate_lv() reliably removes the -cow device because the associated snapshot LV, that is to be removed when a snapshot-merge completes, is always added to the deptree (and kernel -- via "error" target). Now when the snapshot LV is removed both the -cow and -real devices get removed using uuid rather than device name. This paves the way for us to switch over to info-by-uuid queries. Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2010-02-18 01:59:46 +03:00
pool: fix removal of pool metadata spare Since we support device stack of pools over pool (thin-pool with cache data volume) the existing code is no longer able to detect orphan _pmspare. So instead do a _pmspare check after volume removal, and remove spare afterwards.
2014-11-13 15:09:07 +03:00
if (!deactivate_lv(cmd, lv)) {
/* FIXME Review and fix the snapshot error paths! */
log_error("Unable to deactivate logical volume %s.",
display_lvname(lv));
return 0;
pools: move removal of _pmspare Since _pmspare is internal volume move it to lv_remove_single - so it's automatically removed with last remove thin-pool. lv_remove_with_dependencies() is not always used for pool removal.
2014-10-04 01:34:16 +04:00
}
}
writecache: remove from an active lv
2020-02-24 22:52:12 +03:00
if (lv_is_cache_vol(lv)) {
if ((cache_seg = get_only_segment_using_this_lv(lv))) {
/* When used with cache, lvremove on cachevol also removes the cache! */
if (seg_is_cache(cache_seg)) {
if (!lv_cache_remove(cache_seg->lv))
return_0;
} else if (seg_is_writecache(cache_seg)) {
log_error("Detach cachevol before removing.");
return 0;
}
}
}
if (lv_is_used_cache_pool(lv)) {
cache: fix order of metadata change Start to change metadata after they are archived. And since cache_pool is virtual skip deactivation call for this LV.
2014-04-01 20:08:38 +04:00
/* Cache pool removal drops cache layer
* If the cache pool is not linked, we can simply remove it. */
cleanup: use lv_is_used_cache_pool Use lv_is_used_cache_pool() to simplify the code. Function was introduced later and this code missed to use it.
2018-02-28 19:38:43 +03:00
if (!(cache_seg = get_only_segment_using_this_lv(lv)))
return_0;
/* TODO: polling */
if (!lv_cache_remove(cache_seg->lv))
return_0;
Thin clear stacked message for thin pool Before removing thin pool LV always make sure, stacked message for previous run are cleared - but allow to remove any device that should have been created (i.e. creation of snapshot failed - so the message for snapshot creation may be replaced with delete message within unfinished transaction). Also commit messages after lv remove - so free space is released in pool.
2012-01-25 15:27:42 +04:00
}
Properly show LV removal message. (Fix regression in commit 6e181ba96dc1f806afc2d7fe825a8d3dd8093052)
2012-01-24 18:15:52 +04:00
visible = lv_is_visible(lv);
commands: lvremove: also process historical LVs
2016-03-01 17:27:08 +03:00
historical = lv_is_historical(lv);
Properly show LV removal message. (Fix regression in commit 6e181ba96dc1f806afc2d7fe825a8d3dd8093052)
2012-01-24 18:15:52 +04:00
commands: lvremove: also process historical LVs
2016-03-01 17:27:08 +03:00
log_verbose("Releasing %slogical volume \"%s\"",
historical ? "historical " : "",
historical ? lv->this_glv->historical->name : lv->name);
Move lv_remove_single() into library (lv_manip.c, metadata-exported.h). Move yes_no_prompt() into library (display.c, display.h). Fixup includes as a result of movement of prior two functions. Fixup force_t enum to be more descriptive.
2007-08-20 21:04:53 +04:00
if (!lv_remove(lv)) {
commands: lvremove: also process historical LVs
2016-03-01 17:27:08 +03:00
log_error("Error releasing %slogical volume \"%s\"",
historical ? "historical ": "",
historical ? lv->this_glv->historical->name : lv->name);
Move lv_remove_single() into library (lv_manip.c, metadata-exported.h). Move yes_no_prompt() into library (display.c, display.h). Fixup includes as a result of movement of prior two functions. Fixup force_t enum to be more descriptive.
2007-08-20 21:04:53 +04:00
return 0;
}
lv_remove: reduce commits for removed LVs This patch postpones update of lvm metadata for each removed LV for later moment depending on LV type. It also queues messages to be printed after such write & commit. As such there is some change in the behavior - although before prompt we do make write&commit happens automatically in some other error case we rather keep 'existing' state - so there could be difference in amount of removed & commited LVs. IMHO introduce logic is slightly better and more save. But some cases still need the early commit - i.e. thin-removal and fixing this needs some more thinking. TODO: improve removal at least with the case of the whole thin-pool. i.e. we can simply recognize removal of 'all LVs/whole VG'.
2021-03-05 18:21:50 +03:00
if (!pool_lv && (!strcmp(cmd->name, "lvremove") || !strcmp(cmd->name, "vgremove"))) {
/* With lvremove & vgremove try to postpone commit after last such LV */
vg->needs_write_and_commit = 1;
log_debug_metadata("Postponing write and commit.");
} else if (!vg_write(vg) || !vg_commit(vg)) /* store it on disks */
Preload the origin prior to suspend IFF snapshot(s) still exist after a merge completes. This narrows the scope of this "hack" (which still needs a proper fix within the deptree). This stops dmeventd from trying to access snapshot devices that were already removed.
2010-01-21 00:53:10 +03:00
return_0;
Thin clear stacked message for thin pool Before removing thin pool LV always make sure, stacked message for previous run are cleared - but allow to remove any device that should have been created (i.e. creation of snapshot failed - so the message for snapshot creation may be replaced with delete message within unfinished transaction). Also commit messages after lv remove - so free space is released in pool.
2012-01-25 15:27:42 +04:00
/* Release unneeded blocks in thin pool */
/* TODO: defer when multiple LVs relased at once */
thin: rename internal function Names matching internal code layout. Functionc in thin_manip.c uses thin_pool in its name. Keep 'pool' only for function working for both cache and thin pools. No change of functionality.
2022-08-24 16:02:07 +03:00
if (pool_lv && !update_thin_pool_lv(pool_lv, 1)) {
thin: more forced ignoring of pool failure Support also 'vgremove -ff' to properly remove even inactive/broken thin pools. Update messages to use 'print_unless_silent' for the forced case.
2014-08-26 13:53:56 +04:00
if (force < DONT_PROMPT_OVERRIDE) {
thin: rename internal function Names matching internal code layout. Functionc in thin_manip.c uses thin_pool in its name. Keep 'pool' only for function working for both cache and thin pools. No change of functionality.
2022-08-24 16:02:07 +03:00
log_error("Failed to update thin pool %s.", display_lvname(pool_lv));
thin: more forced ignoring of pool failure Support also 'vgremove -ff' to properly remove even inactive/broken thin pools. Update messages to use 'print_unless_silent' for the forced case.
2014-08-26 13:53:56 +04:00
return 0;
}
log_print_unless_silent("Ignoring update failure of pool %s.",
display_lvname(pool_lv));
Thin clear stacked message for thin pool Before removing thin pool LV always make sure, stacked message for previous run are cleared - but allow to remove any device that should have been created (i.e. creation of snapshot failed - so the message for snapshot creation may be replaced with delete message within unfinished transaction). Also commit messages after lv remove - so free space is released in pool.
2012-01-25 15:27:42 +04:00
}
cov: check return value Log problems on fail path.
2021-04-22 18:00:45 +03:00
if (!lockd_lv(cmd, lv, "un", LDLV_PERSISTENT))
log_warn("WARNING: Failed to unlock %s.", display_lvname(lv));
Add lvmlockd
2015-03-05 23:00:44 +03:00
lockd_free_lv(cmd, vg, lv->name, &lv->lvid.id[1], lv->lock_args);
lv_remove: reduce commits for removed LVs This patch postpones update of lvm metadata for each removed LV for later moment depending on LV type. It also queues messages to be printed after such write & commit. As such there is some change in the behavior - although before prompt we do make write&commit happens automatically in some other error case we rather keep 'existing' state - so there could be difference in amount of removed & commited LVs. IMHO introduce logic is slightly better and more save. But some cases still need the early commit - i.e. thin-removal and fixing this needs some more thinking. TODO: improve removal at least with the case of the whole thin-pool. i.e. we can simply recognize removal of 'all LVs/whole VG'.
2021-03-05 18:21:50 +03:00
if (!suppress_remove_message && (visible || historical)) {
(void) dm_snprintf(msg, sizeof(msg),
debug: update message
2021-03-14 15:15:50 +03:00
"%sogical volume \"%s\" successfully removed.",
lv_remove: reduce commits for removed LVs This patch postpones update of lvm metadata for each removed LV for later moment depending on LV type. It also queues messages to be printed after such write & commit. As such there is some change in the behavior - although before prompt we do make write&commit happens automatically in some other error case we rather keep 'existing' state - so there could be difference in amount of removed & commited LVs. IMHO introduce logic is slightly better and more save. But some cases still need the early commit - i.e. thin-removal and fixing this needs some more thinking. TODO: improve removal at least with the case of the whole thin-pool. i.e. we can simply recognize removal of 'all LVs/whole VG'.
2021-03-05 18:21:50 +03:00
historical ? "Historical l" : "L",
historical ? lv->this_glv->historical->name : lv->name);
if (!vg->needs_write_and_commit)
log_print_unless_silent("%s", msg);
/* Keep print message for later display with next vg_write() and vg_commit() */
else if (!(msg_dup = dm_pool_strdup(vg->vgmem, msg)) ||
!str_list_add_no_dup_check(vg->vgmem, &vg->msg_list, msg_dup))
return_0;
}
Suppress 'removed' messages displayed when internal LVs are removed. Fix lvchange -a and -p for sparse LVs. Fix lvcreate --virtualsize to activate the new device immediately.
2009-05-27 22:19:21 +04:00
Move lv_remove_single() into library (lv_manip.c, metadata-exported.h). Move yes_no_prompt() into library (display.c, display.h). Fixup includes as a result of movement of prior two functions. Fixup force_t enum to be more descriptive.
2007-08-20 21:04:53 +04:00
return 1;
}
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
lvremove: easier removal of dependent lvs Add function to remove lvs which are depending on removed lv prior the lv is removed. User is asked for confirmation.
2013-02-20 19:13:17 +04:00
static int _lv_remove_segs_using_this_lv(struct cmd_context *cmd, struct logical_volume *lv,
const force_t force, unsigned level,
const char *lv_type)
{
struct seg_list *sl;
if ((force == PROMPT) &&
debug: update message
2021-03-14 15:15:50 +03:00
yes_no_prompt("Removing %s %s will remove %u dependent volume(s). "
"Proceed? [y/n]: ", lv_type, display_lvname(lv),
lvremove: easier removal of dependent lvs Add function to remove lvs which are depending on removed lv prior the lv is removed. User is asked for confirmation.
2013-02-20 19:13:17 +04:00
dm_list_size(&lv->segs_using_this_lv)) == 'n') {
lvremove: use to_remove for snapshot removal Reuse similar 'acceleration' as used for dependent volumes also for snapshot - so when origin is being removed with all thick snapshots, don't bother with individual 'COW' detachments and write&commits, and when possible handle this all within a single commit.
2021-03-14 15:18:45 +03:00
lv->to_remove = 0;
debug: update message
2021-03-14 15:15:50 +03:00
log_error("Logical volume %s not removed.", display_lvname(lv));
lvremove: use to_remove for snapshot removal Reuse similar 'acceleration' as used for dependent volumes also for snapshot - so when origin is being removed with all thick snapshots, don't bother with individual 'COW' detachments and write&commits, and when possible handle this all within a single commit.
2021-03-14 15:18:45 +03:00
return 0;
}
lvremove: support faster removal of thin-pools When lvremove/vgremove removes thin volumes with its thin-pool as well, try to skip any updates of such thin-pool, so when everything properly deactivates, there is no message send to this thin-pool and whole thin-pool is removed with a single commit.
2021-03-11 01:19:25 +03:00
lvremove: easier removal of dependent lvs Add function to remove lvs which are depending on removed lv prior the lv is removed. User is asked for confirmation.
2013-02-20 19:13:17 +04:00
/*
* Not using _safe iterator here - since we may delete whole subtree
* (similar as process_each_lv_in_vg())
* the code is roughly equivalent to this:
*
* while (!dm_list_empty(&lv->segs_using_this_lv))
* dm_list_iterate_items(sl, &lv->segs_using_this_lv)
* break;
*/
dm_list_iterate_items(sl, &lv->segs_using_this_lv)
if (!lv_remove_with_dependencies(cmd, sl->seg->lv,
force, level + 1))
return_0;
return 1;
}
vgremove tries to remove lv snapshot first. Added function lv_remove_with_dependencies().
2008-08-05 16:05:26 +04:00
/*
* remove LVs with its dependencies - LV leaf nodes should be removed first
*/
int lv_remove_with_dependencies(struct cmd_context *cmd, struct logical_volume *lv,
Disallow the direct removal of a merging snapshot. Allow lv_remove_with_dependencies() to know the top-level LV that was requested to be removed (otherwise it recurses and we lose context). A merging snapshot cannot be removed directly but the associated origin can be. Disallow removal of a merging snapshot unless the associated origin is also being removed.
2010-04-23 23:27:10 +04:00
const force_t force, unsigned level)
vgremove tries to remove lv snapshot first. Added function lv_remove_with_dependencies().
2008-08-05 16:05:26 +04:00
{
report: select: refactor: move percent handling code to libdm for reuse
2014-06-09 14:08:27 +04:00
dm_percent_t snap_percent;
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
struct dm_list *snh, *snht;
Allow removal of an invalid snapshot that was to be merged on next activation. Don't allow a user to merge an invalid snapshot.
2012-01-21 02:03:48 +04:00
struct lvinfo info;
pools: prompt only when metadata lv exists If the VG has no pool metadata volume, don't prompt about removal of _pmspare.
2014-11-08 15:53:13 +03:00
struct lv_list *lvl;
snapshot: move virtsnap code from tool to lib Move code for removal dependency from tool's remove.c into lib's manipulation code. Same code then works with lvm2app.
2013-10-12 00:42:34 +04:00
struct logical_volume *origin;
vgremove tries to remove lv snapshot first. Added function lv_remove_with_dependencies().
2008-08-05 16:05:26 +04:00
lvremove: use to_remove for snapshot removal Reuse similar 'acceleration' as used for dependent volumes also for snapshot - so when origin is being removed with all thick snapshots, don't bother with individual 'COW' detachments and write&commits, and when possible handle this all within a single commit.
2021-03-14 15:18:45 +03:00
/* Make aware users of this LV, it's going to be removed, so they
* can skip any updates of itself */
lv->to_remove = 1;
cleanup: move common condition
2021-03-14 15:15:24 +03:00
if (!level && lv_is_cow(lv)) {
Allow removal of an invalid snapshot that was to be merged on next activation. Don't allow a user to merge an invalid snapshot.
2012-01-21 02:03:48 +04:00
/*
* A merging snapshot cannot be removed directly unless
Prompt if request is made to remove a snapshot whose "Merge failed".
2012-01-21 02:04:16 +04:00
* it has been invalidated or failed merge removal is requested.
Allow removal of an invalid snapshot that was to be merged on next activation. Don't allow a user to merge an invalid snapshot.
2012-01-21 02:03:48 +04:00
*/
cleanup: move common condition
2021-03-14 15:15:24 +03:00
if (lv_is_merging_cow(lv)) {
Allow removal of an invalid snapshot that was to be merged on next activation. Don't allow a user to merge an invalid snapshot.
2012-01-21 02:03:48 +04:00
if (lv_info(lv->vg->cmd, lv, 0, &info, 1, 0) &&
info.exists && info.live_table) {
missing error mesg
2012-02-13 01:37:03 +04:00
if (!lv_snapshot_percent(lv, &snap_percent)) {
cleanup: use display_lvname
2016-06-23 14:04:37 +03:00
log_error("Failed to obtain merging snapshot progress "
"percentage for logical volume %s.",
display_lvname(lv));
missing error mesg
2012-02-13 01:37:03 +04:00
return 0;
}
tidy: prefer not using else after return clang-tidy: avoid using 'else' after return - give more readable code, and also saves indention level.
2017-07-19 17:16:12 +03:00
report: select: refactor: move percent handling code to libdm for reuse
2014-06-09 14:08:27 +04:00
if ((snap_percent != DM_PERCENT_INVALID) &&
(snap_percent != LVM_PERCENT_MERGE_FAILED)) {
cleanup: use display_lvname
2016-06-23 14:04:37 +03:00
log_error("Can't remove merging snapshot logical volume %s.",
display_lvname(lv));
Allow removal of an invalid snapshot that was to be merged on next activation. Don't allow a user to merge an invalid snapshot.
2012-01-21 02:03:48 +04:00
return 0;
tidy: prefer not using else after return clang-tidy: avoid using 'else' after return - give more readable code, and also saves indention level.
2017-07-19 17:16:12 +03:00
}
if ((snap_percent == LVM_PERCENT_MERGE_FAILED) &&
(force == PROMPT) &&
yes_no_prompt("Removing snapshot %s that failed to merge "
"may leave origin %s inconsistent. Proceed? [y/n]: ",
display_lvname(lv),
display_lvname(origin_from_cow(lv))) == 'n')
goto no_remove;
Allow removal of an invalid snapshot that was to be merged on next activation. Don't allow a user to merge an invalid snapshot.
2012-01-21 02:03:48 +04:00
}
cleanup: move common condition
2021-03-14 15:15:24 +03:00
} else if (lv_is_virtual_origin(origin = origin_from_cow(lv)))
snapshot: move virtsnap code from tool to lib Move code for removal dependency from tool's remove.c into lib's manipulation code. Same code then works with lvm2app.
2013-10-12 00:42:34 +04:00
/* If this is a sparse device, remove its origin too. */
/* Stacking is not supported */
lv = origin;
Disallow the direct removal of a merging snapshot. Allow lv_remove_with_dependencies() to know the top-level LV that was requested to be removed (otherwise it recurses and we lose context). A merging snapshot cannot be removed directly but the associated origin can be. Disallow removal of a merging snapshot unless the associated origin is also being removed.
2010-04-23 23:27:10 +04:00
}
if (lv_is_origin(lv)) {
Query before removing inactive snapshots Removal of an inactive origin removes also all related snapshots. When we now support 'old' external snapshots with thin volumes, removal of pool will not only drop all thin volumes, but as a consequence also all snapshots - which might be seen a bit unexpected for the user - so add a query to confirm such action. lvremove -f will skip the prompt.
2011-11-18 23:25:20 +04:00
/* Remove snapshot LVs first */
lvremove: use common routine for prompting Move code for prompting about removed LV to a single function and use it also to prompt for removal of origin and all its thick snapshots and also when removing merging origin. Function does handle postponed write_and_commit so there is no 'in-flight' operation while waiting on [y|n] answer.
2021-03-14 15:17:03 +03:00
if (!_lv_remove_check_in_use(lv, force))
return_0;
Query before removing inactive snapshots Removal of an inactive origin removes also all related snapshots. When we now support 'old' external snapshots with thin volumes, removal of pool will not only drop all thin volumes, but as a consequence also all snapshots - which might be seen a bit unexpected for the user - so add a query to confirm such action. lvremove -f will skip the prompt.
2011-11-18 23:25:20 +04:00
lvremove: use common routine for prompting Move code for prompting about removed LV to a single function and use it also to prompt for removal of origin and all its thick snapshots and also when removing merging origin. Function does handle postponed write_and_commit so there is no 'in-flight' operation while waiting on [y|n] answer.
2021-03-14 15:17:03 +03:00
if (!deactivate_lv(cmd, lv))
snapshot: improve removal of active origin volume Previously when lvremove tried to remove 'active' origin, it had been asking for every 'snapshot' LV separately and doing individual single snapshot removals first. To be faster it now deactivates origin before removal all connected snapshots. This avoids multiple reloads of dm table for origin volume which were unnecessary as origin was meant to be removed as well.
2017-02-22 17:12:54 +03:00
goto no_remove;
lvremove: use common routine for prompting Move code for prompting about removed LV to a single function and use it also to prompt for removal of origin and all its thick snapshots and also when removing merging origin. Function does handle postponed write_and_commit so there is no 'in-flight' operation while waiting on [y|n] answer.
2021-03-14 15:17:03 +03:00
snapshot: improve removal of active origin volume Previously when lvremove tried to remove 'active' origin, it had been asking for every 'snapshot' LV separately and doing individual single snapshot removals first. To be faster it now deactivates origin before removal all connected snapshots. This avoids multiple reloads of dm table for origin volume which were unnecessary as origin was meant to be removed as well.
2017-02-22 17:12:54 +03:00
log_verbose("Removing origin logical volume %s with %u snapshots(s).",
display_lvname(lv), lv->origin_count);
Add missing stack reporting also remove unneeded {}
2011-11-13 02:53:23 +04:00
dm_list_iterate_safe(snh, snht, &lv->snapshot_segs)
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
if (!lv_remove_with_dependencies(cmd, dm_list_struct_base(snh, struct lv_segment,
Disallow the direct removal of a merging snapshot. Allow lv_remove_with_dependencies() to know the top-level LV that was requested to be removed (otherwise it recurses and we lose context). A merging snapshot cannot be removed directly but the associated origin can be. Disallow removal of a merging snapshot unless the associated origin is also being removed.
2010-04-23 23:27:10 +04:00
origin_list)->cow,
force, level + 1))
Add missing stack reporting also remove unneeded {}
2011-11-13 02:53:23 +04:00
return_0;
lvremove: use common routine for prompting Move code for prompting about removed LV to a single function and use it also to prompt for removal of origin and all its thick snapshots and also when removing merging origin. Function does handle postponed write_and_commit so there is no 'in-flight' operation while waiting on [y|n] answer.
2021-03-14 15:17:03 +03:00
} else if (lv_is_merging_origin(lv)) {
/* Removing thin merging origin requires to remove its merging snapshot first */
if (!_lv_remove_check_in_use(lv, force))
return_0;
if (!deactivate_lv(cmd, lv))
goto no_remove;
log_verbose("Removing merging origin logical volume %s.", display_lvname(lv));
vgremove tries to remove lv snapshot first. Added function lv_remove_with_dependencies().
2008-08-05 16:05:26 +04:00
thin: merge removal When thin is merged - properly handly device removal.
2013-11-30 00:21:00 +04:00
if (!lv_remove_with_dependencies(cmd, find_snapshot(lv)->lv,
lvremove: use common routine for prompting Move code for prompting about removed LV to a single function and use it also to prompt for removal of origin and all its thick snapshots and also when removing merging origin. Function does handle postponed write_and_commit so there is no 'in-flight' operation while waiting on [y|n] answer.
2021-03-14 15:17:03 +03:00
force, level + 1))
return_0;
thin: merge removal When thin is merged - properly handly device removal.
2013-11-30 00:21:00 +04:00
}
if (!level && lv_is_merging_thin_snapshot(lv)) {
/* Merged snapshot LV is no longer available for the user */
cleanup: use display_lvname
2016-06-23 14:04:37 +03:00
log_error("Unable to remove %s, volume is merged to %s.",
display_lvname(lv), display_lvname(first_seg(lv)->merge_lv));
thin: merge removal When thin is merged - properly handly device removal.
2013-11-30 00:21:00 +04:00
return 0;
}
writecache: allow removing wcorig lv like removing corig
2020-02-21 21:40:42 +03:00
if (lv_is_cache_origin(lv) || lv_is_writecache_origin(lv)) {
cache: improve vgremove loop Support internal removal of 'cache origin' volume - which we do not normally expose to a user - however internal processing loops may hit this condition (depending on order of list LVs). So when this operation is internally requested - we automatically try to remove it's 'holding' LV (cache LV) - which will also remove the origin.
2019-08-26 14:28:00 +03:00
if (!_lv_remove_segs_using_this_lv(cmd, lv, force, level, "cache origin"))
return_0;
/* Removal of cache LV also removes caching origin */
return 1;
}
thin: removal of external_origin
2013-02-20 19:14:24 +04:00
if (lv_is_external_origin(lv) &&
!_lv_remove_segs_using_this_lv(cmd, lv, force, level, "external origin"))
return_0;
lvremove: easier removal of dependent lvs Add function to remove lvs which are depending on removed lv prior the lv is removed. User is asked for confirmation.
2013-02-20 19:13:17 +04:00
if (lv_is_used_thin_pool(lv) &&
!_lv_remove_segs_using_this_lv(cmd, lv, force, level, "pool"))
return_0;
cleanup: indent and stacktrack Add missing stacktrace on error path and newline indent.
2014-08-26 13:39:51 +04:00
vdo: introduce segment types and manip functions Core functionality introducing lvm VDO support.
2018-06-29 12:11:14 +03:00
if (lv_is_vdo_pool(lv)) {
if (!_lv_remove_segs_using_this_lv(cmd, lv, force, level, "VDO pool"))
return_0;
/* Last user removes VDO pool itself, lv no longer exists */
return 1;
}
lvremove: for unused cache deactive sublv
2017-11-11 02:19:04 +03:00
if (lv_is_cache_pool(lv) && !lv_is_used_cache_pool(lv)) {
if (!deactivate_lv(cmd, first_seg(lv)->metadata_lv) ||
!deactivate_lv(cmd, seg_lv(first_seg(lv),0))) {
log_error("Unable to fully deactivate unused cache-pool %s.",
display_lvname(lv));
return 0;
}
}
thin: removal of spare disables recovery Warn user when removing spare LV. Remove spare automatically, when last pool from VG is removed.
2013-06-17 21:54:15 +04:00
if (lv_is_pool_metadata_spare(lv) &&
pools: prompt only when metadata lv exists If the VG has no pool metadata volume, don't prompt about removal of _pmspare.
2014-11-08 15:53:13 +03:00
(force == PROMPT)) {
dm_list_iterate_items(lvl, &lv->vg->lvs)
if (lv_is_pool_metadata(lvl->lv)) {
cleanup: use display_lvname
2016-06-23 14:04:37 +03:00
if (yes_no_prompt("Removal of pool metadata spare logical volume "
"%s disables automatic recovery attempts "
"after damage to a thin or cache pool. "
"Proceed? [y/n]: ", display_lvname(lv)) == 'n')
pools: prompt only when metadata lv exists If the VG has no pool metadata volume, don't prompt about removal of _pmspare.
2014-11-08 15:53:13 +03:00
goto no_remove;
break;
}
}
thin: removal of spare disables recovery Warn user when removing spare LV. Remove spare automatically, when last pool from VG is removed.
2013-06-17 21:54:15 +04:00
lv_remove_single: add silent arg Support silence for removal message.
2013-11-29 20:00:55 +04:00
return lv_remove_single(cmd, lv, force, 0);
cleanup: share the nonremoval message Use common goto label for not remove log error.
2013-11-12 18:08:35 +04:00
no_remove:
cleanup: use display_lvname
2016-06-23 14:04:37 +03:00
log_error("Logical volume %s not removed.", display_lvname(lv));
cleanup: share the nonremoval message Use common goto label for not remove log error.
2013-11-12 18:08:35 +04:00
return 0;
vgremove tries to remove lv snapshot first. Added function lv_remove_with_dependencies().
2008-08-05 16:05:26 +04:00
}
lv_rename: fix snapshot rename Fix rename operation for snapshot (cow) LV. Only the snapshot's origin has the lock and by mistake suspend and resume has been called for the snapshot LV. This further made volumes unusable in cluster. So instead of suspend and resuming list of LVs, we need to just suspend and resume origin. As the sequence write/suspend/commit/resume is widely used in lvm2 code base - move it to new lv_update_and_reload function.
2014-09-09 20:47:27 +04:00
static int _lv_update_and_reload(struct logical_volume *lv, int origin_only)
{
struct volume_group *vg = lv->vg;
backup: automatically store data on vg_unlock Previously there have been necessary explicit call of backup (often either forgotten or over-used). With this patch the necessity to store backup is remember at vg_commit and once the VG is unlocked, the committed metadata are automatically store in backup file. This may possibly alter some printed messages from command when the backup is now taken later.
2021-06-08 20:39:15 +03:00
int r = 0;
lv_update_and_reload: use proper lock holder When requesting to reload an LV imrove this API to automatically reload its lock holding LV as in cluster only top-level LVs are addressable with lock.
2014-09-22 15:57:47 +04:00
const struct logical_volume *lock_lv = lv_lock_holder(lv);
lv_rename: fix snapshot rename Fix rename operation for snapshot (cow) LV. Only the snapshot's origin has the lock and by mistake suspend and resume has been called for the snapshot LV. This further made volumes unusable in cluster. So instead of suspend and resuming list of LVs, we need to just suspend and resume origin. As the sequence write/suspend/commit/resume is widely used in lvm2 code base - move it to new lv_update_and_reload function.
2014-09-09 20:47:27 +04:00
debug: mention origin_only in message
2016-09-19 14:48:54 +03:00
log_very_verbose("Updating logical volume %s on disk(s)%s.",
display_lvname(lock_lv), origin_only ? " (origin only)": "");
lv_rename: fix snapshot rename Fix rename operation for snapshot (cow) LV. Only the snapshot's origin has the lock and by mistake suspend and resume has been called for the snapshot LV. This further made volumes unusable in cluster. So instead of suspend and resuming list of LVs, we need to just suspend and resume origin. As the sequence write/suspend/commit/resume is widely used in lvm2 code base - move it to new lv_update_and_reload function.
2014-09-09 20:47:27 +04:00
if (!vg_write(vg))
return_0;
debug: show message only when origin_only was set
2017-06-22 18:14:47 +03:00
if (origin_only && (lock_lv != lv)) {
activation: fix usage of origin_only When lock-holding LV differs from actually request locked LV, we drop origin_only flag as it has no use - it'd be applied on completely different LV. Example of problem: Raid is thin-pool _tdata LV. Raid run origin_only locking on stacked device. As lock holder is discovered thinLV. Whole origin_only operation is then applied only on thinLV changing the meaning of whole operation. NOTE: this patch does not change anything for LV that are already top-level lock holding LVs (i.e. thinLVs, snahoshots/origins).
2017-06-20 18:11:42 +03:00
log_debug_activation("Dropping origin_only for %s as lock holds %s",
display_lvname(lv), display_lvname(lock_lv));
origin_only = 0;
}
lv_update_and_reload: use proper lock holder When requesting to reload an LV imrove this API to automatically reload its lock holding LV as in cluster only top-level LVs are addressable with lock.
2014-09-22 15:57:47 +04:00
if (!(origin_only ? suspend_lv_origin(vg->cmd, lock_lv) : suspend_lv(vg->cmd, lock_lv))) {
writecache: remove from an active lv
2020-02-24 22:52:12 +03:00
log_error("Failed to suspend logical volume %s.",
lv_update_and_reload: use proper lock holder When requesting to reload an LV imrove this API to automatically reload its lock holding LV as in cluster only top-level LVs are addressable with lock.
2014-09-22 15:57:47 +04:00
display_lvname(lock_lv));
lv_rename: fix snapshot rename Fix rename operation for snapshot (cow) LV. Only the snapshot's origin has the lock and by mistake suspend and resume has been called for the snapshot LV. This further made volumes unusable in cluster. So instead of suspend and resuming list of LVs, we need to just suspend and resume origin. As the sequence write/suspend/commit/resume is widely used in lvm2 code base - move it to new lv_update_and_reload function.
2014-09-09 20:47:27 +04:00
vg_revert(vg);
activation: use revert_lv on tree suspend failure When thetable reload fails during suspend() - we were only calling plain resume() - and this will reload only those devices, which were left suspend, but will not try to restore metadata state according to lvm2 reverted metadata. So if we were reloading device tree - we have restored only top-level LV and rest of reverted device manipulation were left alone and possibly mismatched what is in committed metadata. FIXME: There are several cases were such revert will likely not work properly anyway as some operation are currenly handled in single commit, while they need multiple commits, but it's step towards better correctness. At least we catch there errors now earlier.
2020-09-22 14:35:27 +03:00
if (!revert_lv(vg->cmd, lock_lv))
log_error("Failed to revert logical volume %s.",
display_lvname(lock_lv));
return 0;
lv_rename: fix snapshot rename Fix rename operation for snapshot (cow) LV. Only the snapshot's origin has the lock and by mistake suspend and resume has been called for the snapshot LV. This further made volumes unusable in cluster. So instead of suspend and resuming list of LVs, we need to just suspend and resume origin. As the sequence write/suspend/commit/resume is widely used in lvm2 code base - move it to new lv_update_and_reload function.
2014-09-09 20:47:27 +04:00
} else if (!(r = vg_commit(vg)))
stack; /* !vg_commit() has implict vg_revert() */
log_very_verbose("Updating logical volume %s in kernel.",
lv_update_and_reload: use proper lock holder When requesting to reload an LV imrove this API to automatically reload its lock holding LV as in cluster only top-level LVs are addressable with lock.
2014-09-22 15:57:47 +04:00
display_lvname(lock_lv));
lv_rename: fix snapshot rename Fix rename operation for snapshot (cow) LV. Only the snapshot's origin has the lock and by mistake suspend and resume has been called for the snapshot LV. This further made volumes unusable in cluster. So instead of suspend and resuming list of LVs, we need to just suspend and resume origin. As the sequence write/suspend/commit/resume is widely used in lvm2 code base - move it to new lv_update_and_reload function.
2014-09-09 20:47:27 +04:00
lv_update_and_reload: use proper lock holder When requesting to reload an LV imrove this API to automatically reload its lock holding LV as in cluster only top-level LVs are addressable with lock.
2014-09-22 15:57:47 +04:00
if (!(origin_only ? resume_lv_origin(vg->cmd, lock_lv) : resume_lv(vg->cmd, lock_lv))) {
lv_rename: fix snapshot rename Fix rename operation for snapshot (cow) LV. Only the snapshot's origin has the lock and by mistake suspend and resume has been called for the snapshot LV. This further made volumes unusable in cluster. So instead of suspend and resuming list of LVs, we need to just suspend and resume origin. As the sequence write/suspend/commit/resume is widely used in lvm2 code base - move it to new lv_update_and_reload function.
2014-09-09 20:47:27 +04:00
log_error("Problem reactivating logical volume %s.",
lv_update_and_reload: use proper lock holder When requesting to reload an LV imrove this API to automatically reload its lock holding LV as in cluster only top-level LVs are addressable with lock.
2014-09-22 15:57:47 +04:00
display_lvname(lock_lv));
lv_rename: fix snapshot rename Fix rename operation for snapshot (cow) LV. Only the snapshot's origin has the lock and by mistake suspend and resume has been called for the snapshot LV. This further made volumes unusable in cluster. So instead of suspend and resuming list of LVs, we need to just suspend and resume origin. As the sequence write/suspend/commit/resume is widely used in lvm2 code base - move it to new lv_update_and_reload function.
2014-09-09 20:47:27 +04:00
r = 0;
}
return r;
}
int lv_update_and_reload(struct logical_volume *lv)
{
cleanup: use exiting function Reuse existing code and some indent change.
2016-12-14 13:34:28 +03:00
return _lv_update_and_reload(lv, 0);
lv_rename: fix snapshot rename Fix rename operation for snapshot (cow) LV. Only the snapshot's origin has the lock and by mistake suspend and resume has been called for the snapshot LV. This further made volumes unusable in cluster. So instead of suspend and resuming list of LVs, we need to just suspend and resume origin. As the sequence write/suspend/commit/resume is widely used in lvm2 code base - move it to new lv_update_and_reload function.
2014-09-09 20:47:27 +04:00
}
int lv_update_and_reload_origin(struct logical_volume *lv)
{
cleanup: use exiting function Reuse existing code and some indent change.
2016-12-14 13:34:28 +03:00
return _lv_update_and_reload(lv, 1);
lv_rename: fix snapshot rename Fix rename operation for snapshot (cow) LV. Only the snapshot's origin has the lock and by mistake suspend and resume has been called for the snapshot LV. This further made volumes unusable in cluster. So instead of suspend and resuming list of LVs, we need to just suspend and resume origin. As the sequence write/suspend/commit/resume is widely used in lvm2 code base - move it to new lv_update_and_reload function.
2014-09-09 20:47:27 +04:00
}
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
/*
* insert_layer_for_segments_on_pv() inserts a layer segment for a segment area.
* However, layer modification could split the underlying layer segment.
* This function splits the parent area according to keep the 1:1 relationship
* between the parent area and the underlying layer segment.
* Since the layer LV might have other layers below, build_parallel_areas()
* is used to find the lowest-level segment boundaries.
*/
static int _split_parent_area(struct lv_segment *seg, uint32_t s,
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
struct dm_list *layer_seg_pvs)
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
{
uint32_t parent_area_len, parent_le, layer_le;
uint32_t area_multiple;
struct seg_pvs *spvs;
if (seg_is_striped(seg))
area_multiple = seg->area_count;
else
area_multiple = 1;
parent_area_len = seg->area_len;
parent_le = seg->le;
layer_le = seg_le(seg, s);
while (parent_area_len > 0) {
/* Find the layer segment pointed at */
if (!(spvs = _find_seg_pvs_by_le(layer_seg_pvs, layer_le))) {
cleanup: use display_lvname
2016-06-23 14:04:37 +03:00
log_error("layer segment for %s:" FMTu32 " not found.",
display_lvname(seg->lv), parent_le);
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
return 0;
}
if (spvs->le != layer_le) {
log_error("Incompatible layer boundary: "
cleanup: use display_lvname
2016-06-23 14:04:37 +03:00
"%s:" FMTu32 "[" FMTu32 "] on %s:" FMTu32 ".",
display_lvname(seg->lv), parent_le, s,
display_lvname(seg_lv(seg, s)), layer_le);
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
return 0;
}
if (spvs->len < parent_area_len) {
parent_le += spvs->len * area_multiple;
if (!lv_split_segment(seg->lv, parent_le))
return_0;
}
parent_area_len -= spvs->len;
layer_le += spvs->len;
}
return 1;
}
/*
* Split the parent LV segments if the layer LV below it is splitted.
*/
int split_parent_segments_for_layer(struct cmd_context *cmd,
struct logical_volume *layer_lv)
{
struct lv_list *lvl;
struct logical_volume *parent_lv;
struct lv_segment *seg;
uint32_t s;
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
struct dm_list *parallel_areas;
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
raid/misc: Allow creation of parallel areas by LV vs segment I've changed build_parallel_areas_from_lv to take a new parameter that allows the caller to build parallel areas by LV vs by segment. Previously, the function created a list of parallel areas for each segment in the given LV. When it came time for allocation, the parallel areas were honored on a segment basis. This was problematic for RAID because any new RAID image must avoid being placed on any PVs used by other images in the RAID. For example, if we have a linear LV that has half its space on one PV and half on another, we do not want an up-convert to use either of those PVs. It should especially not wind up with the following, where the first portion of one LV is paired up with the second portion of the other: ------PV1------- ------PV2------- [ 2of2 image_1 ] [ 1of2 image_1 ] [ 1of2 image_0 ] [ 2of2 image_0 ] ---------------- ---------------- Previously, it was possible for this to happen. The change makes it so that the returned parallel areas list contains one "super" segment (seg_pvs) with a list of all the PVs from every actual segment in the given LV and covering the entire logical extent range. This change allows RAID conversions to function properly when there are existing images that contain multiple segments that span more than one PV.
2014-06-26 06:20:41 +04:00
if (!(parallel_areas = build_parallel_areas_from_lv(layer_lv, 0, 0)))
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
return_0;
/* Loop through all LVs except itself */
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
dm_list_iterate_items(lvl, &layer_lv->vg->lvs) {
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
parent_lv = lvl->lv;
if (parent_lv == layer_lv)
continue;
/* Find all segments that point at the layer LV */
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
dm_list_iterate_items(seg, &parent_lv->segments) {
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
for (s = 0; s < seg->area_count; s++) {
if (seg_type(seg, s) != AREA_LV ||
seg_lv(seg, s) != layer_lv)
continue;
if (!_split_parent_area(seg, s, parallel_areas))
return_0;
}
}
}
return 1;
}
/* Remove a layer from the LV */
int remove_layers_for_segments(struct cmd_context *cmd,
struct logical_volume *lv,
struct logical_volume *layer_lv,
Switch status from 32-bit to 64-bit The physical_volume, volume_group, logical_volume and lv_segment structures' 'status' member is now uint64_t. The alignment of these structures was also audited to remove holes. The movement of some members in 'volume_group' and 'lv_segment' eliminates holes. The 'physical_volume' structure still has one 4-byte hole after 'pe_size'; the other structures no longer have any holes. Each structures' size has not changed.
2009-11-25 01:55:55 +03:00
uint64_t status_mask, struct dm_list *lvs_changed)
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
{
struct lv_segment *seg, *lseg;
uint32_t s;
int lv_changed = 0;
struct lv_list *lvl;
add lvconvert messages
2008-01-19 01:00:46 +03:00
log_very_verbose("Removing layer %s for segments of %s",
layer_lv->name, lv->name);
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
/* Find all segments that point at the temporary mirror */
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
dm_list_iterate_items(seg, &lv->segments) {
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
for (s = 0; s < seg->area_count; s++) {
if (seg_type(seg, s) != AREA_LV ||
seg_lv(seg, s) != layer_lv)
continue;
/* Find the layer segment pointed at */
if (!(lseg = find_seg_by_le(layer_lv, seg_le(seg, s)))) {
log_error("Layer segment found: %s:%" PRIu32,
layer_lv->name, seg_le(seg, s));
return 0;
}
/* Check the segment params are compatible */
if (!seg_is_striped(lseg) || lseg->area_count != 1) {
log_error("Layer is not linear: %s:%" PRIu32,
layer_lv->name, lseg->le);
return 0;
}
pvvmove: add a few comments
2014-06-20 14:41:20 +04:00
if ((lseg->status & status_mask) != status_mask) {
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
log_error("Layer status does not match: "
Switch status from 32-bit to 64-bit The physical_volume, volume_group, logical_volume and lv_segment structures' 'status' member is now uint64_t. The alignment of these structures was also audited to remove holes. The movement of some members in 'volume_group' and 'lv_segment' eliminates holes. The 'physical_volume' structure still has one 4-byte hole after 'pe_size'; the other structures no longer have any holes. Each structures' size has not changed.
2009-11-25 01:55:55 +03:00
"%s:%" PRIu32 " status: 0x%" PRIx64 "/0x%" PRIx64,
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
layer_lv->name, lseg->le,
lseg->status, status_mask);
return 0;
}
if (lseg->le != seg_le(seg, s) ||
lseg->area_len != seg->area_len) {
log_error("Layer boundary mismatch: "
"%s:%" PRIu32 "-%" PRIu32 " on "
"%s:%" PRIu32 " / "
macros: Wrap PRI with FMT. Create a set of wrappers with embedded % such as #define FMTu64 "%" PRIu64
2015-07-06 17:09:17 +03:00
FMTu32 "-" FMTu32 " / ",
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
lv->name, seg->le, seg->area_len,
layer_lv->name, seg_le(seg, s),
lseg->le, lseg->area_len);
return 0;
}
if (!move_lv_segment_area(seg, s, lseg, 0))
return_0;
/* Replace mirror with error segment */
if (!(lseg->segtype =
segtypes: Use SEG_TYPE_NAME_ string constants.
2015-09-22 21:04:12 +03:00
get_segtype_from_string(lv->vg->cmd, SEG_TYPE_NAME_ERROR))) {
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
log_error("Missing error segtype");
return 0;
}
lseg->area_count = 0;
/* First time, add LV to list of LVs affected */
if (!lv_changed && lvs_changed) {
if (!(lvl = dm_pool_alloc(cmd->mem, sizeof(*lvl)))) {
log_error("lv_list alloc failed");
return 0;
}
lvl->lv = lv;
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
dm_list_add(lvs_changed, &lvl->list);
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
lv_changed = 1;
}
}
}
if (lv_changed && !lv_merge_segments(lv))
stack;
return 1;
}
/* Remove a layer */
int remove_layers_for_segments_all(struct cmd_context *cmd,
struct logical_volume *layer_lv,
Switch status from 32-bit to 64-bit The physical_volume, volume_group, logical_volume and lv_segment structures' 'status' member is now uint64_t. The alignment of these structures was also audited to remove holes. The movement of some members in 'volume_group' and 'lv_segment' eliminates holes. The 'physical_volume' structure still has one 4-byte hole after 'pe_size'; the other structures no longer have any holes. Each structures' size has not changed.
2009-11-25 01:55:55 +03:00
uint64_t status_mask,
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
struct dm_list *lvs_changed)
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
{
struct lv_list *lvl;
struct logical_volume *lv1;
/* Loop through all LVs except the temporary mirror */
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
dm_list_iterate_items(lvl, &layer_lv->vg->lvs) {
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
lv1 = lvl->lv;
if (lv1 == layer_lv)
continue;
if (!remove_layers_for_segments(cmd, lv1, layer_lv,
status_mask, lvs_changed))
pre-release review cleanups
2008-01-17 20:17:09 +03:00
return_0;
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
}
if (!lv_empty(layer_lv))
return_0;
pvmove: move code from tools to lib Move code manipulating with locking flags into /lib part of lvm.
2017-11-30 00:19:05 +03:00
/* Assumes only used by PVMOVE ATM when unlocking LVs */
dm_list_iterate_items(lvl, lvs_changed) {
/* FIXME Assumes only one pvmove at a time! */
lvl->lv->status &= ~LOCKED;
pvmove: add missing segment merging When pvmove is finished and metadata are updated, the code missed to merge possible mergable segments - so add explicit merging call after pvmoved volumes are unlocked. This avoids weird results where i.e. lvs could have been reporting non-matching segments as lvs upon metadata read is doing silent segment merging while dm table left after pvmove was still preserving non-merged segments.
2017-11-30 00:19:46 +03:00
if (!lv_merge_segments(lvl->lv))
return_0;
pvmove: move code from tools to lib Move code manipulating with locking flags into /lib part of lvm.
2017-11-30 00:19:05 +03:00
}
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
return 1;
}
Make move_lv_segment non-static This function could be useful for other _manip source files. Use dm_list manipulation function for provided functionality, which make the code more readable and avoid touching list internal details here.
2011-10-22 20:42:10 +04:00
int move_lv_segments(struct logical_volume *lv_to,
struct logical_volume *lv_from,
uint64_t set_status, uint64_t reset_status)
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
{
lv_manip: fix move_lv_segments moved bits For proper functionality of insert_layer_for_lv we need to move more bits to layerd LV. Add some missing new types and correct usage of caller, so the new LV type is set after the movement.
2023-07-10 16:43:49 +03:00
const uint64_t MOVE_BITS = (CACHE |
CACHE_POOL |
INTEGRITY |
LV_CACHE_VOL |
LV_VDO |
LV_VDO_POOL |
MIRROR |
RAID |
THIN_POOL |
THIN_VOLUME |
WRITECACHE);
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
struct lv_segment *seg;
Make move_lv_segment non-static This function could be useful for other _manip source files. Use dm_list manipulation function for provided functionality, which make the code more readable and avoid touching list internal details here.
2011-10-22 20:42:10 +04:00
dm_list_iterate_items(seg, &lv_to->segments)
more fixes
2007-12-21 02:12:27 +03:00
if (seg->origin) {
Make move_lv_segment non-static This function could be useful for other _manip source files. Use dm_list manipulation function for provided functionality, which make the code more readable and avoid touching list internal details here.
2011-10-22 20:42:10 +04:00
log_error("Can't move snapshot segment.");
more fixes
2007-12-21 02:12:27 +03:00
return 0;
}
Make move_lv_segment non-static This function could be useful for other _manip source files. Use dm_list manipulation function for provided functionality, which make the code more readable and avoid touching list internal details here.
2011-10-22 20:42:10 +04:00
dm_list_init(&lv_to->segments);
dm_list_splice(&lv_to->segments, &lv_from->segments);
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
dm_list_iterate_items(seg, &lv_to->segments) {
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
seg->lv = lv_to;
seg->status &= ~reset_status;
seg->status |= set_status;
}
lib: when moving segtypes, move LV bits When we insert layer we also move status flag-bits for certain LV types, so internal volume_group structure remains consistent. (Perhaps it's misuse of 'insert_layer' function and we should have another similar function for this.) Basically we aim to maintain the same state as after reading fresh metadata out of volume group. Currently we when i.e. cache 'raid' LV - this should transfer 'raidLV' flag to _corigin LV and cache is no longer a raid. TODO: bits for stacked devices needs more exact rules.
2015-09-10 16:08:29 +03:00
/*
* Move LV status bits for selected types with their segments
* i.e. when inserting layer to cache LV, we move raid segments
* to a new place, thus 'raid' LV property now belongs to this LV.
*
* Bits should match to those which appears after read from disk.
*/
lv_to->status |= lv_from->status & MOVE_BITS;
lv_from->status &= ~MOVE_BITS;
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
lv_to->le_count = lv_from->le_count;
lv_to->size = lv_from->size;
lv_from->le_count = 0;
lv_from->size = 0;
more fixes
2007-12-21 02:12:27 +03:00
return 1;
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
}
/* Remove a layer from the LV */
stacked mirror support (incomplete)
2007-12-20 21:55:46 +03:00
int remove_layer_from_lv(struct logical_volume *lv,
struct logical_volume *layer_lv)
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
{
writecache: fix splitcache when origin is raid
2020-02-05 01:05:56 +03:00
static const char _suffixes[][8] = { "_tdata", "_cdata", "_corig", "_wcorig", "_vdata" };
lv_manip: remove_layer_from_lv restore lv name Since we 'layer' for cache origin which and we support dropping cache layer - we need to restore origin name in case the origin LV is more complex target - i.e. raid. Drop _corig from name Cleanup and rename parent -> parent_lv.
2014-11-09 21:48:39 +03:00
struct logical_volume *parent_lv;
Maintain lists of stacked LV segments using each LV.
2008-01-16 22:00:59 +03:00
struct lv_segment *parent_seg;
stacked mirror support (incomplete)
2007-12-20 21:55:46 +03:00
struct segment_type *segtype;
lv_manip: remove_layer_from_lv restore lv name Since we 'layer' for cache origin which and we support dropping cache layer - we need to restore origin name in case the origin LV is more complex target - i.e. raid. Drop _corig from name Cleanup and rename parent -> parent_lv.
2014-11-09 21:48:39 +03:00
struct lv_names lv_names;
gcc: cleanup some sign warnings When comparing unsigned with int, the comparision is made as 'unsigned' type, so make it rather explicit which type is being compared.
2016-02-23 14:18:48 +03:00
unsigned r;
stacked mirror support (incomplete)
2007-12-20 21:55:46 +03:00
add lvconvert messages
2008-01-19 01:00:46 +03:00
log_very_verbose("Removing layer %s for %s", layer_lv->name, lv->name);
Maintain lists of stacked LV segments using each LV.
2008-01-16 22:00:59 +03:00
if (!(parent_seg = get_only_segment_using_this_lv(layer_lv))) {
stacked mirror support (incomplete)
2007-12-20 21:55:46 +03:00
log_error("Failed to find layer %s in %s",
debug: add internal error for passed LV TODO: in fact we should parameter LV.
2014-04-01 22:11:50 +04:00
layer_lv->name, lv->name);
stacked mirror support (incomplete)
2007-12-20 21:55:46 +03:00
return 0;
}
lv_manip: remove_layer_from_lv restore lv name Since we 'layer' for cache origin which and we support dropping cache layer - we need to restore origin name in case the origin LV is more complex target - i.e. raid. Drop _corig from name Cleanup and rename parent -> parent_lv.
2014-11-09 21:48:39 +03:00
parent_lv = parent_seg->lv;
if (parent_lv != lv) {
debug: add internal error for passed LV TODO: in fact we should parameter LV.
2014-04-01 22:11:50 +04:00
log_error(INTERNAL_ERROR "Wrong layer %s in %s",
layer_lv->name, lv->name);
return 0;
}
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
/*
* Before removal, the layer should be cleaned up,
* i.e. additional segments and areas should have been removed.
*/
mirror: relax internal error for a while With recent commit d6a74025df1afb3d76bec435bc6a40d649217b42 using INTERNAL_ERROR while cheking layer LV - it's been noticed mirror logic currently doesn't do a correct thing during upconversion and does a full-try instead of checking only allocator capabilities. This leads to invalid usage of layer. To keep existing code running before providing a fix, relax INTERNAL_ERROR just an error and keep the 'code' running. Once mirror code is fixed, these all check should be switched to internal errors.
2017-01-06 14:41:38 +03:00
/* FIXME:
* These are all INTERNAL_ERROR, but ATM there is
* some internal API problem and this code is wrongle
* executed with certain mirror manipulations.
* So we need to fix mirror code first, then switch...
*/
if (dm_list_size(&parent_lv->segments) != 1) {
log_error("Invalid %d segments in %s, expected only 1.",
dm_list_size(&parent_lv->segments),
display_lvname(parent_lv));
return 0;
}
if (parent_seg->area_count != 1) {
log_error("Invalid %d area count(s) in %s, expected only 1.",
parent_seg->area_count, display_lvname(parent_lv));
return 0;
}
if (seg_type(parent_seg, 0) != AREA_LV) {
log_error("Invalid seg_type %d in %s, expected LV.",
seg_type(parent_seg, 0), display_lvname(parent_lv));
return 0;
}
if (layer_lv != seg_lv(parent_seg, 0)) {
log_error("Layer doesn't match segment in %s.",
display_lvname(parent_lv));
return 0;
}
if (parent_lv->le_count != layer_lv->le_count) {
log_error("Inconsistent extent count (%u != %u) of layer %s.",
parent_lv->le_count, layer_lv->le_count,
display_lvname(parent_lv));
debug: show proper error message for layer mismatch Show proper internal error for failing command when there are some inconsitencies in sizes of LV and its layer instead of rather meaningless error code 5. (Could be hit i.e. if user tried to 'resize' cached LV and then uncache such LV.)
2017-01-05 17:49:07 +03:00
return 0;
}
stacked mirror support (incomplete)
2007-12-20 21:55:46 +03:00
lv_manip: remove_layer_from_lv restore lv name Since we 'layer' for cache origin which and we support dropping cache layer - we need to restore origin name in case the origin LV is more complex target - i.e. raid. Drop _corig from name Cleanup and rename parent -> parent_lv.
2014-11-09 21:48:39 +03:00
if (!lv_empty(parent_lv))
Add missing no-longer-used segs_using_this_lv test to check_lv_segments.
2008-02-22 16:22:21 +03:00
return_0;
lv_manip: remove_layer_from_lv restore lv name Since we 'layer' for cache origin which and we support dropping cache layer - we need to restore origin name in case the origin LV is more complex target - i.e. raid. Drop _corig from name Cleanup and rename parent -> parent_lv.
2014-11-09 21:48:39 +03:00
if (!move_lv_segments(parent_lv, layer_lv, 0, 0))
more fixes
2007-12-21 02:12:27 +03:00
return_0;
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
stacked mirror support (incomplete)
2007-12-20 21:55:46 +03:00
/* Replace the empty layer with error segment */
segtypes: Use SEG_TYPE_NAME_ string constants.
2015-09-22 21:04:12 +03:00
if (!(segtype = get_segtype_from_string(lv->vg->cmd, SEG_TYPE_NAME_ERROR)))
cleanup: indent Various indents and tiny error message improvements.
2014-10-18 13:01:29 +04:00
return_0;
lv_manip: remove_layer_from_lv restore lv name Since we 'layer' for cache origin which and we support dropping cache layer - we need to restore origin name in case the origin LV is more complex target - i.e. raid. Drop _corig from name Cleanup and rename parent -> parent_lv.
2014-11-09 21:48:39 +03:00
if (!lv_add_virtual_segment(layer_lv, 0, parent_lv->le_count, segtype))
stacked mirror support (incomplete)
2007-12-20 21:55:46 +03:00
return_0;
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
lv_manip: remove_layer_from_lv restore lv name Since we 'layer' for cache origin which and we support dropping cache layer - we need to restore origin name in case the origin LV is more complex target - i.e. raid. Drop _corig from name Cleanup and rename parent -> parent_lv.
2014-11-09 21:48:39 +03:00
/*
* recuresively rename sub LVs
* currently supported only for thin data layer
* FIXME: without strcmp it breaks mirrors....
*/
writecache: fix splitcache when origin is raid
2020-02-05 01:05:56 +03:00
if (!strstr(layer_lv->name, "_mimage")) {
for (r = 0; r < DM_ARRAY_SIZE(_suffixes); ++r) {
mirror: layer remove doesn't work properly with mirrors
2014-11-11 00:32:43 +03:00
if (strstr(layer_lv->name, _suffixes[r]) == 0) {
lv_names.old = layer_lv->name;
lv_names.new = parent_lv->name;
lv_manip: insert remove layer skips pools Fixing renaming of subLVs when removing and inserting layers - this got visible when using stacked VDO pools.
2019-01-24 16:14:31 +03:00
if (!for_each_sub_lv(parent_lv, _rename_skip_pools_externals_cb, (void *) &lv_names))
mirror: layer remove doesn't work properly with mirrors
2014-11-11 00:32:43 +03:00
return_0;
break;
}
writecache: fix splitcache when origin is raid
2020-02-05 01:05:56 +03:00
}
}
lv_manip: remove_layer_from_lv restore lv name Since we 'layer' for cache origin which and we support dropping cache layer - we need to restore origin name in case the origin LV is more complex target - i.e. raid. Drop _corig from name Cleanup and rename parent -> parent_lv.
2014-11-09 21:48:39 +03:00
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
return 1;
}
/*
* Create and insert a linear LV "above" lv_where.
* After the insertion, a new LV named lv_where->name + suffix is created
* and all segments of lv_where is moved to the new LV.
* lv_where will have a single segment which maps linearly to the new LV.
*/
struct logical_volume *insert_layer_for_lv(struct cmd_context *cmd,
struct logical_volume *lv_where,
Switch status from 32-bit to 64-bit The physical_volume, volume_group, logical_volume and lv_segment structures' 'status' member is now uint64_t. The alignment of these structures was also audited to remove holes. The movement of some members in 'volume_group' and 'lv_segment' eliminates holes. The 'physical_volume' structure still has one 4-byte hole after 'pe_size'; the other structures no longer have any holes. Each structures' size has not changed.
2009-11-25 01:55:55 +03:00
uint64_t status,
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
const char *layer_suffix)
{
lvconvert: support conversion to thin volume Update pool conversion function to handle also conversion of thick LV to thin LV by moving thick LV into thin pool data LV and creating fully provissioned thin LV on top of this volume. Reworking existing conversion to use insert_layer_for_lv co the uuid is now kept with thin-pool - this should however not really matter as we are doing full deactivation & activation cycle. With conversion to thin LV user can use same set of arguments to set chunk-size. TODO: add some smart code to decide best values for chunks sizes.
2023-07-04 22:34:47 +03:00
static const char _suffixes[][10] = { "_tdata", "_cdata", "_corig", "_wcorig", "_vdata", "_tpool%d" };
Fix to preserve exclusive activation of mirror while up-converting. When an LVM mirror is up-converted (an additional image added), it creates a temporary mirror stack. The lower-level mirror in the stack that is created was not being activated exclusively - violating the exclusive nature of the original mirror. We now check for exclusive activation of a mirror before converting it, and if found, we ensure that the temporary mirror is also exclusively activated.
2011-06-23 18:00:58 +04:00
int r;
cleanup: simplier lv name construction Using NAME_LEN max lv name size.
2014-10-24 16:22:13 +04:00
char name[NAME_LEN];
report: select: refactor: move str_list to libdm The list of strings is used quite frequently and we'd like to reuse this simple structure for report selection support too. Make it part of libdevmapper for general reuse throughout the code. This also simplifies the LVM code a bit since we don't need to include and manage lvm-types.h anymore (the string list was the only structure defined there).
2014-05-29 11:41:03 +04:00
struct dm_str_list *sl;
Fix up-convert when mirror activation is controled by volume_list and tags. When mirrors are up-converted, a transient mirror layer is put in so that only the new devices are sync'ed. That transient layer must carry the tags of the original mirror LV, otherwise it will fail to activate when activation is regulated by lvm.conf:activation/volume_list. The conversion would then fail. The fix is to do exactly the same thing that is being done for linear -> mirror converting (lib/metadata/mirror.c:_init_mirror_log()). We copy the tags temporarily for the new LV and remove them after the activation.
2012-05-05 06:08:46 +04:00
struct logical_volume *layer_lv;
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
struct segment_type *segtype;
struct lv_segment *mapseg;
liblvm: insert layer with subvolume renames Rename also subvolumes if we are inserting _tdata layer. (Currently it breaks mirrors if it would be generic, needs fixing).
2012-09-06 17:21:18 +04:00
struct lv_names lv_names;
Remove unused clvm variations for active LVs Different flavors of activate_lv() and lv_is_active() which are meaningful in a clustered VG can be eliminated and replaced with whatever that flavor already falls back to in a local VG. e.g. lv_is_active_exclusive_locally() is distinct from lv_is_active() in a clustered VG, but in a local VG they are equivalent. So, all instances of the variant are replaced with the basic local equivalent. For local VGs, the same behavior remains as before. For shared VGs, lvmlockd was written with the explicit requirement of local behavior from these functions (lvmlockd requires locking_type 1), so the behavior in shared VGs also remains the same.
2018-06-05 21:21:28 +03:00
unsigned i;
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
/* create an empty layer LV */
cleanup: simplier lv name construction Using NAME_LEN max lv name size.
2014-10-24 16:22:13 +04:00
if (dm_snprintf(name, sizeof(name), "%s%s", lv_where->name, layer_suffix) < 0) {
log_error("Layered name is too long. Please use shorter LV name.");
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
return NULL;
}
lv_manip: preserve read-only status in layered volume
2014-10-23 16:27:05 +04:00
if (!(layer_lv = lv_create_empty(name, NULL,
/* Preserve read-only flag */
LVM_READ | (lv_where->status & LVM_WRITE),
Remove unneeded import parameter from lv_create_empty.
2009-05-14 01:28:31 +04:00
ALLOC_INHERIT, lv_where->vg))) {
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
log_error("Creation of layer LV failed");
return NULL;
}
cleanup: use predefined macro for tmp image name
2016-11-23 12:39:59 +03:00
if (lv_is_active(lv_where) && strstr(name, MIRROR_SYNC_LAYER)) {
Fix temp table activation in mirror conversions not to happen in other cmds. Fix temp table in mirror conversions to use always-present error not zero.
2008-10-23 15:21:04 +04:00
log_very_verbose("Creating transient LV %s for mirror conversion in VG %s.", name, lv_where->vg->name);
Use temp table to set device size when converting mirrors. (Avoids having same mirror table loaded twice concurrently by first using a 'zero' table to set the size of the device so when mirror table is preloaded it doesn't have to be activated immediately.)
2008-10-17 14:57:15 +04:00
segtypes: Use SEG_TYPE_NAME_ string constants.
2015-09-22 21:04:12 +03:00
segtype = get_segtype_from_string(cmd, SEG_TYPE_NAME_ERROR);
Use temp table to set device size when converting mirrors. (Avoids having same mirror table loaded twice concurrently by first using a 'zero' table to set the size of the device so when mirror table is preloaded it doesn't have to be activated immediately.)
2008-10-17 14:57:15 +04:00
thin: simplify thin volume creation Move code for creation of thin volume into a single place out of lv_extend(). This allows to drop extra pool arg for alloc_lv_segment() && lv_extend() and makes code more easier to read and follow.
2014-10-26 10:13:59 +03:00
if (!lv_add_virtual_segment(layer_lv, 0, lv_where->le_count, segtype)) {
Fix temp table activation in mirror conversions not to happen in other cmds. Fix temp table in mirror conversions to use always-present error not zero.
2008-10-23 15:21:04 +04:00
log_error("Creation of transient LV %s for mirror conversion in VG %s failed.", name, lv_where->vg->name);
Use temp table to set device size when converting mirrors. (Avoids having same mirror table loaded twice concurrently by first using a 'zero' table to set the size of the device so when mirror table is preloaded it doesn't have to be activated immediately.)
2008-10-17 14:57:15 +04:00
return NULL;
}
Fix up-convert when mirror activation is controled by volume_list and tags. When mirrors are up-converted, a transient mirror layer is put in so that only the new devices are sync'ed. That transient layer must carry the tags of the original mirror LV, otherwise it will fail to activate when activation is regulated by lvm.conf:activation/volume_list. The conversion would then fail. The fix is to do exactly the same thing that is being done for linear -> mirror converting (lib/metadata/mirror.c:_init_mirror_log()). We copy the tags temporarily for the new LV and remove them after the activation.
2012-05-05 06:08:46 +04:00
/* Temporary tags for activation of the transient LV */
dm_list_iterate_items(sl, &lv_where->tags)
if (!str_list_add(cmd->mem, &layer_lv->tags, sl->str)) {
log_error("Aborting. Unable to tag"
" transient mirror layer.");
return NULL;
}
Use temp table to set device size when converting mirrors. (Avoids having same mirror table loaded twice concurrently by first using a 'zero' table to set the size of the device so when mirror table is preloaded it doesn't have to be activated immediately.)
2008-10-17 14:57:15 +04:00
if (!vg_write(lv_where->vg)) {
Fix temp table activation in mirror conversions not to happen in other cmds. Fix temp table in mirror conversions to use always-present error not zero.
2008-10-23 15:21:04 +04:00
log_error("Failed to write intermediate VG %s metadata for mirror conversion.", lv_where->vg->name);
Use temp table to set device size when converting mirrors. (Avoids having same mirror table loaded twice concurrently by first using a 'zero' table to set the size of the device so when mirror table is preloaded it doesn't have to be activated immediately.)
2008-10-17 14:57:15 +04:00
return NULL;
}
if (!vg_commit(lv_where->vg)) {
Fix temp table activation in mirror conversions not to happen in other cmds. Fix temp table in mirror conversions to use always-present error not zero.
2008-10-23 15:21:04 +04:00
log_error("Failed to commit intermediate VG %s metadata for mirror conversion.", lv_where->vg->name);
Use temp table to set device size when converting mirrors. (Avoids having same mirror table loaded twice concurrently by first using a 'zero' table to set the size of the device so when mirror table is preloaded it doesn't have to be activated immediately.)
2008-10-17 14:57:15 +04:00
return NULL;
}
Remove unused clvm variations for active LVs Different flavors of activate_lv() and lv_is_active() which are meaningful in a clustered VG can be eliminated and replaced with whatever that flavor already falls back to in a local VG. e.g. lv_is_active_exclusive_locally() is distinct from lv_is_active() in a clustered VG, but in a local VG they are equivalent. So, all instances of the variant are replaced with the basic local equivalent. For local VGs, the same behavior remains as before. For shared VGs, lvmlockd was written with the explicit requirement of local behavior from these functions (lvmlockd requires locking_type 1), so the behavior in shared VGs also remains the same.
2018-06-05 21:21:28 +03:00
r = activate_lv(cmd, layer_lv);
Fix to preserve exclusive activation of mirror while up-converting. When an LVM mirror is up-converted (an additional image added), it creates a temporary mirror stack. The lower-level mirror in the stack that is created was not being activated exclusively - violating the exclusive nature of the original mirror. We now check for exclusive activation of a mirror before converting it, and if found, we ensure that the temporary mirror is also exclusively activated.
2011-06-23 18:00:58 +04:00
if (!r) {
log_error("Failed to resume transient LV"
" %s for mirror conversion in VG %s.",
name, lv_where->vg->name);
Use temp table to set device size when converting mirrors. (Avoids having same mirror table loaded twice concurrently by first using a 'zero' table to set the size of the device so when mirror table is preloaded it doesn't have to be activated immediately.)
2008-10-17 14:57:15 +04:00
return NULL;
}
Fix up-convert when mirror activation is controled by volume_list and tags. When mirrors are up-converted, a transient mirror layer is put in so that only the new devices are sync'ed. That transient layer must carry the tags of the original mirror LV, otherwise it will fail to activate when activation is regulated by lvm.conf:activation/volume_list. The conversion would then fail. The fix is to do exactly the same thing that is being done for linear -> mirror converting (lib/metadata/mirror.c:_init_mirror_log()). We copy the tags temporarily for the new LV and remove them after the activation.
2012-05-05 06:08:46 +04:00
/* Remove the temporary tags */
dm_list_iterate_items(sl, &lv_where->tags)
str_list_del(&layer_lv->tags, sl->str);
Use temp table to set device size when converting mirrors. (Avoids having same mirror table loaded twice concurrently by first using a 'zero' table to set the size of the device so when mirror table is preloaded it doesn't have to be activated immediately.)
2008-10-17 14:57:15 +04:00
}
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
log_very_verbose("Inserting layer %s for %s",
layer_lv->name, lv_where->name);
Make move_lv_segment non-static This function could be useful for other _manip source files. Use dm_list manipulation function for provided functionality, which make the code more readable and avoid touching list internal details here.
2011-10-22 20:42:10 +04:00
if (!move_lv_segments(layer_lv, lv_where, 0, 0))
more fixes
2007-12-21 02:12:27 +03:00
return_NULL;
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
segtypes: Use SEG_TYPE_NAME_ string constants.
2015-09-22 21:04:12 +03:00
if (!(segtype = get_segtype_from_string(cmd, SEG_TYPE_NAME_STRIPED)))
Use temp table to set device size when converting mirrors. (Avoids having same mirror table loaded twice concurrently by first using a 'zero' table to set the size of the device so when mirror table is preloaded it doesn't have to be activated immediately.)
2008-10-17 14:57:15 +04:00
return_NULL;
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
/* allocate a new linear segment */
lvconvert: add infrastructure for RaidLV reshaping support In order to support striped raid5/6/10 LV reshaping (change of LV type, stripesize or number of legs), this patch introduces infrastructure prerequisites to be used by raid_manip.c extensions in followup patches. This base is needed for allocation of out-of-place reshape space required by the MD raid personalities to avoid writing over data in-place when reading off the current RAID layout or number of legs and writing out the new layout or to a different number of legs (i.e. restripe) Changes: - add members reshape_len to 'struct lv_segment' to store out-of-place reshape length per component rimage - add member data_copies to struct lv_segment to support more than 2 raid10 data copies - make alloc_lv_segment() aware of both reshape_len and data_copies - adjust all alloc_lv_segment() callers to the new API - add functions to retrieve the current data offset (needed for out-of-place reshaping space allocation) and the devices count from the kernel - make libdm deptree code aware of reshape_len - add LV flags for disk add/remove reshaping - support import/export of the new 'struct lv_segment' members - enhance lv_extend/_lv_reduce to cope with reshape_len - add seg_is_*/segtype_is_* macros related to reshaping - add target version check for reshaping - grow rebuilds/writemostly bitmaps to 246 bit to support kernel maximal - enhance libdm deptree code to support data_offset (out-of-place reshaping) and delta_disk (legs add/remove reshaping) target arguments Related: rhbz834579 Related: rhbz1191935 Related: rhbz1191978
2017-02-24 02:50:00 +03:00
if (!(mapseg = alloc_lv_segment(segtype, lv_where, 0, layer_lv->le_count, 0,
status, 0, NULL, 1, layer_lv->le_count, 0,
Fix pvmove allocation to take existing parallel stripes into account. When moving parts of striped LVs, pvmove wouldn't care about leaving you with two stripes on the same disk. Now --alloc anywhere is needed for that. (Tried and gave up on two alternative approaches before the one committed here.)
2010-04-08 04:28:57 +04:00
0, 0, 0, NULL)))
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
return_NULL;
/* map the new segment to the original underlying are */
Maintain lists of stacked LV segments using each LV.
2008-01-16 22:00:59 +03:00
if (!set_lv_segment_area_lv(mapseg, 0, layer_lv, 0, 0))
return_NULL;
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
/* add the new segment to the layer LV */
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
dm_list_add(&lv_where->segments, &mapseg->list);
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
lv_where->le_count = layer_lv->le_count;
Some more missing supposedly 64bit operations. Avoid use 32bit math for extent_size.
2012-03-05 19:05:24 +04:00
lv_where->size = (uint64_t) lv_where->le_count * lv_where->vg->extent_size;
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
lvconvert: vdo may convert already formated vdo User use 'lvconvert -Zn --type vdo-pool' to convert an existing vdo formated volume and skip lvm2 internal formating. This however requires user is passing proper matching parameters. For them user can use --profile|--metadataprofile option whos support has been also enhanced. TODO: add support to read values directly from formated volume.
2021-02-16 23:26:35 +03:00
if (lv_where->vg->fid->fmt->features & FMT_CONFIG_PROFILE)
lv_where->profile = lv_where->vg->cmd->profile_params->global_metadata_profile;
liblvm: insert layer with subvolume renames Rename also subvolumes if we are inserting _tdata layer. (Currently it breaks mirrors if it would be generic, needs fixing).
2012-09-06 17:21:18 +04:00
/*
* recuresively rename sub LVs
* currently supported only for thin data layer
* FIXME: without strcmp it breaks mirrors....
*/
gcc: cleanup some sign warnings When comparing unsigned with int, the comparision is made as 'unsigned' type, so make it rather explicit which type is being compared.
2016-02-23 14:18:48 +03:00
for (i = 0; i < DM_ARRAY_SIZE(_suffixes); ++i)
if (strcmp(layer_suffix, _suffixes[i]) == 0) {
cleanup: use insert_layer_for_lv implicit rename There is implicit rename for certain layered device. Do it now for _tdata, _cdata and _corig. TODO: use better API here...
2014-06-18 16:58:09 +04:00
lv_names.old = lv_where->name;
lv_names.new = layer_lv->name;
lv_manip: insert remove layer skips pools Fixing renaming of subLVs when removing and inserting layers - this got visible when using stacked VDO pools.
2019-01-24 16:14:31 +03:00
if (!for_each_sub_lv(layer_lv, _rename_skip_pools_externals_cb, (void *) &lv_names))
cleanup: indent Various indents and tiny error message improvements.
2014-10-18 13:01:29 +04:00
return_NULL;
cleanup: use insert_layer_for_lv implicit rename There is implicit rename for certain layered device. Do it now for _tdata, _cdata and _corig. TODO: use better API here...
2014-06-18 16:58:09 +04:00
break;
}
liblvm: insert layer with subvolume renames Rename also subvolumes if we are inserting _tdata layer. (Currently it breaks mirrors if it would be generic, needs fixing).
2012-09-06 17:21:18 +04:00
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
return layer_lv;
}
/*
* Extend and insert a linear layer LV beneath the source segment area.
*/
static int _extend_layer_lv_for_segment(struct logical_volume *layer_lv,
struct lv_segment *seg, uint32_t s,
Switch status from 32-bit to 64-bit The physical_volume, volume_group, logical_volume and lv_segment structures' 'status' member is now uint64_t. The alignment of these structures was also audited to remove holes. The movement of some members in 'volume_group' and 'lv_segment' eliminates holes. The 'physical_volume' structure still has one 4-byte hole after 'pe_size'; the other structures no longer have any holes. Each structures' size has not changed.
2009-11-25 01:55:55 +03:00
uint64_t status)
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
{
struct lv_segment *mapseg;
struct segment_type *segtype;
struct physical_volume *src_pv = seg_pv(seg, s);
uint32_t src_pe = seg_pe(seg, s);
if (seg_type(seg, s) != AREA_PV && seg_type(seg, s) != AREA_LV)
return_0;
segtypes: Use SEG_TYPE_NAME_ string constants.
2015-09-22 21:04:12 +03:00
if (!(segtype = get_segtype_from_string(layer_lv->vg->cmd, SEG_TYPE_NAME_STRIPED)))
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
return_0;
/* FIXME Incomplete message? Needs more context */
log_very_verbose("Inserting %s:%" PRIu32 "-%" PRIu32 " of %s/%s",
pv_dev_name(src_pv),
src_pe, src_pe + seg->area_len - 1,
seg->lv->vg->name, seg->lv->name);
/* allocate a new segment */
Always use vg memory pool for allocated lv segment Remove mem pool parameter from alloc_lv_segment() Since we should always allocate LV segment from the vg mempool.
2011-10-23 20:02:01 +04:00
if (!(mapseg = alloc_lv_segment(segtype, layer_lv, layer_lv->le_count,
lvconvert: add infrastructure for RaidLV reshaping support In order to support striped raid5/6/10 LV reshaping (change of LV type, stripesize or number of legs), this patch introduces infrastructure prerequisites to be used by raid_manip.c extensions in followup patches. This base is needed for allocation of out-of-place reshape space required by the MD raid personalities to avoid writing over data in-place when reading off the current RAID layout or number of legs and writing out the new layout or to a different number of legs (i.e. restripe) Changes: - add members reshape_len to 'struct lv_segment' to store out-of-place reshape length per component rimage - add member data_copies to struct lv_segment to support more than 2 raid10 data copies - make alloc_lv_segment() aware of both reshape_len and data_copies - adjust all alloc_lv_segment() callers to the new API - add functions to retrieve the current data offset (needed for out-of-place reshaping space allocation) and the devices count from the kernel - make libdm deptree code aware of reshape_len - add LV flags for disk add/remove reshaping - support import/export of the new 'struct lv_segment' members - enhance lv_extend/_lv_reduce to cope with reshape_len - add seg_is_*/segtype_is_* macros related to reshaping - add target version check for reshaping - grow rebuilds/writemostly bitmaps to 246 bit to support kernel maximal - enhance libdm deptree code to support data_offset (out-of-place reshaping) and delta_disk (legs add/remove reshaping) target arguments Related: rhbz834579 Related: rhbz1191935 Related: rhbz1191978
2017-02-24 02:50:00 +03:00
seg->area_len, 0, status, 0,
NULL, 1, seg->area_len, 0, 0, 0, 0, seg)))
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
return_0;
/* map the new segment to the original underlying are */
if (!move_lv_segment_area(mapseg, 0, seg, s))
return_0;
/* add the new segment to the layer LV */
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
dm_list_add(&layer_lv->segments, &mapseg->list);
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
layer_lv->le_count += seg->area_len;
Some more missing supposedly 64bit operations. Avoid use 32bit math for extent_size.
2012-03-05 19:05:24 +04:00
layer_lv->size += (uint64_t) seg->area_len * layer_lv->vg->extent_size;
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
/* map the original area to the new segment */
Maintain lists of stacked LV segments using each LV.
2008-01-16 22:00:59 +03:00
if (!set_lv_segment_area_lv(seg, s, layer_lv, mapseg->le, 0))
return_0;
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
return 1;
}
/*
* Match the segment area to PEs in the pvl
* (the segment area boundary should be aligned to PE ranges by
* _adjust_layer_segments() so that there is no partial overlap.)
*/
static int _match_seg_area_to_pe_range(struct lv_segment *seg, uint32_t s,
struct pv_list *pvl)
{
struct pe_range *per;
uint32_t pe_start, per_end;
if (!pvl)
return 1;
if (seg_type(seg, s) != AREA_PV || seg_dev(seg, s) != pvl->pv->dev)
return 0;
pe_start = seg_pe(seg, s);
/* Do these PEs match to any of the PEs in pvl? */
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
dm_list_iterate_items(per, pvl->pe_ranges) {
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
per_end = per->start + per->count - 1;
if ((pe_start < per->start) || (pe_start > per_end))
continue;
/* FIXME Missing context in this message - add LV/seg details */
logging: classify log_debug messages Place most log_debug() messages into a class.
2013-01-08 02:30:29 +04:00
log_debug_alloc("Matched PE range %s:%" PRIu32 "-%" PRIu32 " against "
"%s %" PRIu32 " len %" PRIu32, dev_name(pvl->pv->dev),
per->start, per_end, dev_name(seg_dev(seg, s)),
seg_pe(seg, s), seg->area_len);
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
return 1;
}
return 0;
}
/*
* For each segment in lv_where that uses a PV in pvl directly,
* split the segment if it spans more than one underlying PV.
*/
static int _align_segment_boundary_to_pe_range(struct logical_volume *lv_where,
struct pv_list *pvl)
{
struct lv_segment *seg;
struct pe_range *per;
uint32_t pe_start, pe_end, per_end, stripe_multiplier, s;
if (!pvl)
return 1;
/* Split LV segments to match PE ranges */
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
dm_list_iterate_items(seg, &lv_where->segments) {
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
for (s = 0; s < seg->area_count; s++) {
if (seg_type(seg, s) != AREA_PV ||
seg_dev(seg, s) != pvl->pv->dev)
continue;
/* Do these PEs match with the condition? */
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
dm_list_iterate_items(per, pvl->pe_ranges) {
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
pe_start = seg_pe(seg, s);
pe_end = pe_start + seg->area_len - 1;
per_end = per->start + per->count - 1;
/* No overlap? */
if ((pe_end < per->start) ||
(pe_start > per_end))
continue;
if (seg_is_striped(seg))
stripe_multiplier = seg->area_count;
else
stripe_multiplier = 1;
if ((per->start != pe_start &&
per->start > pe_start) &&
!lv_split_segment(lv_where, seg->le +
(per->start - pe_start) *
stripe_multiplier))
return_0;
if ((per_end != pe_end &&
per_end < pe_end) &&
!lv_split_segment(lv_where, seg->le +
(per_end - pe_start + 1) *
stripe_multiplier))
return_0;
}
}
}
return 1;
}
/*
* Scan lv_where for segments on a PV in pvl, and for each one found
* append a linear segment to lv_layer and insert it between the two.
*
* If pvl is empty, a layer is placed under the whole of lv_where.
* If the layer is inserted, lv_where is added to lvs_changed.
*/
int insert_layer_for_segments_on_pv(struct cmd_context *cmd,
struct logical_volume *lv_where,
struct logical_volume *layer_lv,
Switch status from 32-bit to 64-bit The physical_volume, volume_group, logical_volume and lv_segment structures' 'status' member is now uint64_t. The alignment of these structures was also audited to remove holes. The movement of some members in 'volume_group' and 'lv_segment' eliminates holes. The 'physical_volume' structure still has one 4-byte hole after 'pe_size'; the other structures no longer have any holes. Each structures' size has not changed.
2009-11-25 01:55:55 +03:00
uint64_t status,
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
struct pv_list *pvl,
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
struct dm_list *lvs_changed)
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
{
struct lv_segment *seg;
struct lv_list *lvl;
int lv_used = 0;
uint32_t s;
layers: collect only lock holding LVs
2017-11-09 13:41:16 +03:00
struct logical_volume *holder = (struct logical_volume *) lv_lock_holder(lv_where);
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
add lvconvert messages
2008-01-19 01:00:46 +03:00
log_very_verbose("Inserting layer %s for segments of %s on %s",
layer_lv->name, lv_where->name,
pvl ? pv_dev_name(pvl->pv) : "any");
lv_manip: hide layered LV temporarily Since vg_validate() now rejects LVs without segments and insert_layer_for_segments_on_pv() gets just created 'layer_lv' without segment, it needs to be hidden from vg->lvs during processing of _align_segment_boundary_to_pe_range() as this function calls lv_validate() and now requires vg to be consistent. LV is then put back into vg->lvs.
2017-11-01 02:51:39 +03:00
/* Temporarily hide layer_lv from vg->lvs list
* so the lv_split_segment() passes vg_validate()
* since here layer_lv has empty segment list */
if (!(lvl = find_lv_in_vg(lv_where->vg, layer_lv->name)))
return_0;
dm_list_del(&lvl->list);
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
if (!_align_segment_boundary_to_pe_range(lv_where, pvl))
return_0;
lv_manip: hide layered LV temporarily Since vg_validate() now rejects LVs without segments and insert_layer_for_segments_on_pv() gets just created 'layer_lv' without segment, it needs to be hidden from vg->lvs during processing of _align_segment_boundary_to_pe_range() as this function calls lv_validate() and now requires vg to be consistent. LV is then put back into vg->lvs.
2017-11-01 02:51:39 +03:00
/* Put back layer_lv in vg->lv */
dm_list_add(&lv_where->vg->lvs, &lvl->list);
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
/* Work through all segments on the supplied PV */
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
dm_list_iterate_items(seg, &lv_where->segments) {
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
for (s = 0; s < seg->area_count; s++) {
if (!_match_seg_area_to_pe_range(seg, s, pvl))
continue;
/* First time, add LV to list of LVs affected */
if (!lv_used && lvs_changed) {
layers: collect only lock holding LVs
2017-11-09 13:41:16 +03:00
/* First check if LV is listed already */
dm_list_iterate_items(lvl, lvs_changed)
if (lvl->lv == holder) {
lv_used = 1;
break;
}
if (!lv_used) {
if (!(lvl = dm_pool_alloc(cmd->mem, sizeof(*lvl)))) {
log_error("lv_list alloc failed.");
return 0;
}
lvl->lv = holder;
dm_list_add(lvs_changed, &lvl->list);
lv_used = 1;
Major restructuring of pvmove and lvconvert layer manipulation code
2007-12-20 18:42:55 +03:00
}
}
if (!_extend_layer_lv_for_segment(layer_lv, seg, s,
status)) {
log_error("Failed to insert segment in layer "
"LV %s under %s:%" PRIu32 "-%" PRIu32,
layer_lv->name, lv_where->name,
seg->le, seg->le + seg->len);
return 0;
}
}
}
return 1;
}
various cleanups in recent patches
2007-12-21 01:37:42 +03:00
/*
* Initialize the LV with 'value'.
*/
cleanup: use compound literals for wipe_lv Optimize and cleanup recently introduced new function wipe_lv. Use compound literals to get nicely initialized wipe_params struct. Pass in lv as explicit argument for wipe_lv. Use cmd from lv structure. Initialize only non-null members so it's easy to see what is the special arg.
2013-11-28 14:22:24 +04:00
int wipe_lv(struct logical_volume *lv, struct wipe_params wp)
various cleanups in recent patches
2007-12-21 01:37:42 +03:00
{
struct device *dev;
cleanup: use compound literals for wipe_lv Optimize and cleanup recently introduced new function wipe_lv. Use compound literals to get nicely initialized wipe_params struct. Pass in lv as explicit argument for wipe_lv. Use cmd from lv structure. Initialize only non-null members so it's easy to see what is the special arg.
2013-11-28 14:22:24 +04:00
char name[PATH_MAX];
lv_manip: rename set_lv -> wipe_lv and include signature wiping capability Use common wipe_lv (former set_lv) fn to do zeroing as well as signature wiping if needed. Provide new struct wipe_lv_params to define the functionality. Bind "lvcreate -W/--wipesignatures y" with proper wipe_lv call. Also, add "yes" and "force" to lvcreate_params so it's possible to apply them for the prompt: "WARNING: %s detected on %s. Wipe it? [y/n]".
2013-11-06 19:16:34 +04:00
uint64_t zero_sectors;
cov: avoid duplicated assign
2020-08-29 21:40:20 +03:00
int zero_metadata;
various cleanups in recent patches
2007-12-21 01:37:42 +03:00
pool: zero metadata To avoid polution of metadata with some 'garbage' content or eventualy some leak of stale data in case user want to upload metadata somewhere, ensure upon allocation the metadata device is fully zeroed. Behaviour may slow down allocation of thin-pool or cache-pool a bit so the old behaviour can be restored with lvm.conf setting: allocation/zero_metadata=0 TODO: add zeroing for extension of metadata volume.
2020-06-24 13:11:21 +03:00
if (!wp.do_zero && !wp.do_wipe_signatures && !wp.is_metadata)
lv_manip: rename set_lv -> wipe_lv and include signature wiping capability Use common wipe_lv (former set_lv) fn to do zeroing as well as signature wiping if needed. Provide new struct wipe_lv_params to define the functionality. Bind "lvcreate -W/--wipesignatures y" with proper wipe_lv call. Also, add "yes" and "force" to lvcreate_params so it's possible to apply them for the prompt: "WARNING: %s detected on %s. Wipe it? [y/n]".
2013-11-06 19:16:34 +04:00
/* nothing to do */
return 1;
Remove unused clvm variations for active LVs Different flavors of activate_lv() and lv_is_active() which are meaningful in a clustered VG can be eliminated and replaced with whatever that flavor already falls back to in a local VG. e.g. lv_is_active_exclusive_locally() is distinct from lv_is_active() in a clustered VG, but in a local VG they are equivalent. So, all instances of the variant are replaced with the basic local equivalent. For local VGs, the same behavior remains as before. For shared VGs, lvmlockd was written with the explicit requirement of local behavior from these functions (lvmlockd requires locking_type 1), so the behavior in shared VGs also remains the same.
2018-06-05 21:21:28 +03:00
if (!lv_is_active(lv)) {
wipe_lv: make error a fatal event Failure in wiping/zeroing stop the command. If user wants to avoid command abortion he should use -Zn or -Wn to avoid wiping. Note: there is no easy way to distinguish which kind of failure has happend - so it's safe to not proceed any futher.
2020-06-23 14:56:15 +03:00
log_error("Volume %s is not active locally (volume_list activation filter?).",
display_lvname(lv));
cleanup: reorder condition There is no point to wait for sync for non-locally active LV.
2018-03-29 23:53:13 +03:00
return 0;
}
locking: Add missing error handling. Add missing error logging and detection to unlock_vg and callers of sync_local_dev_names etc.
2015-06-30 20:54:38 +03:00
/* Wait until devices are available */
if (!sync_local_dev_names(lv->vg->cmd)) {
wipe_lv: make error a fatal event Failure in wiping/zeroing stop the command. If user wants to avoid command abortion he should use -Zn or -Wn to avoid wiping. Note: there is no easy way to distinguish which kind of failure has happend - so it's safe to not proceed any futher.
2020-06-23 14:56:15 +03:00
log_error("Failed to sync local devices before wiping volume %s.",
locking: Add missing error handling. Add missing error logging and detection to unlock_vg and callers of sync_local_dev_names etc.
2015-06-30 20:54:38 +03:00
display_lvname(lv));
return 0;
}
wipe_lv: move sync_local_dev_names in front Synchronize things before checking for locally active volume.
2014-09-19 13:06:31 +04:00
various cleanups in recent patches
2007-12-21 01:37:42 +03:00
/*
* FIXME:
* <clausen> also, more than 4k
* <clausen> say, reiserfs puts it's superblock 32k in, IIRC
* <ejt_> k, I'll drop a fixme to that effect
* (I know the device is at least 4k, but not 32k)
*/
cleanup: use compound literals for wipe_lv Optimize and cleanup recently introduced new function wipe_lv. Use compound literals to get nicely initialized wipe_params struct. Pass in lv as explicit argument for wipe_lv. Use cmd from lv structure. Initialize only non-null members so it's easy to see what is the special arg.
2013-11-28 14:22:24 +04:00
if (dm_snprintf(name, sizeof(name), "%s%s/%s", lv->vg->cmd->dev_dir,
lv->vg->name, lv->name) < 0) {
log_error("Name too long - device not cleared (%s)", lv->name);
various cleanups in recent patches
2007-12-21 01:37:42 +03:00
return 0;
}
Add cmd arg to more functions so that it can be used in the filter code
2018-06-15 19:03:55 +03:00
if (!(dev = dev_cache_get(lv->vg->cmd, name, NULL))) {
various cleanups in recent patches
2007-12-21 01:37:42 +03:00
log_error("%s: not found: device not cleared", name);
return 0;
}
wipe_lv: initially open LV in writable mode wipe_lv knows it's going to write the device, so it can open rw from the start. It was opening readonly, and then dev_write needed to reopen it readwrite.
2019-04-26 22:49:27 +03:00
if (!label_scan_open_rw(dev)) {
wipe_lv: make error a fatal event Failure in wiping/zeroing stop the command. If user wants to avoid command abortion he should use -Zn or -Wn to avoid wiping. Note: there is no easy way to distinguish which kind of failure has happend - so it's safe to not proceed any futher.
2020-06-23 14:56:15 +03:00
log_error("Failed to open %s for wiping and zeroing.", display_lvname(lv));
return 0;
io: replace dev_set with bcache equivalents
2018-05-09 18:34:28 +03:00
}
various cleanups in recent patches
2007-12-21 01:37:42 +03:00
wipe_lv: interruptible wiping Since we now block signals and wiping may take unexpectedly long time - support breaking command while wipe is in progress.
2020-10-02 20:31:05 +03:00
sigint_allow();
cleanup: use compound literals for wipe_lv Optimize and cleanup recently introduced new function wipe_lv. Use compound literals to get nicely initialized wipe_params struct. Pass in lv as explicit argument for wipe_lv. Use cmd from lv structure. Initialize only non-null members so it's easy to see what is the special arg.
2013-11-28 14:22:24 +04:00
if (wp.do_wipe_signatures) {
wipe_lv: make error a fatal event Failure in wiping/zeroing stop the command. If user wants to avoid command abortion he should use -Zn or -Wn to avoid wiping. Note: there is no easy way to distinguish which kind of failure has happend - so it's safe to not proceed any futher.
2020-06-23 14:56:15 +03:00
log_verbose("Wiping known signatures on logical volume %s.",
display_lvname(lv));
wiping: wipe DM_snapshot_cow signature without prompt in newly created LVs The libblkid can detect DM_snapshot_cow signature and when creating new LVs with blkid wiping used (allocation/use_blkid_wiping=1 lvm.conf setting and --wipe y used at the same time - which it is by default). Do not issue any prompts about this signature when new LV is created and just wipe it right away without asking questions. Still keep the log in verbose mode though.
2014-02-10 16:28:13 +04:00
if (!wipe_known_signatures(lv->vg->cmd, dev, name, 0,
TYPE_DM_SNAPSHOT_COW,
wipe_lv: make error a fatal event Failure in wiping/zeroing stop the command. If user wants to avoid command abortion he should use -Zn or -Wn to avoid wiping. Note: there is no easy way to distinguish which kind of failure has happend - so it's safe to not proceed any futher.
2020-06-23 14:56:15 +03:00
wp.yes, wp.force, NULL)) {
wipe_lv: interruptible wiping Since we now block signals and wiping may take unexpectedly long time - support breaking command while wipe is in progress.
2020-10-02 20:31:05 +03:00
sigint_restore();
wipe_lv: close devices on error path Device was kept open preventing its deactivated and removed on error path.
2020-08-19 15:40:08 +03:00
label_scan_invalidate(dev);
debug: shorten error message Just check for sigint during log_error().
2020-10-19 15:28:58 +03:00
log_error("%s logical volume %s.",
sigint_caught() ?
"Interrupted initialization of" : "Failed to wipe signatures on",
wipe_lv: make error a fatal event Failure in wiping/zeroing stop the command. If user wants to avoid command abortion he should use -Zn or -Wn to avoid wiping. Note: there is no easy way to distinguish which kind of failure has happend - so it's safe to not proceed any futher.
2020-06-23 14:56:15 +03:00
display_lvname(lv));
return 0;
}
lv_manip: rename set_lv -> wipe_lv and include signature wiping capability Use common wipe_lv (former set_lv) fn to do zeroing as well as signature wiping if needed. Provide new struct wipe_lv_params to define the functionality. Bind "lvcreate -W/--wipesignatures y" with proper wipe_lv call. Also, add "yes" and "force" to lvcreate_params so it's possible to apply them for the prompt: "WARNING: %s detected on %s. Wipe it? [y/n]".
2013-11-06 19:16:34 +04:00
}
Do not issue write behind lv size. pvcreate $DEV vgcreate -s 1k vg_test $DEV lvcreate -l 1 -n lv1 vg_test .. /dev/vg_test/lv1: write failed after 1024 of 4096 at 0: No space left on device Just check for maximum write size in set_lv.
2008-12-19 18:26:01 +03:00
pool: zero metadata To avoid polution of metadata with some 'garbage' content or eventualy some leak of stale data in case user want to upload metadata somewhere, ensure upon allocation the metadata device is fully zeroed. Behaviour may slow down allocation of thin-pool or cache-pool a bit so the old behaviour can be restored with lvm.conf setting: allocation/zero_metadata=0 TODO: add zeroing for extension of metadata volume.
2020-06-24 13:11:21 +03:00
if (wp.do_zero || wp.is_metadata) {
zero_metadata = !wp.is_metadata ? 0 :
find_config_tree_bool(lv->vg->cmd, allocation_zero_metadata_CFG, NULL);
if (zero_metadata) {
log_debug("Metadata logical volume %s will be fully zeroed.",
display_lvname(lv));
cleanup: use compound literals for wipe_lv Optimize and cleanup recently introduced new function wipe_lv. Use compound literals to get nicely initialized wipe_params struct. Pass in lv as explicit argument for wipe_lv. Use cmd from lv structure. Initialize only non-null members so it's easy to see what is the special arg.
2013-11-28 14:22:24 +04:00
zero_sectors = lv->size;
wipe: dev_set_bytes resolves zeroing Since dev_write_zeros() is just subset of dev_set_bytes() use it directly and simplify code.
2020-09-15 21:35:48 +03:00
wp.zero_value = 0;
pool: zero metadata To avoid polution of metadata with some 'garbage' content or eventualy some leak of stale data in case user want to upload metadata somewhere, ensure upon allocation the metadata device is fully zeroed. Behaviour may slow down allocation of thin-pool or cache-pool a bit so the old behaviour can be restored with lvm.conf setting: allocation/zero_metadata=0 TODO: add zeroing for extension of metadata volume.
2020-06-24 13:11:21 +03:00
} else {
if (wp.is_metadata) /* Verbosely notify metadata will not be fully zeroed */
log_verbose("Metadata logical volume %s not fully zeroed and may contain stale data.",
display_lvname(lv));
wipe_lv: always zero at least 4K When zero_sectors passed value like 1 - we could zero only 1 sector. Reinstantiate we always zero at least 4K block.
2020-07-08 11:38:36 +03:00
zero_sectors = UINT64_C(4096) >> SECTOR_SHIFT;
if (wp.zero_sectors > zero_sectors)
zero_sectors = wp.zero_sectors;
pool: zero metadata To avoid polution of metadata with some 'garbage' content or eventualy some leak of stale data in case user want to upload metadata somewhere, ensure upon allocation the metadata device is fully zeroed. Behaviour may slow down allocation of thin-pool or cache-pool a bit so the old behaviour can be restored with lvm.conf setting: allocation/zero_metadata=0 TODO: add zeroing for extension of metadata volume.
2020-06-24 13:11:21 +03:00
if (zero_sectors > lv->size)
zero_sectors = lv->size;
}
lv_manip: rename set_lv -> wipe_lv and include signature wiping capability Use common wipe_lv (former set_lv) fn to do zeroing as well as signature wiping if needed. Provide new struct wipe_lv_params to define the functionality. Bind "lvcreate -W/--wipesignatures y" with proper wipe_lv call. Also, add "yes" and "force" to lvcreate_params so it's possible to apply them for the prompt: "WARNING: %s detected on %s. Wipe it? [y/n]".
2013-11-06 19:16:34 +04:00
wipe_lv: make error a fatal event Failure in wiping/zeroing stop the command. If user wants to avoid command abortion he should use -Zn or -Wn to avoid wiping. Note: there is no easy way to distinguish which kind of failure has happend - so it's safe to not proceed any futher.
2020-06-23 14:56:15 +03:00
log_verbose("Initializing %s of logical volume %s with value %d.",
cleanup: update clearing message Since some targets are using this routine to setup other values then 0 and also may clear much more data then just disk header - add better message.
2014-02-11 16:30:41 +04:00
display_size(lv->vg->cmd, zero_sectors),
wipe_lv: make error a fatal event Failure in wiping/zeroing stop the command. If user wants to avoid command abortion he should use -Zn or -Wn to avoid wiping. Note: there is no easy way to distinguish which kind of failure has happend - so it's safe to not proceed any futher.
2020-06-23 14:56:15 +03:00
display_lvname(lv), wp.zero_value);
wipe_lv: use BLKZEROOUT when possible Since BLKZEROOUT ioctl should be supposedly fastest way how to clear block device start using this ioctl for zeroing a device. Commonly we do zero typically small portion of a device (8KiB) - however since we now also started to zero metadata devices, in the case of i.e. thin-pool metadata this can go upto ~16GiB and here the performance starts to be noticable.
2020-10-02 20:32:28 +03:00
#ifdef HAVE_BLKZEROOUT
wipe_lv: use zeroing ioctl only for large sizes There is no easy way to detect, whether device supports zeroing, and kernel also zeroes device when it's not directly supported, but with extra message: operation not supported error, dev X, sector Y op 0x9:(WRITE_ZEROES)... So to avoid generating such message with every 'lvcreate', use for zeroing of upto 8K just standard write of zeroed page. (maybe we can go with even larger sizes).
2023-04-25 00:58:21 +03:00
if (!test_mode() && !wp.zero_value && (zero_sectors > 16)) {
wipe_lv: use BLKZEROOUT when possible Since BLKZEROOUT ioctl should be supposedly fastest way how to clear block device start using this ioctl for zeroing a device. Commonly we do zero typically small portion of a device (8KiB) - however since we now also started to zero metadata devices, in the case of i.e. thin-pool metadata this can go upto ~16GiB and here the performance starts to be noticable.
2020-10-02 20:32:28 +03:00
/* TODO: maybe integrate with bcache_zero_set() */
const uint64_t end = zero_sectors << SECTOR_SHIFT;
uint64_t range[2] = { 0, 1024 * 1024 }; /* zeroing with 1M steps (for better ^C support) */
for (/* empty */ ; range[0] < end; range[0] += range[1]) {
if ((range[0] + range[1]) > end)
range[1] = end - range[0];
if (ioctl(dev->bcache_fd, BLKZEROOUT, &range)) {
if (errno == EINVAL)
goto retry_with_dev_set; /* Kernel without support for BLKZEROOUT */
log_sys_debug("ioctl", "BLKZEROOUT");
sigint_restore();
label_scan_invalidate(dev);
debug: shorten error message Just check for sigint during log_error().
2020-10-19 15:28:58 +03:00
log_error("%s logical volume %s at position " FMTu64 " and size " FMTu64 ".",
sigint_caught() ? "Interrupted initialization of" : "Failed to initialize",
display_lvname(lv), range[0], range[1]);
wipe_lv: use BLKZEROOUT when possible Since BLKZEROOUT ioctl should be supposedly fastest way how to clear block device start using this ioctl for zeroing a device. Commonly we do zero typically small portion of a device (8KiB) - however since we now also started to zero metadata devices, in the case of i.e. thin-pool metadata this can go upto ~16GiB and here the performance starts to be noticable.
2020-10-02 20:32:28 +03:00
return 0;
}
}
} else
retry_with_dev_set:
#endif
wipe: dev_set_bytes resolves zeroing Since dev_write_zeros() is just subset of dev_set_bytes() use it directly and simplify code.
2020-09-15 21:35:48 +03:00
if (!dev_set_bytes(dev, UINT64_C(0), (size_t) zero_sectors << SECTOR_SHIFT, wp.zero_value)) {
wipe_lv: interruptible wiping Since we now block signals and wiping may take unexpectedly long time - support breaking command while wipe is in progress.
2020-10-02 20:31:05 +03:00
sigint_restore();
wipe: reformat message for failure case Use the same error message layout to match BLKZEROUT look. Makes testing easier.
2021-01-22 21:21:55 +03:00
log_error("%s logical volume %s with value %d and size %s.",
debug: shorten error message Just check for sigint during log_error().
2020-10-19 15:28:58 +03:00
sigint_caught() ? "Interrupted initialization" : "Failed to initialize",
wipe: reformat message for failure case Use the same error message layout to match BLKZEROUT look. Makes testing easier.
2021-01-22 21:21:55 +03:00
display_lvname(lv), wp.zero_value,
display_size(lv->vg->cmd, zero_sectors));
wipe_lv: make error a fatal event Failure in wiping/zeroing stop the command. If user wants to avoid command abortion he should use -Zn or -Wn to avoid wiping. Note: there is no easy way to distinguish which kind of failure has happend - so it's safe to not proceed any futher.
2020-06-23 14:56:15 +03:00
return 0;
io: replace dev_set with bcache equivalents
2018-05-09 18:34:28 +03:00
}
lv_manip: rename set_lv -> wipe_lv and include signature wiping capability Use common wipe_lv (former set_lv) fn to do zeroing as well as signature wiping if needed. Provide new struct wipe_lv_params to define the functionality. Bind "lvcreate -W/--wipesignatures y" with proper wipe_lv call. Also, add "yes" and "force" to lvcreate_params so it's possible to apply them for the prompt: "WARNING: %s detected on %s. Wipe it? [y/n]".
2013-11-06 19:16:34 +04:00
}
wipe_lv: interruptible wiping Since we now block signals and wiping may take unexpectedly long time - support breaking command while wipe is in progress.
2020-10-02 20:31:05 +03:00
sigint_restore();
Add backtraces for errors Add stack; backtraces when error is reported from dev_set() or dev_close_immediate().
2010-12-01 15:56:39 +03:00
io: replace dev_set with bcache equivalents
2018-05-09 18:34:28 +03:00
label_scan_invalidate(dev);
wipe_lv: make error a fatal event Failure in wiping/zeroing stop the command. If user wants to avoid command abortion he should use -Zn or -Wn to avoid wiping. Note: there is no easy way to distinguish which kind of failure has happend - so it's safe to not proceed any futher.
2020-06-23 14:56:15 +03:00
cleanup: use compound literals for wipe_lv Optimize and cleanup recently introduced new function wipe_lv. Use compound literals to get nicely initialized wipe_params struct. Pass in lv as explicit argument for wipe_lv. Use cmd from lv structure. Initialize only non-null members so it's easy to see what is the special arg.
2013-11-28 14:22:24 +04:00
lv->status &= ~LV_NOSCAN;
activation: add support for flagging an LV to skip udev scanning during activation A common scenario is during new LV creation when we need to wipe the newly created LV and avoid any udev scanning before this stage otherwise it could cause the device (the LV) to be claimed by some other subsystem for which there were stale metadata within LV data. This patch adds possibility to mark the LV we're just about to wipe with a flag that gets passed to udev via DM_COOKIE as a subsystem specific flag - DM_SUBSYSTEM_UDEV_FLAG0 (in this case the subsystem is "LVM") so LVM udev rules will take care of handling that.
2013-10-08 15:27:21 +04:00
various cleanups in recent patches
2007-12-21 01:37:42 +03:00
return 1;
}
Move _lvcreate into the internal library and rename to lv_create_single. After some refactorings, we can now move the bulk of _lvcreate into the internal library, and we can call from liblvm. In the future, we should refactor lv_create_single further, probably by segtype, to reduce the size of struct lvcreate_params. For now this is a reasonable refactor and allows us to re-use the function from liblvm. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-07-26 06:33:35 +04:00
raid: fix (de)activation of RaidLVs with visible SubLVs There's a small window during creation of a new RaidLV when rmeta SubLVs are made visible to wipe them in order to prevent erroneous discovery of stale RAID metadata. In case a crash prevents the SubLVs from being committed hidden after such wiping, the RaidLV can still be activated with the SubLVs visible. During deactivation though, a deadlock occurs because the visible SubLVs are deactivated before the RaidLV. The patch adds _check_raid_sublvs to the raid validation in merge.c, an activation check to activate.c (paranoid, because the merge.c check will prevent activation in case of visible SubLVs) and shares the existing wiping function _clear_lvs in raid_manip.c moved to lv_manip.c and renamed to activate_and_wipe_lvlist to remove code duplication. Whilst on it, introduce activate_and_wipe_lv to share with (lvconvert|lvchange).c. Resolves: rhbz1633167
2018-11-01 01:05:08 +03:00
/*
* Optionally makes on-disk metadata changes if @commit
*
* If LV is active:
* wipe any signatures and clear first sector of LVs listed on @lv_list
* otherwise:
* activate, wipe (as above), deactivate
*
* Returns: 1 on success, 0 on failure
*/
int activate_and_wipe_lvlist(struct dm_list *lv_list, int commit)
{
struct lv_list *lvl;
struct volume_group *vg = NULL;
unsigned i = 0, sz = dm_list_size(lv_list);
char *was_active;
int r = 1;
if (!sz) {
log_debug_metadata(INTERNAL_ERROR "Empty list of LVs given for wiping.");
return 1;
}
dm_list_iterate_items(lvl, lv_list) {
if (!lv_is_visible(lvl->lv)) {
log_error(INTERNAL_ERROR
"LVs must be set visible before wiping.");
return 0;
}
vg = lvl->lv->vg;
}
if (test_mode())
return 1;
/*
* FIXME: only vg_[write|commit] if LVs are not already written
* as visible in the LVM metadata (which is never the case yet).
*/
if (commit &&
(!vg || !vg_write(vg) || !vg_commit(vg)))
return_0;
was_active = alloca(sz);
dm_list_iterate_items(lvl, lv_list)
if (!(was_active[i++] = lv_is_active(lvl->lv))) {
lvl->lv->status |= LV_TEMPORARY;
if (!activate_lv(vg->cmd, lvl->lv)) {
log_error("Failed to activate localy %s for wiping.",
display_lvname(lvl->lv));
r = 0;
goto out;
}
lvl->lv->status &= ~LV_TEMPORARY;
}
dm_list_iterate_items(lvl, lv_list) {
/* Wipe any know signatures */
raid: no wiping when zeroing raid metadata device Currently lvm2 is not wiping signatures when creating 'metadata' volumes and raid _rmeta was the only exception - so make the behavior consistent with other metadata devices and drop wiping ATM. Drop also some extra debug since they are now more explanatory in wipe_lv() function. Also note - although lvm2 now does not wipe signatures - the error from such wipping used to be actually 'ignored' before wipe_lv() started to return error (with recent commit) and raid creation continued with 'unzeroed' metadata device. TODO: Several issues to resolve: 1. We may want to flip to wipping with all LVs (in that case we need to support passing --yet & --force). 2. Also we may want to clear whole metadata device - however current function is also used for wipping i.e. snapshot COW device which is likely not a good candidate for full device zeroing. We may also need to think about better logic when extent size is enforcing very large LVs, when only a small portion of LV is ever being used. 3. Using TRIM instead of zeroing metadata device might be worth to implement. mm
2020-07-08 11:59:51 +03:00
if (!wipe_lv(lvl->lv, (struct wipe_params) { .do_zero = 1 /* TODO: is_metadata = 1 */ })) {
raid: fix (de)activation of RaidLVs with visible SubLVs There's a small window during creation of a new RaidLV when rmeta SubLVs are made visible to wipe them in order to prevent erroneous discovery of stale RAID metadata. In case a crash prevents the SubLVs from being committed hidden after such wiping, the RaidLV can still be activated with the SubLVs visible. During deactivation though, a deadlock occurs because the visible SubLVs are deactivated before the RaidLV. The patch adds _check_raid_sublvs to the raid validation in merge.c, an activation check to activate.c (paranoid, because the merge.c check will prevent activation in case of visible SubLVs) and shares the existing wiping function _clear_lvs in raid_manip.c moved to lv_manip.c and renamed to activate_and_wipe_lvlist to remove code duplication. Whilst on it, introduce activate_and_wipe_lv to share with (lvconvert|lvchange).c. Resolves: rhbz1633167
2018-11-01 01:05:08 +03:00
r = 0;
raid: no wiping when zeroing raid metadata device Currently lvm2 is not wiping signatures when creating 'metadata' volumes and raid _rmeta was the only exception - so make the behavior consistent with other metadata devices and drop wiping ATM. Drop also some extra debug since they are now more explanatory in wipe_lv() function. Also note - although lvm2 now does not wipe signatures - the error from such wipping used to be actually 'ignored' before wipe_lv() started to return error (with recent commit) and raid creation continued with 'unzeroed' metadata device. TODO: Several issues to resolve: 1. We may want to flip to wipping with all LVs (in that case we need to support passing --yet & --force). 2. Also we may want to clear whole metadata device - however current function is also used for wipping i.e. snapshot COW device which is likely not a good candidate for full device zeroing. We may also need to think about better logic when extent size is enforcing very large LVs, when only a small portion of LV is ever being used. 3. Using TRIM instead of zeroing metadata device might be worth to implement. mm
2020-07-08 11:59:51 +03:00
goto_out;
raid: fix (de)activation of RaidLVs with visible SubLVs There's a small window during creation of a new RaidLV when rmeta SubLVs are made visible to wipe them in order to prevent erroneous discovery of stale RAID metadata. In case a crash prevents the SubLVs from being committed hidden after such wiping, the RaidLV can still be activated with the SubLVs visible. During deactivation though, a deadlock occurs because the visible SubLVs are deactivated before the RaidLV. The patch adds _check_raid_sublvs to the raid validation in merge.c, an activation check to activate.c (paranoid, because the merge.c check will prevent activation in case of visible SubLVs) and shares the existing wiping function _clear_lvs in raid_manip.c moved to lv_manip.c and renamed to activate_and_wipe_lvlist to remove code duplication. Whilst on it, introduce activate_and_wipe_lv to share with (lvconvert|lvchange).c. Resolves: rhbz1633167
2018-11-01 01:05:08 +03:00
}
}
out:
/* TODO: deactivation is only needed with clustered locking
* in normal case we should keep device active
*/
sz = 0;
dm_list_iterate_items(lvl, lv_list)
if ((i > sz) && !was_active[sz++] &&
!deactivate_lv(vg->cmd, lvl->lv)) {
log_error("Failed to deactivate %s.", display_lvname(lvl->lv));
r = 0; /* Continue deactivating as many as possible. */
}
lv_manip: add synchronization points
2020-09-08 16:20:50 +03:00
if (!sync_local_dev_names(vg->cmd))
log_debug("Failed to sync local device names after deactivation of wiped volumes.");
raid: fix (de)activation of RaidLVs with visible SubLVs There's a small window during creation of a new RaidLV when rmeta SubLVs are made visible to wipe them in order to prevent erroneous discovery of stale RAID metadata. In case a crash prevents the SubLVs from being committed hidden after such wiping, the RaidLV can still be activated with the SubLVs visible. During deactivation though, a deadlock occurs because the visible SubLVs are deactivated before the RaidLV. The patch adds _check_raid_sublvs to the raid validation in merge.c, an activation check to activate.c (paranoid, because the merge.c check will prevent activation in case of visible SubLVs) and shares the existing wiping function _clear_lvs in raid_manip.c moved to lv_manip.c and renamed to activate_and_wipe_lvlist to remove code duplication. Whilst on it, introduce activate_and_wipe_lv to share with (lvconvert|lvchange).c. Resolves: rhbz1633167
2018-11-01 01:05:08 +03:00
return r;
}
/* Wipe logical volume @lv, optionally with @commit of metadata */
int activate_and_wipe_lv(struct logical_volume *lv, int commit)
{
struct dm_list lv_list;
struct lv_list lvl;
lvl.lv = lv;
dm_list_init(&lv_list);
dm_list_add(&lv_list, &lvl.list);
return activate_and_wipe_lvlist(&lv_list, commit);
}
Move _lvcreate into the internal library and rename to lv_create_single. After some refactorings, we can now move the bulk of _lvcreate into the internal library, and we can call from liblvm. In the future, we should refactor lv_create_single further, probably by segtype, to reduce the size of struct lvcreate_params. For now this is a reasonable refactor and allows us to re-use the function from liblvm. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-07-26 06:33:35 +04:00
static struct logical_volume *_create_virtual_origin(struct cmd_context *cmd,
struct volume_group *vg,
const char *lv_name,
uint32_t permission,
uint64_t voriginextents)
{
const struct segment_type *segtype;
cleanup: simplier lv name construction Using NAME_LEN max lv name size.
2014-10-24 16:22:13 +04:00
char vorigin_name[NAME_LEN];
Move _lvcreate into the internal library and rename to lv_create_single. After some refactorings, we can now move the bulk of _lvcreate into the internal library, and we can call from liblvm. In the future, we should refactor lv_create_single further, probably by segtype, to reduce the size of struct lvcreate_params. For now this is a reasonable refactor and allows us to re-use the function from liblvm. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-07-26 06:33:35 +04:00
struct logical_volume *lv;
segtypes: Use SEG_TYPE_NAME_ string constants.
2015-09-22 21:04:12 +03:00
if (!(segtype = get_segtype_from_string(cmd, SEG_TYPE_NAME_ZERO))) {
Move _lvcreate into the internal library and rename to lv_create_single. After some refactorings, we can now move the bulk of _lvcreate into the internal library, and we can call from liblvm. In the future, we should refactor lv_create_single further, probably by segtype, to reduce the size of struct lvcreate_params. For now this is a reasonable refactor and allows us to re-use the function from liblvm. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-07-26 06:33:35 +04:00
log_error("Zero segment type for virtual origin not found");
return NULL;
}
cleanup: simplier lv name construction Using NAME_LEN max lv name size.
2014-10-24 16:22:13 +04:00
if (dm_snprintf(vorigin_name, sizeof(vorigin_name), "%s_vorigin", lv_name) < 0) {
log_error("Virtual origin name is too long.");
Move _lvcreate into the internal library and rename to lv_create_single. After some refactorings, we can now move the bulk of _lvcreate into the internal library, and we can call from liblvm. In the future, we should refactor lv_create_single further, probably by segtype, to reduce the size of struct lvcreate_params. For now this is a reasonable refactor and allows us to re-use the function from liblvm. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-07-26 06:33:35 +04:00
return NULL;
}
if (!(lv = lv_create_empty(vorigin_name, NULL, permission,
ALLOC_INHERIT, vg)))
return_NULL;
This patch adds the ability to extend 0 length layered LVs. This allows us to allocate all images of a mirror (or RAID array) at one time during create. The current mirror implementation still requires a separate allocation for the log, however.
2011-04-07 01:32:20 +04:00
if (!lv_extend(lv, segtype, 1, 0, 1, 0, voriginextents,
thin: simplify thin volume creation Move code for creation of thin volume into a single place out of lv_extend(). This allows to drop extra pool arg for alloc_lv_segment() && lv_extend() and makes code more easier to read and follow.
2014-10-26 10:13:59 +03:00
NULL, ALLOC_INHERIT, 0))
Move _lvcreate into the internal library and rename to lv_create_single. After some refactorings, we can now move the bulk of _lvcreate into the internal library, and we can call from liblvm. In the future, we should refactor lv_create_single further, probably by segtype, to reduce the size of struct lvcreate_params. For now this is a reasonable refactor and allows us to re-use the function from liblvm. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-07-26 06:33:35 +04:00
return_NULL;
return lv;
}
activation: add support for skipping activation of selected LVs Also add -k/--setactivationskip y/n and -K/--ignoreactivationskip options to lvcreate. The --setactivationskip y sets the flag in metadata for an LV to skip the LV during activation. Also, the newly created LV is not activated. Thin snapsots have this flag set automatically if not specified directly by the --setactivationskip y/n option. The --ignoreactivationskip overrides the activation skip flag set in metadata for an LV (just for the run of the command - the flag is not changed in metadata!) A few examples for the lvcreate with the new options: (non-thin snap LV => skip flag not set in MDA + LV activated) raw/~ $ lvcreate -l1 vg Logical volume "lvol0" created raw/~ $ lvs -o lv_name,attr vg/lvol0 LV Attr lvol0 -wi-a---- (non-thin snap LV + -ky => skip flag set in MDA + LV not activated) raw/~ $ lvcreate -l1 -ky vg Logical volume "lvol1" created raw/~ $ lvs -o lv_name,attr vg/lvol1 LV Attr lvol1 -wi------ (non-thin snap LV + -ky + -K => skip flag set in MDA + LV activated) raw/~ $ lvcreate -l1 -ky -K vg Logical volume "lvol2" created raw/~ $ lvs -o lv_name,attr vg/lvol2 LV Attr lvol2 -wi-a---- (thin snap LV => skip flag set in MDA (default behaviour) + LV not activated) raw/~ $ lvcreate -L100M -T vg/pool -V 1T -n thin_lv Logical volume "thin_lv" created raw/~ $ lvcreate -s vg/thin_lv -n thin_snap Logical volume "thin_snap" created raw/~ $ lvs -o name,attr vg LV Attr pool twi-a-tz- thin_lv Vwi-a-tz- thin_snap Vwi---tz- (thin snap LV + -K => skip flag set in MDA (default behaviour) + LV activated) raw/~ $ lvcreate -s vg/thin_lv -n thin_snap -K Logical volume "thin_snap" created raw/~ $ lvs -o name,attr vg/thin_lv LV Attr thin_lv Vwi-a-tz- (thins snap LV + -kn => no skip flag in MDA (default behaviour overridden) + LV activated) [0] raw/~ # lvcreate -s vg/thin_lv -n thin_snap -kn Logical volume "thin_snap" created [0] raw/~ # lvs -o name,attr vg/thin_snap LV Attr thin_snap Vwi-a-tz-
2013-07-10 16:06:50 +04:00
/*
* Automatically set ACTIVATION_SKIP flag for the LV supplied - this
* is default behaviour. If override_default is set, then override
* the default behaviour and add/clear the flag based on 'add_skip' arg
* supplied instead.
*/
void lv_set_activation_skip(struct logical_volume *lv, int override_default,
int add_skip)
{
conf: add activation/auto_set_activation_skip The activation/auto_set_activation_skip enables/disables automatic adding of the ACTIVATION_SKIP LV flag. By default thin snapshots are flagged to be skipped during activation. And by default, the auto_set_activation_skip is enabled.
2013-07-12 11:27:17 +04:00
int skip = 0;
activation: add support for skipping activation of selected LVs Also add -k/--setactivationskip y/n and -K/--ignoreactivationskip options to lvcreate. The --setactivationskip y sets the flag in metadata for an LV to skip the LV during activation. Also, the newly created LV is not activated. Thin snapsots have this flag set automatically if not specified directly by the --setactivationskip y/n option. The --ignoreactivationskip overrides the activation skip flag set in metadata for an LV (just for the run of the command - the flag is not changed in metadata!) A few examples for the lvcreate with the new options: (non-thin snap LV => skip flag not set in MDA + LV activated) raw/~ $ lvcreate -l1 vg Logical volume "lvol0" created raw/~ $ lvs -o lv_name,attr vg/lvol0 LV Attr lvol0 -wi-a---- (non-thin snap LV + -ky => skip flag set in MDA + LV not activated) raw/~ $ lvcreate -l1 -ky vg Logical volume "lvol1" created raw/~ $ lvs -o lv_name,attr vg/lvol1 LV Attr lvol1 -wi------ (non-thin snap LV + -ky + -K => skip flag set in MDA + LV activated) raw/~ $ lvcreate -l1 -ky -K vg Logical volume "lvol2" created raw/~ $ lvs -o lv_name,attr vg/lvol2 LV Attr lvol2 -wi-a---- (thin snap LV => skip flag set in MDA (default behaviour) + LV not activated) raw/~ $ lvcreate -L100M -T vg/pool -V 1T -n thin_lv Logical volume "thin_lv" created raw/~ $ lvcreate -s vg/thin_lv -n thin_snap Logical volume "thin_snap" created raw/~ $ lvs -o name,attr vg LV Attr pool twi-a-tz- thin_lv Vwi-a-tz- thin_snap Vwi---tz- (thin snap LV + -K => skip flag set in MDA (default behaviour) + LV activated) raw/~ $ lvcreate -s vg/thin_lv -n thin_snap -K Logical volume "thin_snap" created raw/~ $ lvs -o name,attr vg/thin_lv LV Attr thin_lv Vwi-a-tz- (thins snap LV + -kn => no skip flag in MDA (default behaviour overridden) + LV activated) [0] raw/~ # lvcreate -s vg/thin_lv -n thin_snap -kn Logical volume "thin_snap" created [0] raw/~ # lvs -o name,attr vg/thin_snap LV Attr thin_snap Vwi-a-tz-
2013-07-10 16:06:50 +04:00
/* override default behaviour */
if (override_default)
skip = add_skip;
/* default behaviour */
conf: add activation/auto_set_activation_skip The activation/auto_set_activation_skip enables/disables automatic adding of the ACTIVATION_SKIP LV flag. By default thin snapshots are flagged to be skipped during activation. And by default, the auto_set_activation_skip is enabled.
2013-07-12 11:27:17 +04:00
else if (lv->vg->cmd->auto_set_activation_skip) {
/* skip activation for thin snapshots by default */
if (lv_is_thin_volume(lv) && first_seg(lv)->origin)
skip = 1;
}
activation: add support for skipping activation of selected LVs Also add -k/--setactivationskip y/n and -K/--ignoreactivationskip options to lvcreate. The --setactivationskip y sets the flag in metadata for an LV to skip the LV during activation. Also, the newly created LV is not activated. Thin snapsots have this flag set automatically if not specified directly by the --setactivationskip y/n option. The --ignoreactivationskip overrides the activation skip flag set in metadata for an LV (just for the run of the command - the flag is not changed in metadata!) A few examples for the lvcreate with the new options: (non-thin snap LV => skip flag not set in MDA + LV activated) raw/~ $ lvcreate -l1 vg Logical volume "lvol0" created raw/~ $ lvs -o lv_name,attr vg/lvol0 LV Attr lvol0 -wi-a---- (non-thin snap LV + -ky => skip flag set in MDA + LV not activated) raw/~ $ lvcreate -l1 -ky vg Logical volume "lvol1" created raw/~ $ lvs -o lv_name,attr vg/lvol1 LV Attr lvol1 -wi------ (non-thin snap LV + -ky + -K => skip flag set in MDA + LV activated) raw/~ $ lvcreate -l1 -ky -K vg Logical volume "lvol2" created raw/~ $ lvs -o lv_name,attr vg/lvol2 LV Attr lvol2 -wi-a---- (thin snap LV => skip flag set in MDA (default behaviour) + LV not activated) raw/~ $ lvcreate -L100M -T vg/pool -V 1T -n thin_lv Logical volume "thin_lv" created raw/~ $ lvcreate -s vg/thin_lv -n thin_snap Logical volume "thin_snap" created raw/~ $ lvs -o name,attr vg LV Attr pool twi-a-tz- thin_lv Vwi-a-tz- thin_snap Vwi---tz- (thin snap LV + -K => skip flag set in MDA (default behaviour) + LV activated) raw/~ $ lvcreate -s vg/thin_lv -n thin_snap -K Logical volume "thin_snap" created raw/~ $ lvs -o name,attr vg/thin_lv LV Attr thin_lv Vwi-a-tz- (thins snap LV + -kn => no skip flag in MDA (default behaviour overridden) + LV activated) [0] raw/~ # lvcreate -s vg/thin_lv -n thin_snap -kn Logical volume "thin_snap" created [0] raw/~ # lvs -o name,attr vg/thin_snap LV Attr thin_snap Vwi-a-tz-
2013-07-10 16:06:50 +04:00
if (skip)
lv->status |= LV_ACTIVATION_SKIP;
else
lv->status &= ~LV_ACTIVATION_SKIP;
}
/*
* Get indication whether the LV should be skipped during activation
* based on the ACTIVATION_SKIP flag (deactivation is never skipped!).
* If 'override_lv_skip_flag' is set, then override it based on the value
* of the 'skip' arg supplied instead.
*/
int lv_activation_skip(struct logical_volume *lv, activation_change_t activate,
activation: lv_activation_skip remove always same arg. Remove 'skip' argument passed into the function. We always used '0' - as this is the only supported option (-K) and there is no complementary option. Also add some testing for behaviour of skipping.
2014-02-19 14:02:16 +04:00
int override_lv_skip_flag)
activation: add support for skipping activation of selected LVs Also add -k/--setactivationskip y/n and -K/--ignoreactivationskip options to lvcreate. The --setactivationskip y sets the flag in metadata for an LV to skip the LV during activation. Also, the newly created LV is not activated. Thin snapsots have this flag set automatically if not specified directly by the --setactivationskip y/n option. The --ignoreactivationskip overrides the activation skip flag set in metadata for an LV (just for the run of the command - the flag is not changed in metadata!) A few examples for the lvcreate with the new options: (non-thin snap LV => skip flag not set in MDA + LV activated) raw/~ $ lvcreate -l1 vg Logical volume "lvol0" created raw/~ $ lvs -o lv_name,attr vg/lvol0 LV Attr lvol0 -wi-a---- (non-thin snap LV + -ky => skip flag set in MDA + LV not activated) raw/~ $ lvcreate -l1 -ky vg Logical volume "lvol1" created raw/~ $ lvs -o lv_name,attr vg/lvol1 LV Attr lvol1 -wi------ (non-thin snap LV + -ky + -K => skip flag set in MDA + LV activated) raw/~ $ lvcreate -l1 -ky -K vg Logical volume "lvol2" created raw/~ $ lvs -o lv_name,attr vg/lvol2 LV Attr lvol2 -wi-a---- (thin snap LV => skip flag set in MDA (default behaviour) + LV not activated) raw/~ $ lvcreate -L100M -T vg/pool -V 1T -n thin_lv Logical volume "thin_lv" created raw/~ $ lvcreate -s vg/thin_lv -n thin_snap Logical volume "thin_snap" created raw/~ $ lvs -o name,attr vg LV Attr pool twi-a-tz- thin_lv Vwi-a-tz- thin_snap Vwi---tz- (thin snap LV + -K => skip flag set in MDA (default behaviour) + LV activated) raw/~ $ lvcreate -s vg/thin_lv -n thin_snap -K Logical volume "thin_snap" created raw/~ $ lvs -o name,attr vg/thin_lv LV Attr thin_lv Vwi-a-tz- (thins snap LV + -kn => no skip flag in MDA (default behaviour overridden) + LV activated) [0] raw/~ # lvcreate -s vg/thin_lv -n thin_snap -kn Logical volume "thin_snap" created [0] raw/~ # lvs -o name,attr vg/thin_snap LV Attr thin_snap Vwi-a-tz-
2013-07-10 16:06:50 +04:00
{
cleanup: move verbose message to lv_activation_skip Simplify code and put verbose message into a single place.
2014-02-18 23:49:32 +04:00
if (!(lv->status & LV_ACTIVATION_SKIP) ||
!is_change_activating(activate) || /* Do not skip deactivation */
activation: lv_activation_skip remove always same arg. Remove 'skip' argument passed into the function. We always used '0' - as this is the only supported option (-K) and there is no complementary option. Also add some testing for behaviour of skipping.
2014-02-19 14:02:16 +04:00
override_lv_skip_flag)
activation: add support for skipping activation of selected LVs Also add -k/--setactivationskip y/n and -K/--ignoreactivationskip options to lvcreate. The --setactivationskip y sets the flag in metadata for an LV to skip the LV during activation. Also, the newly created LV is not activated. Thin snapsots have this flag set automatically if not specified directly by the --setactivationskip y/n option. The --ignoreactivationskip overrides the activation skip flag set in metadata for an LV (just for the run of the command - the flag is not changed in metadata!) A few examples for the lvcreate with the new options: (non-thin snap LV => skip flag not set in MDA + LV activated) raw/~ $ lvcreate -l1 vg Logical volume "lvol0" created raw/~ $ lvs -o lv_name,attr vg/lvol0 LV Attr lvol0 -wi-a---- (non-thin snap LV + -ky => skip flag set in MDA + LV not activated) raw/~ $ lvcreate -l1 -ky vg Logical volume "lvol1" created raw/~ $ lvs -o lv_name,attr vg/lvol1 LV Attr lvol1 -wi------ (non-thin snap LV + -ky + -K => skip flag set in MDA + LV activated) raw/~ $ lvcreate -l1 -ky -K vg Logical volume "lvol2" created raw/~ $ lvs -o lv_name,attr vg/lvol2 LV Attr lvol2 -wi-a---- (thin snap LV => skip flag set in MDA (default behaviour) + LV not activated) raw/~ $ lvcreate -L100M -T vg/pool -V 1T -n thin_lv Logical volume "thin_lv" created raw/~ $ lvcreate -s vg/thin_lv -n thin_snap Logical volume "thin_snap" created raw/~ $ lvs -o name,attr vg LV Attr pool twi-a-tz- thin_lv Vwi-a-tz- thin_snap Vwi---tz- (thin snap LV + -K => skip flag set in MDA (default behaviour) + LV activated) raw/~ $ lvcreate -s vg/thin_lv -n thin_snap -K Logical volume "thin_snap" created raw/~ $ lvs -o name,attr vg/thin_lv LV Attr thin_lv Vwi-a-tz- (thins snap LV + -kn => no skip flag in MDA (default behaviour overridden) + LV activated) [0] raw/~ # lvcreate -s vg/thin_lv -n thin_snap -kn Logical volume "thin_snap" created [0] raw/~ # lvs -o name,attr vg/thin_snap LV Attr thin_snap Vwi-a-tz-
2013-07-10 16:06:50 +04:00
return 0;
activation: fix typo in 'activation skip' message
2014-06-30 13:02:45 +04:00
log_verbose("ACTIVATION_SKIP flag set for LV %s/%s, skipping activation.",
cleanup: move verbose message to lv_activation_skip Simplify code and put verbose message into a single place.
2014-02-18 23:49:32 +04:00
lv->vg->name, lv->name);
return 1;
activation: add support for skipping activation of selected LVs Also add -k/--setactivationskip y/n and -K/--ignoreactivationskip options to lvcreate. The --setactivationskip y sets the flag in metadata for an LV to skip the LV during activation. Also, the newly created LV is not activated. Thin snapsots have this flag set automatically if not specified directly by the --setactivationskip y/n option. The --ignoreactivationskip overrides the activation skip flag set in metadata for an LV (just for the run of the command - the flag is not changed in metadata!) A few examples for the lvcreate with the new options: (non-thin snap LV => skip flag not set in MDA + LV activated) raw/~ $ lvcreate -l1 vg Logical volume "lvol0" created raw/~ $ lvs -o lv_name,attr vg/lvol0 LV Attr lvol0 -wi-a---- (non-thin snap LV + -ky => skip flag set in MDA + LV not activated) raw/~ $ lvcreate -l1 -ky vg Logical volume "lvol1" created raw/~ $ lvs -o lv_name,attr vg/lvol1 LV Attr lvol1 -wi------ (non-thin snap LV + -ky + -K => skip flag set in MDA + LV activated) raw/~ $ lvcreate -l1 -ky -K vg Logical volume "lvol2" created raw/~ $ lvs -o lv_name,attr vg/lvol2 LV Attr lvol2 -wi-a---- (thin snap LV => skip flag set in MDA (default behaviour) + LV not activated) raw/~ $ lvcreate -L100M -T vg/pool -V 1T -n thin_lv Logical volume "thin_lv" created raw/~ $ lvcreate -s vg/thin_lv -n thin_snap Logical volume "thin_snap" created raw/~ $ lvs -o name,attr vg LV Attr pool twi-a-tz- thin_lv Vwi-a-tz- thin_snap Vwi---tz- (thin snap LV + -K => skip flag set in MDA (default behaviour) + LV activated) raw/~ $ lvcreate -s vg/thin_lv -n thin_snap -K Logical volume "thin_snap" created raw/~ $ lvs -o name,attr vg/thin_lv LV Attr thin_lv Vwi-a-tz- (thins snap LV + -kn => no skip flag in MDA (default behaviour overridden) + LV activated) [0] raw/~ # lvcreate -s vg/thin_lv -n thin_snap -kn Logical volume "thin_snap" created [0] raw/~ # lvs -o name,attr vg/thin_snap LV Attr thin_snap Vwi-a-tz-
2013-07-10 16:06:50 +04:00
}
lv_manip: improve should_wipe reporting We want to print smarter warning message only when the zeroing was not provided on the first zeroable segment of newly created LV. Put warning within _should_wipe_lv function to avoid reevaluation of same conditions twice.
2014-10-22 15:29:25 +04:00
static int _should_wipe_lv(struct lvcreate_params *lp,
struct logical_volume *lv, int warn)
{
/* Unzeroable segment */
cleanup: use macros
2016-12-25 01:46:47 +03:00
if (seg_cannot_be_zeroed(first_seg(lv)))
lv_manip: improve should_wipe reporting We want to print smarter warning message only when the zeroing was not provided on the first zeroable segment of newly created LV. Put warning within _should_wipe_lv function to avoid reevaluation of same conditions twice.
2014-10-22 15:29:25 +04:00
return 0;
thin: fix thin LV flagging for udev to skip scanning Only flag thin LV for no scanning in udev if this LV is about to be wiped. This happens only in case the thin LV's pool was not created with zeroing of the new blocks enabled.
2014-01-20 15:38:21 +04:00
lv_manip: improve should_wipe reporting We want to print smarter warning message only when the zeroing was not provided on the first zeroable segment of newly created LV. Put warning within _should_wipe_lv function to avoid reevaluation of same conditions twice.
2014-10-22 15:29:25 +04:00
/* Thin snapshot need not to be zeroed */
/* Thin pool with zeroing doesn't need zeroing or wiping */
if (lv_is_thin_volume(lv) &&
(first_seg(lv)->origin ||
first_seg(first_seg(lv)->pool_lv)->zero_new_blocks))
return 0;
thin: fix thin LV flagging for udev to skip scanning Only flag thin LV for no scanning in udev if this LV is about to be wiped. This happens only in case the thin LV's pool was not created with zeroing of the new blocks enabled.
2014-01-20 15:38:21 +04:00
vdo: skip zeroing for VDO LV Since VDO is always returns 'zero' on unprovisioned read and every provisioned block is always 'zeroed' on partial writes, we can avoid 'zeroing' of such LVs.
2021-08-27 00:04:56 +03:00
/* VDO LV do not need to be zeroed */
if (lv_is_vdo(lv))
return 0;
lvcreate: use lv_passes_readonly_filter Check if created LV is going to be activated read-only because such LV cannot be zeroed (equals to use option '-pr').
2021-02-02 21:53:59 +03:00
if (warn && (lv_passes_readonly_filter(lv))) {
log_warn("WARNING: Read-only activated logical volume %s not zeroed.",
display_lvname(lv));
return 0;
}
lv_manip: improve should_wipe reporting We want to print smarter warning message only when the zeroing was not provided on the first zeroable segment of newly created LV. Put warning within _should_wipe_lv function to avoid reevaluation of same conditions twice.
2014-10-22 15:29:25 +04:00
/* Cannot zero read-only volume */
if ((lv->status & LVM_WRITE) &&
(lp->zero || lp->wipe_signatures))
return 1;
if (warn && (!lp->zero || !(lv->status & LVM_WRITE)))
log_warn("WARNING: Logical volume %s not zeroed.",
display_lvname(lv));
if (warn && (!lp->wipe_signatures || !(lv->status & LVM_WRITE)))
log_verbose("Signature wiping on logical volume %s not requested.",
display_lvname(lv));
thin: fix thin LV flagging for udev to skip scanning Only flag thin LV for no scanning in udev if this LV is about to be wiped. This happens only in case the thin LV's pool was not created with zeroing of the new blocks enabled.
2014-01-20 15:38:21 +04:00
return 0;
}
cleanup: move code for checking vg features Move code that checks for needed VG features into separate smaller function.
2014-10-21 13:23:33 +04:00
/* Check if VG metadata supports needed features */
static int _vg_check_features(struct volume_group *vg,
struct lvcreate_params *lp)
{
uint32_t features = vg->fid->fmt->features;
if (vg_max_lv_reached(vg)) {
log_error("Maximum number of logical volumes (%u) reached "
"in volume group %s", vg->max_lv, vg->name);
return 0;
}
if (!(features & FMT_SEGMENTS) &&
(seg_is_cache(lp) ||
seg_is_cache_pool(lp) ||
mirror: checking for mirror segtype Checking more correctly for mirror segtype here instead of mirrored one which can be also 'raid'.
2018-04-20 11:01:28 +03:00
seg_is_mirror(lp) ||
cleanup: move code for checking vg features Move code that checks for needed VG features into separate smaller function.
2014-10-21 13:23:33 +04:00
seg_is_raid(lp) ||
seg_is_thin(lp))) {
log_error("Metadata does not support %s segments.",
lp->segtype->name);
return 0;
}
if (!(features & FMT_TAGS) && !dm_list_empty(&lp->tags)) {
log_error("Volume group %s does not support tags.", vg->name);
return 0;
}
if ((features & FMT_RESTRICTED_READAHEAD) &&
lp->read_ahead != DM_READ_AHEAD_AUTO &&
lp->read_ahead != DM_READ_AHEAD_NONE &&
(lp->read_ahead < 2 || lp->read_ahead > 120)) {
log_error("Metadata only supports readahead values between 2 and 120.");
return 0;
}
/* Need to check the vg's format to verify this - the cmd format isn't setup properly yet */
if (!(features & FMT_UNLIMITED_STRIPESIZE) &&
(lp->stripes > 1) && (lp->stripe_size > STRIPE_SIZE_MAX)) {
log_error("Stripe size may not exceed %s.",
display_size(vg->cmd, (uint64_t) STRIPE_SIZE_MAX));
return 0;
}
return 1;
}
lvcreate parsing for thin provisioning. The rest is incomplete so this isn't usable yet.
2011-09-06 04:26:42 +04:00
/* Thin notes:
* If lp->thin OR lp->activate is AY*, activate the pool if not already active.
* If lp->thin, create thin LV within the pool - as a snapshot if lp->snapshot.
* If lp->activate is AY*, activate it.
comment: update Use 'is' for both forms.
2017-07-08 20:15:49 +03:00
* If lp->activate is AN* and the pool was originally not active, deactivate it.
lvcreate parsing for thin provisioning. The rest is incomplete so this isn't usable yet.
2011-09-06 04:26:42 +04:00
*/
RAID: Make RAID single-machine-exclusive capable in a cluster Creation, deletion, [de]activation, repair, conversion, scrubbing and changing operations are all now available for RAID LVs in a cluster - provided that they are activated exclusively. The code has been changed to ensure that no LV or sub-LV activation is attempted cluster-wide. This includes the often overlooked operations of activating metadata areas for the brief time it takes to clear them. Additionally, some 'resume_lv' operations were replaced with 'activate_lv_excl_local' when sub-LVs were promoted to top-level LVs for removal, clearing or extraction. This was necessary because it forces the appropriate renaming actions the occur via resume in the single-machine case, but won't happen in a cluster due to the necessity of acquiring a lock first. The *raid* tests have been updated to allow testing in a cluster. For the most part, this meant creating devices with '-aey' if they were to be converted to RAID. (RAID requires the converting LV to be EX because it is a condition of activation for the RAID LV in a cluster.)
2013-09-11 01:33:22 +04:00
static struct logical_volume *_lv_create_an_lv(struct volume_group *vg,
struct lvcreate_params *lp,
lvcreate parsing for thin provisioning. The rest is incomplete so this isn't usable yet.
2011-09-06 04:26:42 +04:00
const char *new_lv_name)
Move _lvcreate into the internal library and rename to lv_create_single. After some refactorings, we can now move the bulk of _lvcreate into the internal library, and we can call from liblvm. In the future, we should refactor lv_create_single further, probably by segtype, to reduce the size of struct lvcreate_params. For now this is a reasonable refactor and allows us to re-use the function from liblvm. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-07-26 06:33:35 +04:00
{
struct cmd_context *cmd = vg->cmd;
stripes: Introduce _round_to_stripe_boundary.
2015-09-24 19:50:53 +03:00
uint32_t size;
cleanup: move code
2014-10-18 13:01:34 +04:00
uint64_t status = lp->permission | VISIBLE_LV;
lvcreate: new validation code Refactor lvcreate code. Prefer to use arg_outside_list_is_set() so we get automatic 'white-list' validation of supported options with different segment types. Drop used lp->cache, lp->cache and use seg_is_cache(), seg_is_thin() Draw clear border where is the last moment we could change create segment type. When segment type is given with --type - do not allow it to be changed later. Put together tests related to individual segment types. Finish cache conversion at proper part of lv_manip code after the vg_metadata are written - so we could correcly clean-up created stripe LV for cache volume.
2014-10-24 17:26:41 +04:00
const struct segment_type *create_segtype = lp->segtype;
cleanup: rename _name, _lv and _size Use some standard names for lv char * names, logical_volume * lv and sizes internally.
2014-10-07 12:43:47 +04:00
struct logical_volume *lv, *origin_lv = NULL;
thin: simplify thin volume creation Move code for creation of thin volume into a single place out of lv_extend(). This allows to drop extra pool arg for alloc_lv_segment() && lv_extend() and makes code more easier to read and follow.
2014-10-26 10:13:59 +03:00
struct logical_volume *pool_lv = NULL;
cache: improve creation code Move code to better locations. Improve test and remove invalid ones (i.e. no reason to require cache size to be >= then origin). Correctly comment where the code is doing actual conversion of other existing volume - we do already a similar thing with external origins. Lots of new command line options and combinations is now supported. Hopefully older syntax still works as well. lvcreate --cache --cachepool vg/pool -l1 lvcreate --type cache --cachepool vg/pool -l1 lvcreate --type cache-pool vg/pool -l1 lvcreate --type cache-pool --name pool vg -l1 ... and many many more ...
2014-10-04 01:51:54 +04:00
struct logical_volume *tmp_lv;
gcc: cleanup warns from older gcc
2020-10-25 23:56:02 +03:00
struct lv_segment *seg = NULL, *pool_seg;
thin: check for new pool before creating thin volume Call check_new_thin_pool() to detect in-use thin-pool. Save extra reactivation of thin-pool when thin pool is not active. (it's now a bit more expensive to invoke thin_check for new pools.) For new pools: We now active locally exclusively thin-pool as 'public' LV. Validate transaction_id is till 0. Deactive. Prepare create message for thin-pool and exclusively active pool. Active new thin LV. And deactivate thin pool if it used to be inactive.
2014-11-04 17:08:15 +03:00
int thin_pool_was_active = -1; /* not scanned, inactive, active */
metadata: also look at historical LVs when checking LV name availability Live LVs and historical LVs are in one namespace and the name needs to be unique in whole VG.
2016-03-01 17:31:48 +03:00
int historical;
thin: enhance lvcreate error paths Improve error response and reporting, when creating thin snapshots. If the thin pool kernel metadata already have device with ID lvm2 tries to create, give more meanigful error message and also properly restore transaction id to the value known to thin-pool in this case. Before it's been possible to divert by one from kernel TID value, and lvm2 stacked delete message for such thin device.
2020-09-25 23:43:57 +03:00
uint64_t transaction_id;
int ret;
Move _lvcreate into the internal library and rename to lv_create_single. After some refactorings, we can now move the bulk of _lvcreate into the internal library, and we can call from liblvm. In the future, we should refactor lv_create_single further, probably by segtype, to reduce the size of struct lvcreate_params. For now this is a reasonable refactor and allows us to re-use the function from liblvm. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-07-26 06:33:35 +04:00
metadata: also look at historical LVs when checking LV name availability Live LVs and historical LVs are in one namespace and the name needs to be unique in whole VG.
2016-03-01 17:31:48 +03:00
if (new_lv_name && lv_name_is_used_in_vg(vg, new_lv_name, &historical)) {
log_error("%sLogical Volume \"%s\" already exists in "
"volume group \"%s\"", historical ? "historical " : "",
new_lv_name, vg->name);
lvcreate parsing for thin provisioning. The rest is incomplete so this isn't usable yet.
2011-09-06 04:26:42 +04:00
return NULL;
Move _lvcreate into the internal library and rename to lv_create_single. After some refactorings, we can now move the bulk of _lvcreate into the internal library, and we can call from liblvm. In the future, we should refactor lv_create_single further, probably by segtype, to reduce the size of struct lvcreate_params. For now this is a reasonable refactor and allows us to re-use the function from liblvm. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-07-26 06:33:35 +04:00
}
cleanup: move code for checking vg features Move code that checks for needed VG features into separate smaller function.
2014-10-21 13:23:33 +04:00
if (!_vg_check_features(vg, lp))
return_NULL;
Move _lvcreate into the internal library and rename to lv_create_single. After some refactorings, we can now move the bulk of _lvcreate into the internal library, and we can call from liblvm. In the future, we should refactor lv_create_single further, probably by segtype, to reduce the size of struct lvcreate_params. For now this is a reasonable refactor and allows us to re-use the function from liblvm. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-07-26 06:33:35 +04:00
lvcreate: move tests that requires activation Tests that needs active kernel driver put in single place.
2014-10-21 14:12:45 +04:00
if (!activation()) {
if (seg_is_cache(lp) ||
seg_is_mirror(lp) ||
raid0: Add raid0 segment type. This remains experimental and quite restrictive so should only be used for testing at this stage. (E.g. lvreduce is not supported.)
2016-05-23 18:46:38 +03:00
(seg_is_raid(lp) && !seg_is_raid0(lp)) ||
lvcreate: move tests that requires activation Tests that needs active kernel driver put in single place.
2014-10-21 14:12:45 +04:00
seg_is_thin(lp) ||
vdo: introduce segment types and manip functions Core functionality introducing lvm VDO support.
2018-06-29 12:11:14 +03:00
seg_is_vdo(lp) ||
lvcreate: move tests that requires activation Tests that needs active kernel driver put in single place.
2014-10-21 14:12:45 +04:00
lp->snapshot) {
/*
* FIXME: For thin pool add some code to allow delayed
* initialization of empty thin pool volume.
* i.e. using some LV flag, fake message,...
* and testing for metadata pool header signature?
*/
log_error("Can't create %s without using "
"device-mapper kernel driver.",
lp->segtype->name);
return NULL;
}
/* Does LV need to be zeroed? */
active: fix compilation without devmapper Better support for compilation without device-mapper.
2020-09-28 19:56:58 +03:00
if (lp->zero) {
log_warn("WARNING: Skipping zeroing and wipping, compiled without activation support.");
lp->zero = 0;
lp->wipe_signatures = 0;
lvcreate: move tests that requires activation Tests that needs active kernel driver put in single place.
2014-10-21 14:12:45 +04:00
}
}
Move _lvcreate into the internal library and rename to lv_create_single. After some refactorings, we can now move the bulk of _lvcreate into the internal library, and we can call from liblvm. In the future, we should refactor lv_create_single further, probably by segtype, to reduce the size of struct lvcreate_params. For now this is a reasonable refactor and allows us to re-use the function from liblvm. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-07-26 06:33:35 +04:00
if (lp->stripe_size > vg->extent_size) {
cleanup: indent Various indents and tiny error message improvements.
2014-10-18 13:01:29 +04:00
if (seg_is_raid(lp) && (vg->extent_size < STRIPE_SIZE_MIN)) {
RAID: Fail RAID4/5/6 creation if PE size is less than STRIPE_SIZE_MIN The maximum stripe size is equal to the volume group PE size. If that size falls below the STRIPE_SIZE_MIN, the creation of RAID 4/5/6 volumes becomes impossible. (The kernel will fail to load a RAID 4/5/6 mapping table with a stripe size less than STRIPE_SIZE_MIN.) So, we report an error if it is attempted. This is very rare because reducing the PE size down that far limits the size of the PV below that of modern devices.
2014-08-16 06:15:34 +04:00
/*
* FIXME: RAID will simply fail to load the table if
* this is the case, but we should probably
* honor the stripe minimum for regular stripe
* volumes as well. Avoiding doing that now
* only to minimize the change.
*/
pre-release
2014-08-26 19:34:14 +04:00
log_error("The extent size in volume group %s is too "
"small to support striped RAID volumes.",
RAID: Fail RAID4/5/6 creation if PE size is less than STRIPE_SIZE_MIN The maximum stripe size is equal to the volume group PE size. If that size falls below the STRIPE_SIZE_MIN, the creation of RAID 4/5/6 volumes becomes impossible. (The kernel will fail to load a RAID 4/5/6 mapping table with a stripe size less than STRIPE_SIZE_MIN.) So, we report an error if it is attempted. This is very rare because reducing the PE size down that far limits the size of the PV below that of modern devices.
2014-08-16 06:15:34 +04:00
vg->name);
return NULL;
}
cleanup: use log_print instead of log_error Since reduce the message has informational character and doesn't lead to exit of the command - reduce the log level to info print as we use for other similar types. Reindent next print message.
2013-06-20 16:08:25 +04:00
log_print_unless_silent("Reducing requested stripe size %s to maximum, "
"physical extent size %s.",
display_size(cmd, (uint64_t) lp->stripe_size),
display_size(cmd, (uint64_t) vg->extent_size));
Move _lvcreate into the internal library and rename to lv_create_single. After some refactorings, we can now move the bulk of _lvcreate into the internal library, and we can call from liblvm. In the future, we should refactor lv_create_single further, probably by segtype, to reduce the size of struct lvcreate_params. For now this is a reasonable refactor and allows us to re-use the function from liblvm. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-07-26 06:33:35 +04:00
lp->stripe_size = vg->extent_size;
}
stripes: Introduce _round_to_stripe_boundary.
2015-09-24 19:50:53 +03:00
lp->extents = _round_to_stripe_boundary(vg, lp->extents, lp->stripes, 1);
Move _lvcreate into the internal library and rename to lv_create_single. After some refactorings, we can now move the bulk of _lvcreate into the internal library, and we can call from liblvm. In the future, we should refactor lv_create_single further, probably by segtype, to reduce the size of struct lvcreate_params. For now this is a reasonable refactor and allows us to re-use the function from liblvm. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-07-26 06:33:35 +04:00
lv_manip: do not check extents for any virtual target Allow creation of any virtual segment type with just --virtualsize specified without any real extent size give. TODO: likely --type error,zero might be later enhanced to use -V (along with -L) - but since those targets do not allocate real space, supporting -V makes sense with them.
2018-06-29 12:25:08 +03:00
if (!lp->extents && !seg_is_virtual(lp)) {
lvcreate: new validation code Refactor lvcreate code. Prefer to use arg_outside_list_is_set() so we get automatic 'white-list' validation of supported options with different segment types. Drop used lp->cache, lp->cache and use seg_is_cache(), seg_is_thin() Draw clear border where is the last moment we could change create segment type. When segment type is given with --type - do not allow it to be changed later. Put together tests related to individual segment types. Finish cache conversion at proper part of lv_manip code after the vg_metadata are written - so we could correcly clean-up created stripe LV for cache volume.
2014-10-24 17:26:41 +04:00
log_error(INTERNAL_ERROR "Unable to create new logical volume with no extents.");
debug: cleanup backtrace after log_error
2016-09-16 15:42:37 +03:00
return NULL;
lvcreate: new validation code Refactor lvcreate code. Prefer to use arg_outside_list_is_set() so we get automatic 'white-list' validation of supported options with different segment types. Drop used lp->cache, lp->cache and use seg_is_cache(), seg_is_thin() Draw clear border where is the last moment we could change create segment type. When segment type is given with --type - do not allow it to be changed later. Put together tests related to individual segment types. Finish cache conversion at proper part of lv_manip code after the vg_metadata are written - so we could correcly clean-up created stripe LV for cache volume.
2014-10-24 17:26:41 +04:00
}
cache: support more args Unlike with thin-pool - with cache we support all args also directly when create cache volume. So the result of 'separate' cache-pool creation and setting its options should give same result as specifying those args during cache creation. Cache-pool values are used as defaults if the params are not specified with cache creation.
2014-10-26 18:17:14 +03:00
if ((seg_is_pool(lp) || seg_is_cache(lp)) &&
lvcreate: new validation code Refactor lvcreate code. Prefer to use arg_outside_list_is_set() so we get automatic 'white-list' validation of supported options with different segment types. Drop used lp->cache, lp->cache and use seg_is_cache(), seg_is_thin() Draw clear border where is the last moment we could change create segment type. When segment type is given with --type - do not allow it to be changed later. Put together tests related to individual segment types. Finish cache conversion at proper part of lv_manip code after the vg_metadata are written - so we could correcly clean-up created stripe LV for cache volume.
2014-10-24 17:26:41 +04:00
((uint64_t)lp->extents * vg->extent_size < lp->chunk_size)) {
log_error("Unable to create %s smaller than 1 chunk.",
lp->segtype->name);
return NULL;
}
if ((lp->alloc != ALLOC_ANYWHERE) && (lp->stripes > dm_list_size(lp->pvh))) {
log_error("Number of stripes (%u) must not exceed "
"number of physical volumes (%d)", lp->stripes,
dm_list_size(lp->pvh));
return NULL;
}
if (seg_is_pool(lp))
status |= LVM_WRITE; /* Pool is always writable */
vdo: introduce segment types and manip functions Core functionality introducing lvm VDO support.
2018-06-29 12:11:14 +03:00
else if (seg_is_cache(lp) || seg_is_thin_volume(lp) || seg_is_vdo(lp)) {
pools: prefetch pool_lv and origin_lv Load pool_lv and origin_lv at a single place and use it for more types as they need them.
2014-10-26 20:17:40 +03:00
/* Resolve pool volume */
if (!lp->pool_name) {
/* Should be already checked */
log_error(INTERNAL_ERROR "Cannot create %s volume without %s pool.",
lp->segtype->name, lp->segtype->name);
return NULL;
}
lvcreate: new validation code Refactor lvcreate code. Prefer to use arg_outside_list_is_set() so we get automatic 'white-list' validation of supported options with different segment types. Drop used lp->cache, lp->cache and use seg_is_cache(), seg_is_thin() Draw clear border where is the last moment we could change create segment type. When segment type is given with --type - do not allow it to be changed later. Put together tests related to individual segment types. Finish cache conversion at proper part of lv_manip code after the vg_metadata are written - so we could correcly clean-up created stripe LV for cache volume.
2014-10-24 17:26:41 +04:00
pools: prefetch pool_lv and origin_lv Load pool_lv and origin_lv at a single place and use it for more types as they need them.
2014-10-26 20:17:40 +03:00
if (!(pool_lv = find_lv(vg, lp->pool_name))) {
log_error("Couldn't find volume %s in Volume group %s.",
lp->pool_name, vg->name);
lvcreate: new validation code Refactor lvcreate code. Prefer to use arg_outside_list_is_set() so we get automatic 'white-list' validation of supported options with different segment types. Drop used lp->cache, lp->cache and use seg_is_cache(), seg_is_thin() Draw clear border where is the last moment we could change create segment type. When segment type is given with --type - do not allow it to be changed later. Put together tests related to individual segment types. Finish cache conversion at proper part of lv_manip code after the vg_metadata are written - so we could correcly clean-up created stripe LV for cache volume.
2014-10-24 17:26:41 +04:00
return NULL;
}
pools: prefetch pool_lv and origin_lv Load pool_lv and origin_lv at a single place and use it for more types as they need them.
2014-10-26 20:17:40 +03:00
if (lv_is_locked(pool_lv)) {
log_error("Cannot use locked pool volume %s.",
display_lvname(pool_lv));
return NULL;
}
cache: apply chunk rounding also for cache creation. When we create volumes with chunk size bigger then extent size we try to round up to some nearest chunk boundary. Until now we did this for thins - use same logic for cache volumes.
2014-10-26 20:17:59 +03:00
lvcreate: do not round cache volumes on cache chunks Since cache chunk might be huge and there is no technical need to enforce rounding and there is actually more 'real' VG space used then necessary - keep rounding on 'chunk' bounrary only for thin volumes - where it's the space used anyway. NB: we support conversion of any-size 'existing' LV into cached LV.
2017-03-09 19:15:56 +03:00
if (seg_is_thin_volume(lp)) {
/* Validate volume size to to aling on chunk for small extents */
size = first_seg(pool_lv)->chunk_size;
if (size > vg->extent_size) {
/* Align extents on chunk boundary size */
size = ((uint64_t)vg->extent_size * lp->extents + size - 1) /
size * size / vg->extent_size;
if (size != lp->extents) {
log_print_unless_silent("Rounding size (%d extents) up to chunk boundary "
"size (%d extents).", lp->extents, size);
lp->extents = size;
}
cache: apply chunk rounding also for cache creation. When we create volumes with chunk size bigger then extent size we try to round up to some nearest chunk boundary. Until now we did this for thins - use same logic for cache volumes.
2014-10-26 20:17:59 +03:00
}
cache: wipe cache-pool before reuse Before we reuse cache-pool - we need to ensure metadata volume has wiped header.
2014-11-02 21:41:46 +03:00
thin: enforce local activation when creation new thin As we need to check how full thin-pool is - require thin-pool is locally active.
2015-10-14 02:00:35 +03:00
thin_pool_was_active = lv_is_active(pool_lv);
thin: check for overflown pool earlier Check for pool early before we actually start to modify metadata. This requires locally active thin-pool.
2015-10-07 16:10:03 +03:00
if (lv_is_new_thin_pool(pool_lv)) {
if (!check_new_thin_pool(pool_lv))
return_NULL;
/* New pool is now inactive */
thin: enforce local activation when creation new thin As we need to check how full thin-pool is - require thin-pool is locally active.
2015-10-14 02:00:35 +03:00
} else {
Remove unused clvm variations for active LVs Different flavors of activate_lv() and lv_is_active() which are meaningful in a clustered VG can be eliminated and replaced with whatever that flavor already falls back to in a local VG. e.g. lv_is_active_exclusive_locally() is distinct from lv_is_active() in a clustered VG, but in a local VG they are equivalent. So, all instances of the variant are replaced with the basic local equivalent. For local VGs, the same behavior remains as before. For shared VGs, lvmlockd was written with the explicit requirement of local behavior from these functions (lvmlockd requires locking_type 1), so the behavior in shared VGs also remains the same.
2018-06-05 21:21:28 +03:00
if (!activate_lv(cmd, pool_lv)) {
thin: enforce local activation when creation new thin As we need to check how full thin-pool is - require thin-pool is locally active.
2015-10-14 02:00:35 +03:00
log_error("Aborting. Failed to locally activate thin pool %s.",
display_lvname(pool_lv));
cleanup: minor cosmetics Update some return value to match return type. Drop unused function and declaration.
2017-02-28 14:31:36 +03:00
return NULL;
thin: enforce local activation when creation new thin As we need to check how full thin-pool is - require thin-pool is locally active.
2015-10-14 02:00:35 +03:00
}
thin: rename internal function Names matching internal code layout. Functionc in thin_manip.c uses thin_pool in its name. Keep 'pool' only for function working for both cache and thin pools. No change of functionality.
2022-08-24 16:02:07 +03:00
if (!thin_pool_below_threshold(first_seg(pool_lv))) {
thin: enforce local activation when creation new thin As we need to check how full thin-pool is - require thin-pool is locally active.
2015-10-14 02:00:35 +03:00
log_error("Cannot create new thin volume, free space in "
"thin pool %s reached threshold.",
display_lvname(pool_lv));
return NULL;
}
thin: check for overflown pool earlier Check for pool early before we actually start to modify metadata. This requires locally active thin-pool.
2015-10-07 16:10:03 +03:00
}
thin: check for new pool before creating thin volume Call check_new_thin_pool() to detect in-use thin-pool. Save extra reactivation of thin-pool when thin pool is not active. (it's now a bit more expensive to invoke thin_check for new pools.) For new pools: We now active locally exclusively thin-pool as 'public' LV. Validate transaction_id is till 0. Deactive. Prepare create message for thin-pool and exclusively active pool. Active new thin LV. And deactivate thin pool if it used to be inactive.
2014-11-04 17:08:15 +03:00
}
cache: wipe cache-pool before reuse Before we reuse cache-pool - we need to ensure metadata volume has wiped header.
2014-11-02 21:41:46 +03:00
if (seg_is_cache(lp) &&
!wipe_cache_pool(pool_lv))
return_NULL;
pools: prefetch pool_lv and origin_lv Load pool_lv and origin_lv at a single place and use it for more types as they need them.
2014-10-26 20:17:40 +03:00
}
/* Resolve origin volume */
if (lp->origin_name &&
!(origin_lv = find_lv(vg, lp->origin_name))) {
log_error("Origin volume %s not found in Volume group %s.",
lp->origin_name, vg->name);
return NULL;
}
if (origin_lv && seg_is_cache_pool(lp)) {
/* Converting exiting origin and creating cache pool */
cache: separate func for pool/origin validation Split validate_lv_cache_create() into 2 function once is called for pool validation other for origin. It's less misleading the accepting NULLs.
2014-10-22 23:01:03 +04:00
if (!validate_lv_cache_create_origin(origin_lv))
lvcreate: new validation code Refactor lvcreate code. Prefer to use arg_outside_list_is_set() so we get automatic 'white-list' validation of supported options with different segment types. Drop used lp->cache, lp->cache and use seg_is_cache(), seg_is_thin() Draw clear border where is the last moment we could change create segment type. When segment type is given with --type - do not allow it to be changed later. Put together tests related to individual segment types. Finish cache conversion at proper part of lv_manip code after the vg_metadata are written - so we could correcly clean-up created stripe LV for cache volume.
2014-10-24 17:26:41 +04:00
return_NULL;
pools: prefetch pool_lv and origin_lv Load pool_lv and origin_lv at a single place and use it for more types as they need them.
2014-10-26 20:17:40 +03:00
if (origin_lv->size < lp->chunk_size) {
log_error("Caching of origin cache volume smaller then chunk size is unsupported.");
return NULL;
}
cache: add more validation
2015-08-11 16:11:45 +03:00
} else if (seg_is_cache(lp)) {
if (!pool_lv) {
log_error(INTERNAL_ERROR "Pool LV for cache is missing.");
return NULL;
}
lvcreate: new validation code Refactor lvcreate code. Prefer to use arg_outside_list_is_set() so we get automatic 'white-list' validation of supported options with different segment types. Drop used lp->cache, lp->cache and use seg_is_cache(), seg_is_thin() Draw clear border where is the last moment we could change create segment type. When segment type is given with --type - do not allow it to be changed later. Put together tests related to individual segment types. Finish cache conversion at proper part of lv_manip code after the vg_metadata are written - so we could correcly clean-up created stripe LV for cache volume.
2014-10-24 17:26:41 +04:00
if (!lv_is_cache_pool(pool_lv)) {
log_error("Logical volume %s is not a cache pool.",
display_lvname(pool_lv));
cache: Code to allow the create/remove of cache LVs This patch allows users to create cache LVs with 'lvcreate'. An origin or a cache pool LV must be created first. Then, while supplying the origin or cache pool to the lvcreate command, the cache can be created. Ex1: Here the cache pool is created first, followed by the origin which will be cached. ~> lvcreate --type cache_pool -L 500M -n cachepool vg /dev/small_n_fast ~> lvcreate --type cache -L 1G -n lv vg/cachepool /dev/large_n_slow Ex2: Here the origin is created first, followed by the cache pool - allowing a cache LV to be created covering the origin. ~> lvcreate -L 1G -n lv vg /dev/large_n_slow ~> lvcreate --type cache -L 500M -n cachepool vg/lv /dev/small_n_fast The code determines which type of LV was supplied (cache pool or origin) by checking its type. It ensures the right argument was given by ensuring that the origin is larger than the cache pool. If the user wants to remove just the cache for an LV. They specify the LV's associated cache pool when removing: ~> lvremove vg/cachepool If the user wishes to remove the origin, but leave the cachepool to be used for another LV, they specify the cache LV. ~> lvremove vg/lv In order to remove it all, specify both LVs. This patch also includes tests to create and remove cache pools and cache LVs.
2014-02-05 02:50:16 +04:00
return NULL;
}
lvcreate: new validation code Refactor lvcreate code. Prefer to use arg_outside_list_is_set() so we get automatic 'white-list' validation of supported options with different segment types. Drop used lp->cache, lp->cache and use seg_is_cache(), seg_is_thin() Draw clear border where is the last moment we could change create segment type. When segment type is given with --type - do not allow it to be changed later. Put together tests related to individual segment types. Finish cache conversion at proper part of lv_manip code after the vg_metadata are written - so we could correcly clean-up created stripe LV for cache volume.
2014-10-24 17:26:41 +04:00
/* Create cache origin for cache pool */
pre-release
2014-11-11 17:13:00 +03:00
/* FIXME Eventually support raid/mirrors with -m */
segtypes: Use SEG_TYPE_NAME_ string constants.
2015-09-22 21:04:12 +03:00
if (!(create_segtype = get_segtype_from_string(vg->cmd, SEG_TYPE_NAME_STRIPED)))
cache: Code to allow the create/remove of cache LVs This patch allows users to create cache LVs with 'lvcreate'. An origin or a cache pool LV must be created first. Then, while supplying the origin or cache pool to the lvcreate command, the cache can be created. Ex1: Here the cache pool is created first, followed by the origin which will be cached. ~> lvcreate --type cache_pool -L 500M -n cachepool vg /dev/small_n_fast ~> lvcreate --type cache -L 1G -n lv vg/cachepool /dev/large_n_slow Ex2: Here the origin is created first, followed by the cache pool - allowing a cache LV to be created covering the origin. ~> lvcreate -L 1G -n lv vg /dev/large_n_slow ~> lvcreate --type cache -L 500M -n cachepool vg/lv /dev/small_n_fast The code determines which type of LV was supplied (cache pool or origin) by checking its type. It ensures the right argument was given by ensuring that the origin is larger than the cache pool. If the user wants to remove just the cache for an LV. They specify the LV's associated cache pool when removing: ~> lvremove vg/cachepool If the user wishes to remove the origin, but leave the cachepool to be used for another LV, they specify the cache LV. ~> lvremove vg/lv In order to remove it all, specify both LVs. This patch also includes tests to create and remove cache pools and cache LVs.
2014-02-05 02:50:16 +04:00
return_0;
Allow dm-integrity to be used for raid images dm-integrity stores checksums of the data written to an LV, and returns an error if data read from the LV does not match the previously saved checksum. When used on raid images, dm-raid will correct the error by reading the block from another image, and the device user sees no error. The integrity metadata (checksums) are stored on an internal LV allocated by lvm for each linear image. The internal LV is allocated on the same PV as the image. Create a raid LV with an integrity layer over each raid image (for raid levels 1,4,5,6,10): lvcreate --type raidN --raidintegrity y [options] Add an integrity layer to images of an existing raid LV: lvconvert --raidintegrity y LV Remove the integrity layer from images of a raid LV: lvconvert --raidintegrity n LV Settings Use --raidintegritymode journal|bitmap (journal is default) to configure the method used by dm-integrity to ensure crash consistency. Initialization When integrity is added to an LV, the kernel needs to initialize the integrity metadata/checksums for all blocks in the LV. The data corruption checking performed by dm-integrity will only operate on areas of the LV that are already initialized. The progress of integrity initialization is reported by the "syncpercent" LV reporting field (and under the Cpy%Sync lvs column.) Example: create a raid1 LV with integrity: $ lvcreate --type raid1 -m1 --raidintegrity y -n rr -L1G foo Creating integrity metadata LV rr_rimage_0_imeta with size 12.00 MiB. Logical volume "rr_rimage_0_imeta" created. Creating integrity metadata LV rr_rimage_1_imeta with size 12.00 MiB. Logical volume "rr_rimage_1_imeta" created. Logical volume "rr" created. $ lvs -a foo LV VG Attr LSize Origin Cpy%Sync rr foo rwi-a-r--- 1.00g 4.93 [rr_rimage_0] foo gwi-aor--- 1.00g [rr_rimage_0_iorig] 41.02 [rr_rimage_0_imeta] foo ewi-ao---- 12.00m [rr_rimage_0_iorig] foo -wi-ao---- 1.00g [rr_rimage_1] foo gwi-aor--- 1.00g [rr_rimage_1_iorig] 39.45 [rr_rimage_1_imeta] foo ewi-ao---- 12.00m [rr_rimage_1_iorig] foo -wi-ao---- 1.00g [rr_rmeta_0] foo ewi-aor--- 4.00m [rr_rmeta_1] foo ewi-aor--- 4.00m
2019-11-21 01:07:27 +03:00
} else if (seg_is_integrity(lp)) {
if (!(create_segtype = get_segtype_from_string(vg->cmd, SEG_TYPE_NAME_STRIPED)))
return_0;
raid0: Add raid0 segment type. This remains experimental and quite restrictive so should only be used for testing at this stage. (E.g. lvreduce is not supported.)
2016-05-23 18:46:38 +03:00
} else if (seg_is_mirrored(lp) || (seg_is_raid(lp) && !seg_is_any_raid0(lp))) {
mirror: fix region_size for clustered VG When adjusting region size for clustered VG it always needs to fit 2 full bitset into 1MB due to old limits of CPG. This is relatively big amount of bits, but we have still limitation for region size to fit into 32bits (0x8000000). So for too big mirrors this operation needs to fail - so whenever function returns now 0, it means we can't find matching region_size. Since return 0 is now 'error' we need to also pass proper region_size when creating pvmove mirror.
2018-04-20 11:07:42 +03:00
if (!(lp->region_size = adjusted_mirror_region_size(vg->cmd,
vg->extent_size,
lp->extents,
lp->region_size, 0,
vg_is_clustered(vg))))
return_NULL;
pre-release
2014-11-11 17:13:00 +03:00
/* FIXME This will not pass cluster lock! */
lvcreate: new validation code Refactor lvcreate code. Prefer to use arg_outside_list_is_set() so we get automatic 'white-list' validation of supported options with different segment types. Drop used lp->cache, lp->cache and use seg_is_cache(), seg_is_thin() Draw clear border where is the last moment we could change create segment type. When segment type is given with --type - do not allow it to be changed later. Put together tests related to individual segment types. Finish cache conversion at proper part of lv_manip code after the vg_metadata are written - so we could correcly clean-up created stripe LV for cache volume.
2014-10-24 17:26:41 +04:00
init_mirror_in_sync(lp->nosync);
if (lp->nosync) {
cleanup: use spelling synchronize Use single spelling form for synchronize.
2023-07-02 17:41:34 +03:00
log_warn("WARNING: New %s won't be synchronized. "
lvcreate: new validation code Refactor lvcreate code. Prefer to use arg_outside_list_is_set() so we get automatic 'white-list' validation of supported options with different segment types. Drop used lp->cache, lp->cache and use seg_is_cache(), seg_is_thin() Draw clear border where is the last moment we could change create segment type. When segment type is given with --type - do not allow it to be changed later. Put together tests related to individual segment types. Finish cache conversion at proper part of lv_manip code after the vg_metadata are written - so we could correcly clean-up created stripe LV for cache volume.
2014-10-24 17:26:41 +04:00
"Don't read what you didn't write!",
lp->segtype->name);
status |= LV_NOTSYNCED;
coverity: error for undefined origin If we would have been missing origin here, it would be an internal error - since these values are validated earlier.
2014-05-07 13:14:22 +04:00
}
pools: prefetch pool_lv and origin_lv Load pool_lv and origin_lv at a single place and use it for more types as they need them.
2014-10-26 20:17:40 +03:00
} else if (pool_lv && seg_is_thin_volume(lp)) {
lvcreate: new validation code Refactor lvcreate code. Prefer to use arg_outside_list_is_set() so we get automatic 'white-list' validation of supported options with different segment types. Drop used lp->cache, lp->cache and use seg_is_cache(), seg_is_thin() Draw clear border where is the last moment we could change create segment type. When segment type is given with --type - do not allow it to be changed later. Put together tests related to individual segment types. Finish cache conversion at proper part of lv_manip code after the vg_metadata are written - so we could correcly clean-up created stripe LV for cache volume.
2014-10-24 17:26:41 +04:00
if (!lv_is_thin_pool(pool_lv)) {
log_error("Logical volume %s is not a thin pool.",
display_lvname(pool_lv));
lvcreate parsing for thin provisioning. The rest is incomplete so this isn't usable yet.
2011-09-06 04:26:42 +04:00
return NULL;
Move _lvcreate into the internal library and rename to lv_create_single. After some refactorings, we can now move the bulk of _lvcreate into the internal library, and we can call from liblvm. In the future, we should refactor lv_create_single further, probably by segtype, to reduce the size of struct lvcreate_params. For now this is a reasonable refactor and allows us to re-use the function from liblvm. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-07-26 06:33:35 +04:00
}
pools: prefetch pool_lv and origin_lv Load pool_lv and origin_lv at a single place and use it for more types as they need them.
2014-10-26 20:17:40 +03:00
if (origin_lv) {
lvcreate: new validation code Refactor lvcreate code. Prefer to use arg_outside_list_is_set() so we get automatic 'white-list' validation of supported options with different segment types. Drop used lp->cache, lp->cache and use seg_is_cache(), seg_is_thin() Draw clear border where is the last moment we could change create segment type. When segment type is given with --type - do not allow it to be changed later. Put together tests related to individual segment types. Finish cache conversion at proper part of lv_manip code after the vg_metadata are written - so we could correcly clean-up created stripe LV for cache volume.
2014-10-24 17:26:41 +04:00
if (lv_is_locked(origin_lv)) {
log_error("Snapshots of locked devices are not supported.");
return NULL;
}
cleanup: rename virtual_extents Use standard 'virtual_extents' naming. Move virtual_size into 'lcp' struct out of lvcreate_params.
2014-10-31 13:33:19 +03:00
lp->virtual_extents = origin_lv->le_count;
pools: prefetch pool_lv and origin_lv Load pool_lv and origin_lv at a single place and use it for more types as they need them.
2014-10-26 20:17:40 +03:00
/*
* Check if using 'external origin' or the 'normal' snapshot
* within the same thin pool
*/
if (first_seg(origin_lv)->pool_lv != pool_lv) {
thin: rename internal function Names matching internal code layout. Functionc in thin_manip.c uses thin_pool in its name. Keep 'pool' only for function working for both cache and thin pools. No change of functionality.
2022-08-24 16:02:07 +03:00
if (!thin_pool_supports_external_origin(first_seg(pool_lv), origin_lv))
pools: prefetch pool_lv and origin_lv Load pool_lv and origin_lv at a single place and use it for more types as they need them.
2014-10-26 20:17:40 +03:00
return_NULL;
if (origin_lv->status & LVM_WRITE) {
log_error("Cannot use writable LV as the external origin.");
pre-release
2014-11-11 17:13:00 +03:00
return NULL; /* FIXME conversion for inactive */
pools: prefetch pool_lv and origin_lv Load pool_lv and origin_lv at a single place and use it for more types as they need them.
2014-10-26 20:17:40 +03:00
}
if (lv_is_active(origin_lv) && !lv_is_external_origin(origin_lv)) {
log_error("Cannot use active LV for the external origin.");
pre-release
2014-11-11 17:13:00 +03:00
return NULL; /* We can't be sure device is read-only */
pools: prefetch pool_lv and origin_lv Load pool_lv and origin_lv at a single place and use it for more types as they need them.
2014-10-26 20:17:40 +03:00
}
}
lvcreate: new validation code Refactor lvcreate code. Prefer to use arg_outside_list_is_set() so we get automatic 'white-list' validation of supported options with different segment types. Drop used lp->cache, lp->cache and use seg_is_cache(), seg_is_thin() Draw clear border where is the last moment we could change create segment type. When segment type is given with --type - do not allow it to be changed later. Put together tests related to individual segment types. Finish cache conversion at proper part of lv_manip code after the vg_metadata are written - so we could correcly clean-up created stripe LV for cache volume.
2014-10-24 17:26:41 +04:00
}
} else if (lp->snapshot) {
cleanup: rename virtual_extents Use standard 'virtual_extents' naming. Move virtual_size into 'lcp' struct out of lvcreate_params.
2014-10-31 13:33:19 +03:00
if (!lp->virtual_extents) {
pools: prefetch pool_lv and origin_lv Load pool_lv and origin_lv at a single place and use it for more types as they need them.
2014-10-26 20:17:40 +03:00
if (!origin_lv) {
Move _lvcreate into the internal library and rename to lv_create_single. After some refactorings, we can now move the bulk of _lvcreate into the internal library, and we can call from liblvm. In the future, we should refactor lv_create_single further, probably by segtype, to reduce the size of struct lvcreate_params. For now this is a reasonable refactor and allows us to re-use the function from liblvm. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-07-26 06:33:35 +04:00
log_error("Couldn't find origin volume '%s'.",
cleanup: rename _name, _lv and _size Use some standard names for lv char * names, logical_volume * lv and sizes internally.
2014-10-07 12:43:47 +04:00
lp->origin_name);
lvcreate parsing for thin provisioning. The rest is incomplete so this isn't usable yet.
2011-09-06 04:26:42 +04:00
return NULL;
Move _lvcreate into the internal library and rename to lv_create_single. After some refactorings, we can now move the bulk of _lvcreate into the internal library, and we can call from liblvm. In the future, we should refactor lv_create_single further, probably by segtype, to reduce the size of struct lvcreate_params. For now this is a reasonable refactor and allows us to re-use the function from liblvm. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-07-26 06:33:35 +04:00
}
cleanup: rename _name, _lv and _size Use some standard names for lv char * names, logical_volume * lv and sizes internally.
2014-10-07 12:43:47 +04:00
if (lv_is_virtual_origin(origin_lv)) {
Move _lvcreate into the internal library and rename to lv_create_single. After some refactorings, we can now move the bulk of _lvcreate into the internal library, and we can call from liblvm. In the future, we should refactor lv_create_single further, probably by segtype, to reduce the size of struct lvcreate_params. For now this is a reasonable refactor and allows us to re-use the function from liblvm. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-07-26 06:33:35 +04:00
log_error("Can't share virtual origins. "
"Use --virtualsize.");
lvcreate parsing for thin provisioning. The rest is incomplete so this isn't usable yet.
2011-09-06 04:26:42 +04:00
return NULL;
Move _lvcreate into the internal library and rename to lv_create_single. After some refactorings, we can now move the bulk of _lvcreate into the internal library, and we can call from liblvm. In the future, we should refactor lv_create_single further, probably by segtype, to reduce the size of struct lvcreate_params. For now this is a reasonable refactor and allows us to re-use the function from liblvm. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-07-26 06:33:35 +04:00
}
snapshot: no snapshot of any cache type LVs Unsupported as of now.
2014-11-05 01:21:07 +03:00
snapshot: relocate common code validation for snapshot origin Since both lvcreate and lvconvert needs to check for same type of allowed origin for snapshot - move the code into a single function. This way we also fix several inconsitencies where snapshot has been allowed by mistake either through lvcreate or lvconvert path.
2017-10-27 17:48:57 +03:00
if (!validate_snapshot_origin(origin_lv))
return_0;
Move _lvcreate into the internal library and rename to lv_create_single. After some refactorings, we can now move the bulk of _lvcreate into the internal library, and we can call from liblvm. In the future, we should refactor lv_create_single further, probably by segtype, to reduce the size of struct lvcreate_params. For now this is a reasonable refactor and allows us to re-use the function from liblvm. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-07-26 06:33:35 +04:00
}
Thin test min thin_pool size for at least 1 chunk
2011-11-10 16:42:36 +04:00
lvcreate: new validation code Refactor lvcreate code. Prefer to use arg_outside_list_is_set() so we get automatic 'white-list' validation of supported options with different segment types. Drop used lp->cache, lp->cache and use seg_is_cache(), seg_is_thin() Draw clear border where is the last moment we could change create segment type. When segment type is given with --type - do not allow it to be changed later. Put together tests related to individual segment types. Finish cache conversion at proper part of lv_manip code after the vg_metadata are written - so we could correcly clean-up created stripe LV for cache volume.
2014-10-24 17:26:41 +04:00
if (!cow_has_min_chunks(vg, lp->extents, lp->chunk_size))
return_NULL;
Give correct error message when creating a too-small snapshot (BZ 587063)
2010-10-13 17:52:53 +04:00
lvcreate: new validation code Refactor lvcreate code. Prefer to use arg_outside_list_is_set() so we get automatic 'white-list' validation of supported options with different segment types. Drop used lp->cache, lp->cache and use seg_is_cache(), seg_is_thin() Draw clear border where is the last moment we could change create segment type. When segment type is given with --type - do not allow it to be changed later. Put together tests related to individual segment types. Finish cache conversion at proper part of lv_manip code after the vg_metadata are written - so we could correcly clean-up created stripe LV for cache volume.
2014-10-24 17:26:41 +04:00
/* The snapshot segment gets created later */
segtypes: Use SEG_TYPE_NAME_ string constants.
2015-09-22 21:04:12 +03:00
if (!(create_segtype = get_segtype_from_string(cmd, SEG_TYPE_NAME_STRIPED)))
lvcreate: new validation code Refactor lvcreate code. Prefer to use arg_outside_list_is_set() so we get automatic 'white-list' validation of supported options with different segment types. Drop used lp->cache, lp->cache and use seg_is_cache(), seg_is_thin() Draw clear border where is the last moment we could change create segment type. When segment type is given with --type - do not allow it to be changed later. Put together tests related to individual segment types. Finish cache conversion at proper part of lv_manip code after the vg_metadata are written - so we could correcly clean-up created stripe LV for cache volume.
2014-10-24 17:26:41 +04:00
return_NULL;
Move _lvcreate into the internal library and rename to lv_create_single. After some refactorings, we can now move the bulk of _lvcreate into the internal library, and we can call from liblvm. In the future, we should refactor lv_create_single further, probably by segtype, to reduce the size of struct lvcreate_params. For now this is a reasonable refactor and allows us to re-use the function from liblvm. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-07-26 06:33:35 +04:00
lvcreate: new validation code Refactor lvcreate code. Prefer to use arg_outside_list_is_set() so we get automatic 'white-list' validation of supported options with different segment types. Drop used lp->cache, lp->cache and use seg_is_cache(), seg_is_thin() Draw clear border where is the last moment we could change create segment type. When segment type is given with --type - do not allow it to be changed later. Put together tests related to individual segment types. Finish cache conversion at proper part of lv_manip code after the vg_metadata are written - so we could correcly clean-up created stripe LV for cache volume.
2014-10-24 17:26:41 +04:00
/* Must zero cow */
status |= LVM_WRITE;
lp->zero = 1;
lp->wipe_signatures = 0;
vdo: introduce segment types and manip functions Core functionality introducing lvm VDO support.
2018-06-29 12:11:14 +03:00
} else if (seg_is_vdo_pool(lp)) {
if (!lp->virtual_extents)
log_verbose("Virtual size matching available free logical size in VDO pool.");
if (!(create_segtype = get_segtype_from_string(vg->cmd, SEG_TYPE_NAME_STRIPED)))
return_NULL;
/* Must zero and format data area */
status |= LVM_WRITE;
lp->zero = 1;
Move _lvcreate into the internal library and rename to lv_create_single. After some refactorings, we can now move the bulk of _lvcreate into the internal library, and we can call from liblvm. In the future, we should refactor lv_create_single further, probably by segtype, to reduce the size of struct lvcreate_params. For now this is a reasonable refactor and allows us to re-use the function from liblvm. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-07-26 06:33:35 +04:00
}
lvcreate: check for lv type and created segtype When creating LV - in some case we change created segment type (ATM for cache and snapshot) and we then manipulate with lv segment according to 'lp' segtype. Fix this by checking for proper type before accessing segment members. This makes command like: lvcreate --type cache-pool -L10 vg/cpool lvcreate -H -L10 --cachesettings migtation_threshold=10000 vg/cpool to pass since now tool correctly selects default cache policy.
2016-04-27 16:02:54 +03:00
if (!segtype_is_virtual(create_segtype) && !lp->approx_alloc &&
lvcreate: delay check for free extents As the rounding for cache creation may change the value of extents postpone check for free extents.
2014-10-26 18:18:53 +03:00
(vg->free_count < lp->extents)) {
log_error("Volume group \"%s\" has insufficient free space "
"(%u extents): %u required.",
vg->name, vg->free_count, lp->extents);
return NULL;
}
lvcreate: check for lv type and created segtype When creating LV - in some case we change created segment type (ATM for cache and snapshot) and we then manipulate with lv segment according to 'lp' segtype. Fix this by checking for proper type before accessing segment members. This makes command like: lvcreate --type cache-pool -L10 vg/cpool lvcreate -H -L10 --cachesettings migtation_threshold=10000 vg/cpool to pass since now tool correctly selects default cache policy.
2016-04-27 16:02:54 +03:00
if (pool_lv && segtype_is_thin_volume(create_segtype)) {
Thin using update_pool_lv Replace detach_pool_messages with update_pool_lv. Move creation code from to 'if' condition into 1. Ensure creation has finished all previous message operations.
2011-11-03 18:56:20 +04:00
/* Ensure all stacked messages are submitted */
thin: rename internal function Names matching internal code layout. Functionc in thin_manip.c uses thin_pool in its name. Keep 'pool' only for function working for both cache and thin pools. No change of functionality.
2022-08-24 16:02:07 +03:00
if ((thin_pool_is_active(pool_lv) || is_change_activating(lp->activate)) &&
!update_thin_pool_lv(pool_lv, 1))
cleanup: use is_change_activating Use a single inline function to detect activation/deactivation
2014-02-18 23:52:17 +04:00
return_NULL;
Move _lvcreate into the internal library and rename to lv_create_single. After some refactorings, we can now move the bulk of _lvcreate into the internal library, and we can call from liblvm. In the future, we should refactor lv_create_single further, probably by segtype, to reduce the size of struct lvcreate_params. For now this is a reasonable refactor and allows us to re-use the function from liblvm. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-07-26 06:33:35 +04:00
}
lvcreate parsing for thin provisioning. The rest is incomplete so this isn't usable yet.
2011-09-06 04:26:42 +04:00
if (!(lv = lv_create_empty(new_lv_name ? : "lvol%d", NULL,
Move _lvcreate into the internal library and rename to lv_create_single. After some refactorings, we can now move the bulk of _lvcreate into the internal library, and we can call from liblvm. In the future, we should refactor lv_create_single further, probably by segtype, to reduce the size of struct lvcreate_params. For now this is a reasonable refactor and allows us to re-use the function from liblvm. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-07-26 06:33:35 +04:00
status, lp->alloc, vg)))
lvcreate parsing for thin provisioning. The rest is incomplete so this isn't usable yet.
2011-09-06 04:26:42 +04:00
return_NULL;
Move _lvcreate into the internal library and rename to lv_create_single. After some refactorings, we can now move the bulk of _lvcreate into the internal library, and we can call from liblvm. In the future, we should refactor lv_create_single further, probably by segtype, to reduce the size of struct lvcreate_params. For now this is a reasonable refactor and allows us to re-use the function from liblvm. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-07-26 06:33:35 +04:00
Fix setting of readahead in lvcreate. The default comes from the configuration settings, with possible commandline override.
2009-12-03 04:47:33 +03:00
if (lp->read_ahead != lv->read_ahead) {
Move _lvcreate into the internal library and rename to lv_create_single. After some refactorings, we can now move the bulk of _lvcreate into the internal library, and we can call from liblvm. In the future, we should refactor lv_create_single further, probably by segtype, to reduce the size of struct lvcreate_params. For now this is a reasonable refactor and allows us to re-use the function from liblvm. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-07-26 06:33:35 +04:00
lv->read_ahead = lp->read_ahead;
cleanup: indent Various indents and tiny error message improvements.
2014-10-18 13:01:29 +04:00
log_debug_metadata("Setting read ahead sectors %u.", lv->read_ahead);
Move _lvcreate into the internal library and rename to lv_create_single. After some refactorings, we can now move the bulk of _lvcreate into the internal library, and we can call from liblvm. In the future, we should refactor lv_create_single further, probably by segtype, to reduce the size of struct lvcreate_params. For now this is a reasonable refactor and allows us to re-use the function from liblvm. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-07-26 06:33:35 +04:00
}
vdo: introduce segment types and manip functions Core functionality introducing lvm VDO support.
2018-06-29 12:11:14 +03:00
if (!segtype_is_pool(create_segtype) &&
!segtype_is_vdo_pool(create_segtype) &&
lp->minor >= 0) {
Move _lvcreate into the internal library and rename to lv_create_single. After some refactorings, we can now move the bulk of _lvcreate into the internal library, and we can call from liblvm. In the future, we should refactor lv_create_single further, probably by segtype, to reduce the size of struct lvcreate_params. For now this is a reasonable refactor and allows us to re-use the function from liblvm. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-07-26 06:33:35 +04:00
lv->major = lp->major;
lv->minor = lp->minor;
lv->status |= FIXED_MINOR;
cleanup: indent Various indents and tiny error message improvements.
2014-10-18 13:01:29 +04:00
log_debug_metadata("Setting device number to (%d, %d).",
lv->major, lv->minor);
Move _lvcreate into the internal library and rename to lv_create_single. After some refactorings, we can now move the bulk of _lvcreate into the internal library, and we can call from liblvm. In the future, we should refactor lv_create_single further, probably by segtype, to reduce the size of struct lvcreate_params. For now this is a reasonable refactor and allows us to re-use the function from liblvm. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-07-26 06:33:35 +04:00
}
Add lvmlockd
2015-03-05 23:00:44 +03:00
/*
* The specific LV may not use a lock. lockd_init_lv() sets
* lv->lock_args to NULL if this LV does not use its own lock.
*/
if (!lockd_init_lv(vg->cmd, vg, lv, lp))
return_NULL;
Remove extra empty check dm_list_splice handles empty list itself, no need to duplicate code.
2011-10-22 20:46:34 +04:00
dm_list_splice(&lv->tags, &lp->tags);
Move _lvcreate into the internal library and rename to lv_create_single. After some refactorings, we can now move the bulk of _lvcreate into the internal library, and we can call from liblvm. In the future, we should refactor lv_create_single further, probably by segtype, to reduce the size of struct lvcreate_params. For now this is a reasonable refactor and allows us to re-use the function from liblvm. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-07-26 06:33:35 +04:00
lvcreate: new validation code Refactor lvcreate code. Prefer to use arg_outside_list_is_set() so we get automatic 'white-list' validation of supported options with different segment types. Drop used lp->cache, lp->cache and use seg_is_cache(), seg_is_thin() Draw clear border where is the last moment we could change create segment type. When segment type is given with --type - do not allow it to be changed later. Put together tests related to individual segment types. Finish cache conversion at proper part of lv_manip code after the vg_metadata are written - so we could correcly clean-up created stripe LV for cache volume.
2014-10-24 17:26:41 +04:00
if (!lv_extend(lv, create_segtype,
Add basic RAID segment type(s) support. Implementation described in doc/lvm2-raid.txt. Basic support includes: - ability to create RAID 1/4/5/6 arrays - ability to delete RAID arrays - ability to display RAID arrays Notable missing features (not included in this patch): - ability to clean-up/repair failures - ability to convert RAID segment types - ability to monitor RAID segment types
2011-08-03 02:07:20 +04:00
lp->stripes, lp->stripe_size,
Thin supports poolmetadatasize setting Add option to set pool metadatasize. For passing size parameter reuse region_size.
2011-11-05 02:43:10 +04:00
lp->mirrors,
lvcreate: check for lv type and created segtype When creating LV - in some case we change created segment type (ATM for cache and snapshot) and we then manipulate with lv segment according to 'lp' segtype. Fix this by checking for proper type before accessing segment members. This makes command like: lvcreate --type cache-pool -L10 vg/cpool lvcreate -H -L10 --cachesettings migtation_threshold=10000 vg/cpool to pass since now tool correctly selects default cache policy.
2016-04-27 16:02:54 +03:00
segtype_is_pool(create_segtype) ? lp->pool_metadata_extents : lp->region_size,
vdo: introduce segment types and manip functions Core functionality introducing lvm VDO support.
2018-06-29 12:11:14 +03:00
(segtype_is_thin_volume(create_segtype) ||
segtype_is_vdo(create_segtype)) ? lp->virtual_extents : lp->extents,
lvreduce: check LV has segment Before accessing content make sure LV has segment. This can be used in case code removes LV without segments (i.e. on some error path)
2017-10-30 16:35:31 +03:00
lp->pvh, lp->alloc, lp->approx_alloc)) {
unlink_lv_from_vg(lv); /* Keep VG consistent and remove LV without any segment */
lvcreate parsing for thin provisioning. The rest is incomplete so this isn't usable yet.
2011-09-06 04:26:42 +04:00
return_NULL;
lvreduce: check LV has segment Before accessing content make sure LV has segment. This can be used in case code removes LV without segments (i.e. on some error path)
2017-10-30 16:35:31 +03:00
}
lvcreate parsing for thin provisioning. The rest is incomplete so this isn't usable yet.
2011-09-06 04:26:42 +04:00
lvcreate: allow 100%FREE creation of "--type mirror" to work Fixes the following case with 3PVs and 3 legs "mirror" LV: # lvcreate -l100%FREE --type mirror -m2 vg3 Insufficient free space for log allocation for logical volume . Unable to allocate extents for mirror log. Related: rhbz1269533
2017-10-12 18:43:24 +03:00
/* rhbz1269533: allow for 100%FREE allocation to work with "mirror" and a disk log */
if (segtype_is_mirror(create_segtype) &&
lp->log_count &&
!vg->free_count &&
lv->le_count > 1)
lv_reduce(lv, 1);
memlock: drop uneeded lock Avoid doing buffered operation within memory lock.
2014-09-19 03:09:36 +04:00
/* Unlock memory if possible */
memlock_unlock(vg->cmd);
cleanup: simplier check first
2021-03-17 10:56:23 +03:00
if (pool_lv && segtype_is_vdo(create_segtype))
vdo: introduce segment types and manip functions Core functionality introducing lvm VDO support.
2018-06-29 12:11:14 +03:00
if (!set_lv_segment_area_lv(first_seg(lv), 0, pool_lv, 0, LV_VDO_POOL))
return_NULL;
lvcreate: improve --chunksize support for cached volume. Support parsing --chunksize option also when converting. Now user can use cache pool created with i.e. 32K chunksize, while in caching user can select 512K blocks. Tool is supposed to validate cache metadata size is big enough to support such chunk size. Otherwise error is shown.
2016-05-05 22:34:21 +03:00
if (lv_is_cache_pool(lv)) {
if (!cache_set_params(first_seg(lv),
cache: set chunk_size as first param
2017-03-09 17:54:30 +03:00
lp->chunk_size,
cache: enable usage of --cachemetadataformat lvcreate and lvconvert may select cache metadata format when caching LV. By default lvm2 picks best available format.
2017-02-26 22:18:37 +03:00
lp->cache_metadata_format,
lvcreate: improve --chunksize support for cached volume. Support parsing --chunksize option also when converting. Now user can use cache pool created with i.e. 32K chunksize, while in caching user can select 512K blocks. Tool is supposed to validate cache metadata size is big enough to support such chunk size. Otherwise error is shown.
2016-05-05 22:34:21 +03:00
lp->cache_mode,
lp->policy_name,
cache: set chunk_size as first param
2017-03-09 17:54:30 +03:00
lp->policy_settings)) {
pools: error path removes metadata When pool volume is create - it has already managed to update metadata once within lv_extend - so revert new created LV here.
2014-10-24 17:21:48 +04:00
stack;
goto revert_new_lv;
}
raid0: Add raid0 segment type. This remains experimental and quite restrictive so should only be used for testing at this stage. (E.g. lvreduce is not supported.)
2016-05-23 18:46:38 +03:00
} else if (lv_is_raid(lv) && !seg_is_any_raid0(first_seg(lv))) {
cleanup: move code
2014-10-18 13:01:34 +04:00
first_seg(lv)->min_recovery_rate = lp->min_recovery_rate;
first_seg(lv)->max_recovery_rate = lp->max_recovery_rate;
lvcreate: check for lv type and created segtype When creating LV - in some case we change created segment type (ATM for cache and snapshot) and we then manipulate with lv segment according to 'lp' segtype. Fix this by checking for proper type before accessing segment members. This makes command like: lvcreate --type cache-pool -L10 vg/cpool lvcreate -H -L10 --cachesettings migtation_threshold=10000 vg/cpool to pass since now tool correctly selects default cache policy.
2016-04-27 16:02:54 +03:00
} else if (lv_is_thin_pool(lv)) {
thin and cache: unify pool common code Fix get_pool_params to only read params. Add poolmetadataspare option to get_pool_params. Move all profile code into update_pool_params. Move recalculate code into pool_manip.c
2014-07-23 00:20:18 +04:00
first_seg(lv)->chunk_size = lp->chunk_size;
thin: add new ZERO/DISCARDS_UNSELECTED To more easily recognize unselected state from select '0' state add new 'THIN_ZERO_UNSELECTED' enum. Same applies to THIN_DISCARDS_UNSELECTED. For those we no longer need to use PASS_ARG_ZERO or PASS_ARG_DISCARDS.
2017-03-03 22:46:13 +03:00
first_seg(lv)->zero_new_blocks = lp->zero_new_blocks;
thin: lvcreate --discards
2012-08-09 14:20:47 +04:00
first_seg(lv)->discards = lp->discards;
thin: improve 16g support for thin pool metadata Initial support for thin-pool used slightly smaller max size 15.81GiB for thin-pool metadata. However the real limit later settled at 15.88GiB (difference is ~64MiB - 16448 4K blocks). lvm2 could not simply increase the size as it has been using hard cropping of the loaded metadata device to avoid warnings printing warning of kernel when the size was bigger (i.e. due to bigger extent_size). This patch adds the new lvm.conf configurable setting: allocation/thin_pool_crop_metadata which defaults to 0 -> no crop of metadata beyond 15.81GiB. Only user with these sizes of metadata will be affected. Without cropping lvm2 now limits metadata allocation size to 15.88GiB. Any space beyond is currently not used by thin-pool target. Even if i.e. bigger LV is used for metadata via lvconvert, or allocated bigger because of to large extent size. With cropping enabled (=1) lvm2 preserves the old limitation 15.81GiB and should allow to work in the evironement with older lvm2 tools (i.e. older distribution). Thin-pool metadata with size bigger then 15.81G is now using CROP_METADATA flag within lvm2 metadata, so older lvm2 recognizes an incompatible thin-pool and cannot activate such pool! Users should use uncropped version as it is not suffering from various issues between thin_repair results and allocated metadata LV as thin_repair limit is 15.88GiB Users should use cropping only when really needed! Patch also better handles resize of thin-pool metadata and prevents resize beoyond usable size 15.88GiB. Resize beyond 15.81GiB automatically switches pool to no-crop version. Even with existing bigger thin-pool metadata command 'lvextend -l+1 vg/pool_tmeta' does the change. Patch gives better controls 'coverted' metadata LV and reports less confusing message during conversion. Patch set also moves the code for updating min/max into pool_manip.c for better sharing with cache_pool code.
2021-01-12 19:59:29 +03:00
if ((first_seg(lv)->crop_metadata = lp->crop_metadata) == THIN_CROP_METADATA_NO)
lv->status |= LV_CROP_METADATA;
pool: support passing data_lv for recalculation Support data_lv to be passed as parameter when it's not yet attached to the pool.
2023-07-02 12:21:15 +03:00
if (!recalculate_pool_chunk_size_with_dev_hints(lv, seg_lv(first_seg(lv), 0),
lp->thin_chunk_size_calc_policy)) {
pools: error path removes metadata When pool volume is create - it has already managed to update metadata once within lv_extend - so revert new created LV here.
2014-10-24 17:21:48 +04:00
stack;
goto revert_new_lv;
}
thin: errrorwhenfull support Support error_if_no_space feature for thin pools. Report more info about thinpool status: (out_of_data (D), metadata_read_only (M), failed (F) also as health attribute.)
2015-01-13 17:23:03 +03:00
if (lp->error_when_full)
lv->status |= LV_ERROR_WHEN_FULL;
thin: add extra protection Check explicitely created LV already has thin segment. As currenlty it's the only user - this patch should have no impact.
2021-03-17 11:13:20 +03:00
} else if (pool_lv && lv_is_virtual(lv) && /* not yet thin LV */
(seg = first_seg(lv)) &&
seg_is_thin(seg)) { /* going to be a thin volume */
thin: simplify thin volume creation Move code for creation of thin volume into a single place out of lv_extend(). This allows to drop extra pool arg for alloc_lv_segment() && lv_extend() and makes code more easier to read and follow.
2014-10-26 10:13:59 +03:00
pool_seg = first_seg(pool_lv);
thin: rename internal function Names matching internal code layout. Functionc in thin_manip.c uses thin_pool in its name. Keep 'pool' only for function working for both cache and thin pools. No change of functionality.
2022-08-24 16:02:07 +03:00
if (!(seg->device_id = get_free_thin_pool_device_id(pool_seg)))
thin: fix error path in creation path Remove some calls to revert_new_lv when no LV has been created/commited so far. When the pool update failed - then only revert is needed.
2013-07-17 17:26:41 +04:00
return_NULL;
thin: simplify thin volume creation Move code for creation of thin volume into a single place out of lv_extend(). This allows to drop extra pool arg for alloc_lv_segment() && lv_extend() and makes code more easier to read and follow.
2014-10-26 10:13:59 +03:00
seg->transaction_id = pool_seg->transaction_id;
if (origin_lv && lv_is_thin_volume(origin_lv) &&
(first_seg(origin_lv)->pool_lv == pool_lv)) {
/* For thin snapshot pool must match */
metadata: add support for interconnection of thin pool LV segment with indirect origin Add support for making an interconnection between thin LV segment and its indirect origin (which may be historical or live LV) - add a new "indirect_origin" argument to attach_pool_lv function.
2016-03-01 17:21:36 +03:00
if (!attach_pool_lv(seg, pool_lv, origin_lv, NULL, NULL))
thin: simplify thin volume creation Move code for creation of thin volume into a single place out of lv_extend(). This allows to drop extra pool arg for alloc_lv_segment() && lv_extend() and makes code more easier to read and follow.
2014-10-26 10:13:59 +03:00
return_NULL;
/* Use the same external origin */
if (!attach_thin_external_origin(seg, first_seg(origin_lv)->external_lv))
return_NULL;
} else {
metadata: add support for interconnection of thin pool LV segment with indirect origin Add support for making an interconnection between thin LV segment and its indirect origin (which may be historical or live LV) - add a new "indirect_origin" argument to attach_pool_lv function.
2016-03-01 17:21:36 +03:00
if (!attach_pool_lv(seg, pool_lv, NULL, NULL, NULL))
thin: simplify thin volume creation Move code for creation of thin volume into a single place out of lv_extend(). This allows to drop extra pool arg for alloc_lv_segment() && lv_extend() and makes code more easier to read and follow.
2014-10-26 10:13:59 +03:00
return_NULL;
/* If there is an external origin... */
if (!attach_thin_external_origin(seg, origin_lv))
thin: fix error path in creation path Remove some calls to revert_new_lv when no LV has been created/commited so far. When the pool update failed - then only revert is needed.
2013-07-17 17:26:41 +04:00
return_NULL;
thin: lvcreate external origin snapshot support
2013-04-02 16:53:58 +04:00
}
Add code to activate thin target Code to zero pool metadata lv when pool is created. Add code to create thin target via message sending. (Revert is missing)
2011-10-03 22:43:39 +04:00
thin: rename internal function Names matching internal code layout. Functionc in thin_manip.c uses thin_pool in its name. Keep 'pool' only for function working for both cache and thin pools. No change of functionality.
2022-08-24 16:02:07 +03:00
if (!attach_thin_pool_message(pool_seg, DM_THIN_MESSAGE_CREATE_THIN, lv, 0, 0))
thin: fix error path in creation path Remove some calls to revert_new_lv when no LV has been created/commited so far. When the pool update failed - then only revert is needed.
2013-07-17 17:26:41 +04:00
return_NULL;
Add code to activate thin target Code to zero pool metadata lv when pool is created. Add code to create thin target via message sending. (Revert is missing)
2011-10-03 22:43:39 +04:00
}
Move _lvcreate into the internal library and rename to lv_create_single. After some refactorings, we can now move the bulk of _lvcreate into the internal library, and we can call from liblvm. In the future, we should refactor lv_create_single further, probably by segtype, to reduce the size of struct lvcreate_params. For now this is a reasonable refactor and allows us to re-use the function from liblvm. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-07-26 06:33:35 +04:00
thin: rename internal function Names matching internal code layout. Functionc in thin_manip.c uses thin_pool in its name. Keep 'pool' only for function working for both cache and thin pools. No change of functionality.
2022-08-24 16:02:07 +03:00
if (!thin_pool_check_overprovisioning(lv))
thin: check for overprovisioning
2015-07-03 16:31:31 +03:00
return_NULL;
Track unreserved space for all alloc policies and then permit NORMAL to place log and data on same single PV.
2012-02-01 06:10:45 +04:00
/* FIXME Log allocation and attachment should have happened inside lv_extend. */
mirror: checking for mirror segtype Checking more correctly for mirror segtype here instead of mirrored one which can be also 'raid'.
2018-04-20 11:01:28 +03:00
if (lp->log_count && segtype_is_mirror(create_segtype)) {
This patch adds the ability to extend 0 length layered LVs. This allows us to allocate all images of a mirror (or RAID array) at one time during create. The current mirror implementation still requires a separate allocation for the log, however.
2011-04-07 01:32:20 +04:00
if (!add_mirror_log(cmd, lv, lp->log_count,
first_seg(lv)->region_size,
lp->pvh, lp->alloc)) {
Move _lvcreate into the internal library and rename to lv_create_single. After some refactorings, we can now move the bulk of _lvcreate into the internal library, and we can call from liblvm. In the future, we should refactor lv_create_single further, probably by segtype, to reduce the size of struct lvcreate_params. For now this is a reasonable refactor and allows us to re-use the function from liblvm. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-07-26 06:33:35 +04:00
stack;
goto revert_new_lv;
}
}
activation: add support for skipping activation of selected LVs Also add -k/--setactivationskip y/n and -K/--ignoreactivationskip options to lvcreate. The --setactivationskip y sets the flag in metadata for an LV to skip the LV during activation. Also, the newly created LV is not activated. Thin snapsots have this flag set automatically if not specified directly by the --setactivationskip y/n option. The --ignoreactivationskip overrides the activation skip flag set in metadata for an LV (just for the run of the command - the flag is not changed in metadata!) A few examples for the lvcreate with the new options: (non-thin snap LV => skip flag not set in MDA + LV activated) raw/~ $ lvcreate -l1 vg Logical volume "lvol0" created raw/~ $ lvs -o lv_name,attr vg/lvol0 LV Attr lvol0 -wi-a---- (non-thin snap LV + -ky => skip flag set in MDA + LV not activated) raw/~ $ lvcreate -l1 -ky vg Logical volume "lvol1" created raw/~ $ lvs -o lv_name,attr vg/lvol1 LV Attr lvol1 -wi------ (non-thin snap LV + -ky + -K => skip flag set in MDA + LV activated) raw/~ $ lvcreate -l1 -ky -K vg Logical volume "lvol2" created raw/~ $ lvs -o lv_name,attr vg/lvol2 LV Attr lvol2 -wi-a---- (thin snap LV => skip flag set in MDA (default behaviour) + LV not activated) raw/~ $ lvcreate -L100M -T vg/pool -V 1T -n thin_lv Logical volume "thin_lv" created raw/~ $ lvcreate -s vg/thin_lv -n thin_snap Logical volume "thin_snap" created raw/~ $ lvs -o name,attr vg LV Attr pool twi-a-tz- thin_lv Vwi-a-tz- thin_snap Vwi---tz- (thin snap LV + -K => skip flag set in MDA (default behaviour) + LV activated) raw/~ $ lvcreate -s vg/thin_lv -n thin_snap -K Logical volume "thin_snap" created raw/~ $ lvs -o name,attr vg/thin_lv LV Attr thin_lv Vwi-a-tz- (thins snap LV + -kn => no skip flag in MDA (default behaviour overridden) + LV activated) [0] raw/~ # lvcreate -s vg/thin_lv -n thin_snap -kn Logical volume "thin_snap" created [0] raw/~ # lvs -o name,attr vg/thin_snap LV Attr thin_snap Vwi-a-tz-
2013-07-10 16:06:50 +04:00
lv_set_activation_skip(lv, lp->activation_skip & ACTIVATION_SKIP_SET,
lp->activation_skip & ACTIVATION_SKIP_SET_ENABLED);
Add metadata-based autoactivation property for VG and LV The autoactivation property can be specified in lvcreate or vgcreate for new LVs/VGs, and the property can be changed by lvchange or vgchange for existing LVs/VGs. --setautoactivation y|n enables|disables autoactivation of a VG or LV. Autoactivation is enabled by default, which is consistent with past behavior. The disabled state is stored as a new flag in the VG metadata, and the absence of the flag allows autoactivation. If autoactivation is disabled for the VG, then no LVs in the VG will be autoactivated (the LV autoactivation property will have no effect.) When autoactivation is enabled for the VG, then autoactivation can be controlled on individual LVs. The state of this property can be reported for LVs/VGs using the "-o autoactivation" option in lvs/vgs commands, which will report "enabled", or "" for the disabled state. Previous versions of lvm do not recognize this property. Since autoactivation is enabled by default, the disabled setting will have no effect in older lvm versions. If the VG is modified by older lvm versions, the disabled state will also be dropped from the metadata. The autoactivation property is an alternative to using the lvm.conf auto_activation_volume_list, which is still applied to to VGs/LVs in addition to the new property. If VG or LV autoactivation is disabled either in metadata or in auto_activation_volume_list, it will not be autoactivated. An autoactivation command will silently skip activating an LV when the autoactivation property is disabled. To determine the effective autoactivation behavior for a specific LV, multiple settings would need to be checked: the VG autoactivation property, the LV autoactivation property, the auto_activation_volume_list. The "activation skip" property would also be relevant, since it applies to both normal and auto activation.
2021-04-02 01:20:00 +03:00
if (lp->noautoactivate)
lv->status |= LV_NOAUTOACTIVATE;
lvcreate: add --activate ay (autoactivate) One can use "lvcreate --aay" to have the newly created volume activated or not activated based on the activation/auto_activation_volume_list this way. Note: -Z/--zero is not compatible with -aay, zeroing is not used in this case! When using lvcreate -aay, a default warning message is also issued that zeroing is not done.
2012-06-28 12:15:07 +04:00
/*
* Check for autoactivation.
* If the LV passes the auto activation filter, activate
* it just as if CHANGE_AY was used, CHANGE_AN otherwise.
*/
if (lp->activate == CHANGE_AAY)
cleanup: indent Various indents and tiny error message improvements.
2014-10-18 13:01:29 +04:00
lp->activate = lv_passes_auto_activation_filter(cmd, lv)
? CHANGE_ALY : CHANGE_ALN;
lvcreate: add --activate ay (autoactivate) One can use "lvcreate --aay" to have the newly created volume activated or not activated based on the activation/auto_activation_volume_list this way. Note: -Z/--zero is not compatible with -aay, zeroing is not used in this case! When using lvcreate -aay, a default warning message is also issued that zeroing is not done.
2012-06-28 12:15:07 +04:00
activation: lv_activation_skip remove always same arg. Remove 'skip' argument passed into the function. We always used '0' - as this is the only supported option (-K) and there is no complementary option. Also add some testing for behaviour of skipping.
2014-02-19 14:02:16 +04:00
if (lv_activation_skip(lv, lp->activate, lp->activation_skip & ACTIVATION_SKIP_IGNORE))
activation: add support for skipping activation of selected LVs Also add -k/--setactivationskip y/n and -K/--ignoreactivationskip options to lvcreate. The --setactivationskip y sets the flag in metadata for an LV to skip the LV during activation. Also, the newly created LV is not activated. Thin snapsots have this flag set automatically if not specified directly by the --setactivationskip y/n option. The --ignoreactivationskip overrides the activation skip flag set in metadata for an LV (just for the run of the command - the flag is not changed in metadata!) A few examples for the lvcreate with the new options: (non-thin snap LV => skip flag not set in MDA + LV activated) raw/~ $ lvcreate -l1 vg Logical volume "lvol0" created raw/~ $ lvs -o lv_name,attr vg/lvol0 LV Attr lvol0 -wi-a---- (non-thin snap LV + -ky => skip flag set in MDA + LV not activated) raw/~ $ lvcreate -l1 -ky vg Logical volume "lvol1" created raw/~ $ lvs -o lv_name,attr vg/lvol1 LV Attr lvol1 -wi------ (non-thin snap LV + -ky + -K => skip flag set in MDA + LV activated) raw/~ $ lvcreate -l1 -ky -K vg Logical volume "lvol2" created raw/~ $ lvs -o lv_name,attr vg/lvol2 LV Attr lvol2 -wi-a---- (thin snap LV => skip flag set in MDA (default behaviour) + LV not activated) raw/~ $ lvcreate -L100M -T vg/pool -V 1T -n thin_lv Logical volume "thin_lv" created raw/~ $ lvcreate -s vg/thin_lv -n thin_snap Logical volume "thin_snap" created raw/~ $ lvs -o name,attr vg LV Attr pool twi-a-tz- thin_lv Vwi-a-tz- thin_snap Vwi---tz- (thin snap LV + -K => skip flag set in MDA (default behaviour) + LV activated) raw/~ $ lvcreate -s vg/thin_lv -n thin_snap -K Logical volume "thin_snap" created raw/~ $ lvs -o name,attr vg/thin_lv LV Attr thin_lv Vwi-a-tz- (thins snap LV + -kn => no skip flag in MDA (default behaviour overridden) + LV activated) [0] raw/~ # lvcreate -s vg/thin_lv -n thin_snap -kn Logical volume "thin_snap" created [0] raw/~ # lvs -o name,attr vg/thin_snap LV Attr thin_snap Vwi-a-tz-
2013-07-10 16:06:50 +04:00
lp->activate = CHANGE_AN;
cleanup: move detection of change mode before commit point Following patch will need to know change state before commit point. Also the test mode should properly report all ongoing operation.
2013-07-18 18:25:16 +04:00
/* store vg on disk(s) */
pools: after fail of vg_write no restore Revert part of commit 51a29e60564d537, it's probably bad idea to continue with any recovery, when vg_write() or vg_commit() fail - so it's better to leave it as it is.
2014-11-05 22:27:51 +03:00
if (!vg_write(vg) || !vg_commit(vg))
/* Pool created metadata LV, but better avoid recover when vg_write/commit fails */
cleanup: move detection of change mode before commit point Following patch will need to know change state before commit point. Also the test mode should properly report all ongoing operation.
2013-07-18 18:25:16 +04:00
return_NULL;
if (test_mode()) {
lv_manip: rename set_lv -> wipe_lv and include signature wiping capability Use common wipe_lv (former set_lv) fn to do zeroing as well as signature wiping if needed. Provide new struct wipe_lv_params to define the functionality. Bind "lvcreate -W/--wipesignatures y" with proper wipe_lv call. Also, add "yes" and "force" to lvcreate_params so it's possible to apply them for the prompt: "WARNING: %s detected on %s. Wipe it? [y/n]".
2013-11-06 19:16:34 +04:00
log_verbose("Test mode: Skipping activation, zeroing and signature wiping.");
cleanup: move detection of change mode before commit point Following patch will need to know change state before commit point. Also the test mode should properly report all ongoing operation.
2013-07-18 18:25:16 +04:00
goto out;
cache: never activate cache pool Since cache-pool is purely lvm abstraction layer LV, it never need any device node, so do not add even 'error' device for it.
2014-04-01 19:53:18 +04:00
}
Allow dm-integrity to be used for raid images dm-integrity stores checksums of the data written to an LV, and returns an error if data read from the LV does not match the previously saved checksum. When used on raid images, dm-raid will correct the error by reading the block from another image, and the device user sees no error. The integrity metadata (checksums) are stored on an internal LV allocated by lvm for each linear image. The internal LV is allocated on the same PV as the image. Create a raid LV with an integrity layer over each raid image (for raid levels 1,4,5,6,10): lvcreate --type raidN --raidintegrity y [options] Add an integrity layer to images of an existing raid LV: lvconvert --raidintegrity y LV Remove the integrity layer from images of a raid LV: lvconvert --raidintegrity n LV Settings Use --raidintegritymode journal|bitmap (journal is default) to configure the method used by dm-integrity to ensure crash consistency. Initialization When integrity is added to an LV, the kernel needs to initialize the integrity metadata/checksums for all blocks in the LV. The data corruption checking performed by dm-integrity will only operate on areas of the LV that are already initialized. The progress of integrity initialization is reported by the "syncpercent" LV reporting field (and under the Cpy%Sync lvs column.) Example: create a raid1 LV with integrity: $ lvcreate --type raid1 -m1 --raidintegrity y -n rr -L1G foo Creating integrity metadata LV rr_rimage_0_imeta with size 12.00 MiB. Logical volume "rr_rimage_0_imeta" created. Creating integrity metadata LV rr_rimage_1_imeta with size 12.00 MiB. Logical volume "rr_rimage_1_imeta" created. Logical volume "rr" created. $ lvs -a foo LV VG Attr LSize Origin Cpy%Sync rr foo rwi-a-r--- 1.00g 4.93 [rr_rimage_0] foo gwi-aor--- 1.00g [rr_rimage_0_iorig] 41.02 [rr_rimage_0_imeta] foo ewi-ao---- 12.00m [rr_rimage_0_iorig] foo -wi-ao---- 1.00g [rr_rimage_1] foo gwi-aor--- 1.00g [rr_rimage_1_iorig] 39.45 [rr_rimage_1_imeta] foo ewi-ao---- 12.00m [rr_rimage_1_iorig] foo -wi-ao---- 1.00g [rr_rmeta_0] foo ewi-aor--- 4.00m [rr_rmeta_1] foo ewi-aor--- 4.00m
2019-11-21 01:07:27 +03:00
if (seg_is_raid(lp) && lp->raidintegrity) {
log_debug("Adding integrity to new LV");
if (!lv_add_integrity_to_raid(lv, &lp->integrity_settings, lp->pvh, NULL))
goto revert_new_lv;
}
lv_manip: rename set_lv -> wipe_lv and include signature wiping capability Use common wipe_lv (former set_lv) fn to do zeroing as well as signature wiping if needed. Provide new struct wipe_lv_params to define the functionality. Bind "lvcreate -W/--wipesignatures y" with proper wipe_lv call. Also, add "yes" and "force" to lvcreate_params so it's possible to apply them for the prompt: "WARNING: %s detected on %s. Wipe it? [y/n]".
2013-11-06 19:16:34 +04:00
/* Do not scan this LV until properly zeroed/wiped. */
lv_manip: improve should_wipe reporting We want to print smarter warning message only when the zeroing was not provided on the first zeroable segment of newly created LV. Put warning within _should_wipe_lv function to avoid reevaluation of same conditions twice.
2014-10-22 15:29:25 +04:00
if (_should_wipe_lv(lp, lv, 0))
activation: add support for flagging an LV to skip udev scanning during activation A common scenario is during new LV creation when we need to wipe the newly created LV and avoid any udev scanning before this stage otherwise it could cause the device (the LV) to be claimed by some other subsystem for which there were stale metadata within LV data. This patch adds possibility to mark the LV we're just about to wipe with a flag that gets passed to udev via DM_COOKIE as a subsystem specific flag - DM_SUBSYSTEM_UDEV_FLAG0 (in this case the subsystem is "LVM") so LVM udev rules will take care of handling that.
2013-10-08 15:27:21 +04:00
lv->status |= LV_NOSCAN;
activation: flag temporary LVs internally Add LV_TEMPORARY flag for LVs with limited existence during command execution. Such LVs are temporary in way that they need to be activated, some action done and then removed immediately. Such LVs are just like any normal LV - the only difference is that they are removed during LVM command execution. This is also the case for LVs representing future pool metadata spare LVs which we need to initialize by using the usual LV before they are declared as pool metadata spare. We can optimize some other parts like udev to do a better job if it knows that the LV is temporary and any processing on it is just useless. This flag is orthogonal to LV_NOSCAN flag introduced recently as LV_NOSCAN flag is primarily used to mark an LV for the scanning to be avoided before the zeroing of the device happens. The LV_TEMPORARY flag makes a difference between a full-fledged LV visible in the system and the LV just used as a temporary overlay for some action that needs to be done on underlying PVs. For example: lvcreate --thinpool POOL --zero n -L 1G vg - first, the usual LV is created to do a clean up for pool metadata spare. The LV is activated, zeroed, deactivated. - between "activated" and "zeroed" stage, the LV_NOSCAN flag is used to avoid any scanning in udev - betwen "zeroed" and "deactivated" stage, we need to avoid the WATCH udev rule, but since the LV is just a usual LV, we can't make a difference. The LV_TEMPORARY internal LV flag helps here. If we create the LV with this flag, the DM_UDEV_DISABLE_DISK_RULES and DM_UDEV_DISABLE_OTHER_RULES flag are set (just like as it is with "invisible" and non-top-level LVs) - udev is directed to skip WATCH rule use. - if the LV_TEMPORARY flag was not used, there would normally be a WATCH event generated once the LV is closed after "zeroed" stage. This will make problems with immediated deactivation that follows.
2013-10-23 16:06:39 +04:00
if (lp->temporary)
lv->status |= LV_TEMPORARY;
lvcreate: new validation code Refactor lvcreate code. Prefer to use arg_outside_list_is_set() so we get automatic 'white-list' validation of supported options with different segment types. Drop used lp->cache, lp->cache and use seg_is_cache(), seg_is_thin() Draw clear border where is the last moment we could change create segment type. When segment type is given with --type - do not allow it to be changed later. Put together tests related to individual segment types. Finish cache conversion at proper part of lv_manip code after the vg_metadata are written - so we could correcly clean-up created stripe LV for cache volume.
2014-10-24 17:26:41 +04:00
if (seg_is_cache(lp)) {
lvmlockd: primarily use vg_is_shared to check if a vg uses an lvmlockd lock_type, instead of the equivalent but longer is_lockd_type.
2018-06-01 18:04:54 +03:00
if (vg_is_shared(vg)) {
lvmlockd: enable lvcreate of new LV plus existing cache pool In this command, lvcreate creates a new LV and then combines it with an existing cache pool, producing a cache LV. This command was previously not allowed in in a shared VG.
2018-05-30 23:24:24 +03:00
if (is_change_activating(lp->activate)) {
Remove unused clvm variations for active LVs Different flavors of activate_lv() and lv_is_active() which are meaningful in a clustered VG can be eliminated and replaced with whatever that flavor already falls back to in a local VG. e.g. lv_is_active_exclusive_locally() is distinct from lv_is_active() in a clustered VG, but in a local VG they are equivalent. So, all instances of the variant are replaced with the basic local equivalent. For local VGs, the same behavior remains as before. For shared VGs, lvmlockd was written with the explicit requirement of local behavior from these functions (lvmlockd requires locking_type 1), so the behavior in shared VGs also remains the same.
2018-06-05 21:21:28 +03:00
if (!lv_active_change(cmd, lv, CHANGE_AEY)) {
lvmlockd: enable lvcreate of new LV plus existing cache pool In this command, lvcreate creates a new LV and then combines it with an existing cache pool, producing a cache LV. This command was previously not allowed in in a shared VG.
2018-05-30 23:24:24 +03:00
log_error("Aborting. Failed to activate LV %s.",
display_lvname(lv));
goto revert_new_lv;
}
}
}
pre-release
2014-11-11 17:13:00 +03:00
/* FIXME Support remote exclusive activation? */
cleanup: indents comments backtraces
2014-11-06 22:36:53 +03:00
/* Not yet 'cache' LV, it is stripe volume for wiping */
lvmlockd: enable lvcreate of new LV plus existing cache pool In this command, lvcreate creates a new LV and then combines it with an existing cache pool, producing a cache LV. This command was previously not allowed in in a shared VG.
2018-05-30 23:24:24 +03:00
Remove unused clvm variations for active LVs Different flavors of activate_lv() and lv_is_active() which are meaningful in a clustered VG can be eliminated and replaced with whatever that flavor already falls back to in a local VG. e.g. lv_is_active_exclusive_locally() is distinct from lv_is_active() in a clustered VG, but in a local VG they are equivalent. So, all instances of the variant are replaced with the basic local equivalent. For local VGs, the same behavior remains as before. For shared VGs, lvmlockd was written with the explicit requirement of local behavior from these functions (lvmlockd requires locking_type 1), so the behavior in shared VGs also remains the same.
2018-06-05 21:21:28 +03:00
else if (is_change_activating(lp->activate) && !activate_lv(cmd, lv)) {
lvcreate: new validation code Refactor lvcreate code. Prefer to use arg_outside_list_is_set() so we get automatic 'white-list' validation of supported options with different segment types. Drop used lp->cache, lp->cache and use seg_is_cache(), seg_is_thin() Draw clear border where is the last moment we could change create segment type. When segment type is given with --type - do not allow it to be changed later. Put together tests related to individual segment types. Finish cache conversion at proper part of lv_manip code after the vg_metadata are written - so we could correcly clean-up created stripe LV for cache volume.
2014-10-24 17:26:41 +04:00
log_error("Aborting. Failed to activate LV %s locally exclusively.",
display_lvname(lv));
goto revert_new_lv;
}
} else if (lv_is_cache_pool(lv)) {
/* Cache pool cannot be actived and zeroed */
log_very_verbose("Cache pool is prepared.");
} else if (lv_is_thin_volume(lv)) {
Thin check for lv_thin_pool_percent error status Check has been missing.
2012-01-25 13:02:35 +04:00
/* For snapshot, suspend active thin origin first */
thin: enhance lvcreate error paths Improve error response and reporting, when creating thin snapshots. If the thin pool kernel metadata already have device with ID lvm2 tries to create, give more meanigful error message and also properly restore transaction id to the value known to thin-pool in this case. Before it's been possible to divert by one from kernel TID value, and lvm2 stacked delete message for such thin device.
2020-09-25 23:43:57 +03:00
if (origin_lv && lv_is_thin_volume(origin_lv) && lv_is_active(origin_lv)) {
if (!(ret = suspend_lv_origin(cmd, origin_lv))) {
log_error("Failed to suspend thin snapshot origin %s.",
display_lvname(origin_lv));
Thin use suspend/resume_lv_origin Use origin_only support for thin volume when thin snapshot is created.
2012-01-25 13:14:25 +04:00
}
thin: enhance lvcreate error paths Improve error response and reporting, when creating thin snapshots. If the thin pool kernel metadata already have device with ID lvm2 tries to create, give more meanigful error message and also properly restore transaction id to the value known to thin-pool in this case. Before it's been possible to divert by one from kernel TID value, and lvm2 stacked delete message for such thin device.
2020-09-25 23:43:57 +03:00
/* Note: always proceed with resume_lv() to leave critical_section */
cleanup: rename _name, _lv and _size Use some standard names for lv char * names, logical_volume * lv and sizes internally.
2014-10-07 12:43:47 +04:00
if (!resume_lv_origin(cmd, origin_lv)) { /* deptree updates thin-pool */
thin: enhance lvcreate error paths Improve error response and reporting, when creating thin snapshots. If the thin pool kernel metadata already have device with ID lvm2 tries to create, give more meanigful error message and also properly restore transaction id to the value known to thin-pool in this case. Before it's been possible to divert by one from kernel TID value, and lvm2 stacked delete message for such thin device.
2020-09-25 23:43:57 +03:00
log_error("Failed to resume thin snapshot origin %s.",
display_lvname(origin_lv));
if (ret)
/* suspend with message was OK, only resume failed */
goto revert_new_lv; /* hard to fix things here */
}
if (!ret) {
/* Pool transaction_id has been incremented for this canceled transaction
* and needs to be restored to the state from this canceled segment.
* TODO: there is low chance actual suspend has failed
*/
thin: use lv_status_thin and lv_status_thin_pool Introduce structures lv_status_thin_pool and lv_status_thin (pair to lv_status_cache, lv_status_vdo) Convert lv_thin_percent() -> lv_thin_status() and lv_thin_pool_percent() + lv_thin_pool_transaction_id() -> lv_thin_pool_status(). This way a function user can see not only percentages, but also other important status info about thin-pool. TODO: This patch tries to not change too many other things, but pool_below_threshold() now uses new thin-pool info to return failure if thin-pool cannot be actually modified. This should be handle separately in a better way.
2020-09-27 02:11:47 +03:00
struct lv_status_thin_pool *tpstatus;
if (!lv_thin_pool_status(pool_lv, 1, &tpstatus))
thin: enhance lvcreate error paths Improve error response and reporting, when creating thin snapshots. If the thin pool kernel metadata already have device with ID lvm2 tries to create, give more meanigful error message and also properly restore transaction id to the value known to thin-pool in this case. Before it's been possible to divert by one from kernel TID value, and lvm2 stacked delete message for such thin device.
2020-09-25 23:43:57 +03:00
log_error("Aborting. Failed to read transaction_id from thin pool %s.",
display_lvname(pool_lv)); /* Can't even get thin pool transaction id ??? */
thin: use lv_status_thin and lv_status_thin_pool Introduce structures lv_status_thin_pool and lv_status_thin (pair to lv_status_cache, lv_status_vdo) Convert lv_thin_percent() -> lv_thin_status() and lv_thin_pool_percent() + lv_thin_pool_transaction_id() -> lv_thin_pool_status(). This way a function user can see not only percentages, but also other important status info about thin-pool. TODO: This patch tries to not change too many other things, but pool_below_threshold() now uses new thin-pool info to return failure if thin-pool cannot be actually modified. This should be handle separately in a better way.
2020-09-27 02:11:47 +03:00
else {
transaction_id = tpstatus->thin_pool->transaction_id;
dm_pool_destroy(tpstatus->mem);
if ((transaction_id != first_seg(pool_lv)->transaction_id) &&
(transaction_id != seg->transaction_id))
thin: enhance lvcreate error paths Improve error response and reporting, when creating thin snapshots. If the thin pool kernel metadata already have device with ID lvm2 tries to create, give more meanigful error message and also properly restore transaction id to the value known to thin-pool in this case. Before it's been possible to divert by one from kernel TID value, and lvm2 stacked delete message for such thin device.
2020-09-25 23:43:57 +03:00
log_warn("WARNING: Metadata for thin pool %s have transaction_id " FMTu64
", but active pool has " FMTu64 ".",
display_lvname(pool_lv), seg->transaction_id, transaction_id);
thin: use lv_status_thin and lv_status_thin_pool Introduce structures lv_status_thin_pool and lv_status_thin (pair to lv_status_cache, lv_status_vdo) Convert lv_thin_percent() -> lv_thin_status() and lv_thin_pool_percent() + lv_thin_pool_transaction_id() -> lv_thin_pool_status(). This way a function user can see not only percentages, but also other important status info about thin-pool. TODO: This patch tries to not change too many other things, but pool_below_threshold() now uses new thin-pool info to return failure if thin-pool cannot be actually modified. This should be handle separately in a better way.
2020-09-27 02:11:47 +03:00
log_debug_metadata("Restoring previous transaction_id " FMTu64 " for thin pool %s.",
seg->transaction_id, display_lvname(pool_lv));
thin: enhance lvcreate error paths Improve error response and reporting, when creating thin snapshots. If the thin pool kernel metadata already have device with ID lvm2 tries to create, give more meanigful error message and also properly restore transaction id to the value known to thin-pool in this case. Before it's been possible to divert by one from kernel TID value, and lvm2 stacked delete message for such thin device.
2020-09-25 23:43:57 +03:00
first_seg(pool_lv)->transaction_id = seg->transaction_id;
first_seg(lv)->device_id = 0; /* no delete of never existing thin device */
}
Thin supports snapshots Full support for thin snapshots. Create and remove is supported. TODO: lvconvert support is not yes available.
2011-11-07 15:03:47 +04:00
goto revert_new_lv;
}
Thin use suspend/resume_lv_origin Use origin_only support for thin volume when thin snapshot is created.
2012-01-25 13:14:25 +04:00
/* At this point remove pool messages, snapshot is active */
thin: rename internal function Names matching internal code layout. Functionc in thin_manip.c uses thin_pool in its name. Keep 'pool' only for function working for both cache and thin pools. No change of functionality.
2022-08-24 16:02:07 +03:00
if (!update_thin_pool_lv(pool_lv, 0)) {
Thin supports snapshots Full support for thin snapshots. Create and remove is supported. TODO: lvconvert support is not yes available.
2011-11-07 15:03:47 +04:00
stack;
thin: fix error path in creation path Remove some calls to revert_new_lv when no LV has been created/commited so far. When the pool update failed - then only revert is needed.
2013-07-17 17:26:41 +04:00
goto revert_new_lv;
Thin supports snapshots Full support for thin snapshots. Create and remove is supported. TODO: lvconvert support is not yes available.
2011-11-07 15:03:47 +04:00
}
cleanup: avoid unneeded check Since creation of thin snapshot already makes sure, the message list is empty, there is no need to check this again.
2020-09-26 20:32:52 +03:00
} else if (!dm_list_empty(&first_seg(pool_lv)->thin_messages)) {
thin: improve pool creation activation order Pool creation involves clearing of metadata device which triggers udev watch rule we cannot udev synchronize with in current code. This metadata devices needs to be activated localy, so in cluster mode deactivation and reactivation is always needed. However for non-clustered mode we may reload table via suspend/resume path which avoids collision with udev watch rule which was occasionaly triggering retry deactivation loop. Code has been also split into 2 separate code paths for thin pools and thin volumes which improved readability of the code as well. Deactivation has been moved out of extend_pool() and decision is now in _lv_create_an_lv() which knows the change mode.
2013-07-18 18:44:39 +04:00
/* Send message so that table preload knows new thin */
thin: check for new pool before creating thin volume Call check_new_thin_pool() to detect in-use thin-pool. Save extra reactivation of thin-pool when thin pool is not active. (it's now a bit more expensive to invoke thin_check for new pools.) For new pools: We now active locally exclusively thin-pool as 'public' LV. Validate transaction_id is till 0. Deactive. Prepare create message for thin-pool and exclusively active pool. Active new thin LV. And deactivate thin pool if it used to be inactive.
2014-11-04 17:08:15 +03:00
if (!lv_is_active(pool_lv)) {
/* Avoid multiple thin-pool activations in this case */
if (thin_pool_was_active < 0)
thin_pool_was_active = 0;
Remove unused clvm variations for active LVs Different flavors of activate_lv() and lv_is_active() which are meaningful in a clustered VG can be eliminated and replaced with whatever that flavor already falls back to in a local VG. e.g. lv_is_active_exclusive_locally() is distinct from lv_is_active() in a clustered VG, but in a local VG they are equivalent. So, all instances of the variant are replaced with the basic local equivalent. For local VGs, the same behavior remains as before. For shared VGs, lvmlockd was written with the explicit requirement of local behavior from these functions (lvmlockd requires locking_type 1), so the behavior in shared VGs also remains the same.
2018-06-05 21:21:28 +03:00
if (!activate_lv(cmd, pool_lv)) {
thin: fix error path Print pool name and not the origin name.
2014-11-19 20:57:40 +03:00
log_error("Failed to activate thin pool %s.",
display_lvname(pool_lv));
thin: check for new pool before creating thin volume Call check_new_thin_pool() to detect in-use thin-pool. Save extra reactivation of thin-pool when thin pool is not active. (it's now a bit more expensive to invoke thin_check for new pools.) For new pools: We now active locally exclusively thin-pool as 'public' LV. Validate transaction_id is till 0. Deactive. Prepare create message for thin-pool and exclusively active pool. Active new thin LV. And deactivate thin pool if it used to be inactive.
2014-11-04 17:08:15 +03:00
goto revert_new_lv;
}
if (!lv_is_active(pool_lv)) {
log_error("Cannot activate thin pool %s, perhaps skipped in lvm.conf volume_list?",
display_lvname(pool_lv));
return 0;
}
}
/* Keep thin pool active until thin volume is activated */
thin: rename internal function Names matching internal code layout. Functionc in thin_manip.c uses thin_pool in its name. Keep 'pool' only for function working for both cache and thin pools. No change of functionality.
2022-08-24 16:02:07 +03:00
if (!update_thin_pool_lv(pool_lv, 1)) {
Thin correct activation order When the message is passed only in resume path the order needs to be corrected.
2012-01-25 13:15:44 +04:00
stack;
thin: improve pool creation activation order Pool creation involves clearing of metadata device which triggers udev watch rule we cannot udev synchronize with in current code. This metadata devices needs to be activated localy, so in cluster mode deactivation and reactivation is always needed. However for non-clustered mode we may reload table via suspend/resume path which avoids collision with udev watch rule which was occasionaly triggering retry deactivation loop. Code has been also split into 2 separate code paths for thin pools and thin volumes which improved readability of the code as well. Deactivation has been moved out of extend_pool() and decision is now in _lv_create_an_lv() which knows the change mode.
2013-07-18 18:44:39 +04:00
goto revert_new_lv;
Thin correct activation order When the message is passed only in resume path the order needs to be corrected.
2012-01-25 13:15:44 +04:00
}
thin: move pool messaging from resume to suspend Existing messaging intarface for thin-pool has a few 'weak' points: * Message were posted with each 'resume' operation, thus not allowing activation of thin-pool with the existing state. * Acceleration skipped suspend step has not worked in cluster, since clvmd resumes only nodes which are suspended (have proper lock state). * Resume may fail and code is not really designed to 'fail' in this phase (generic rule here is resume DOES NOT fail unless something serious is wrong and lvm2 tool usually doesn't handle recovery path in this case.) * Full thin-pool suspend happened, when taken a thin-volume snapshot. With this patch the new method relocates message passing into suspend state. This has a few drawbacks with current API, but overal it performs better and gives are more posibilities to deal with errors. Patch introduces a new logic for 'origin-only' suspend of thin-pool and this also relates to thin-volume when taking snapshot. When suspend_origin_only operation is invoked on a pool with queued messages then only those messages are posted to thin-pool and actual suspend of thin pool and data and metadata volume is skipped. This makes taking a snapshot of thin-volume lighter operation and avoids blocking of other unrelated active thin volumes. Also fail now happens in 'suspend' state where the 'Fail' is more expected and it is better handled through error paths. Activation of thin-pool is now not sending any message and leaves upto a tool to decided later how to finish unfinished double-commit transaction. Problem which needs some API improvements relates to the lvm2 tree construction. For the suspend tree we do not add target table line into the tree, but only a device is inserted into a tree. Current mechanism to attach messages for thin-pool requires the libdm to know about thin-pool target, so lvm2 currently takes assumption, node is really a thin-pool and fills in the table line for this node (which should be ensured by the PRELOAD phase, but it's a misuse of internal API) we would possibly need to be able to attach message to 'any' node. Other thing to notice - current messaging interface in thin-pool target requires to suspend thin volume origin first and then send a create message, but this could not have any 'nice' solution on lvm2 side and IMHO we should introduce something like 'create_after_resume' message. Patch also changes the moment, where lvm2 transaction id is increased. Now it happens only after successful finish of kernel transaction id change. This change was needed to handle properly activation of pool, which is in the middle of unfinished transaction, and also this corrects usage of thin-pool by external apps like Docker.
2015-07-01 14:31:37 +03:00
}
lv_manip: fix out of order backup We had only 2 remaining places that were leaving unbackuped metadata.
2014-10-03 20:39:54 +04:00
Remove unused clvm variations for active LVs Different flavors of activate_lv() and lv_is_active() which are meaningful in a clustered VG can be eliminated and replaced with whatever that flavor already falls back to in a local VG. e.g. lv_is_active_exclusive_locally() is distinct from lv_is_active() in a clustered VG, but in a local VG they are equivalent. So, all instances of the variant are replaced with the basic local equivalent. For local VGs, the same behavior remains as before. For shared VGs, lvmlockd was written with the explicit requirement of local behavior from these functions (lvmlockd requires locking_type 1), so the behavior in shared VGs also remains the same.
2018-06-05 21:21:28 +03:00
if (!lv_active_change(cmd, lv, lp->activate)) {
thin: move pool messaging from resume to suspend Existing messaging intarface for thin-pool has a few 'weak' points: * Message were posted with each 'resume' operation, thus not allowing activation of thin-pool with the existing state. * Acceleration skipped suspend step has not worked in cluster, since clvmd resumes only nodes which are suspended (have proper lock state). * Resume may fail and code is not really designed to 'fail' in this phase (generic rule here is resume DOES NOT fail unless something serious is wrong and lvm2 tool usually doesn't handle recovery path in this case.) * Full thin-pool suspend happened, when taken a thin-volume snapshot. With this patch the new method relocates message passing into suspend state. This has a few drawbacks with current API, but overal it performs better and gives are more posibilities to deal with errors. Patch introduces a new logic for 'origin-only' suspend of thin-pool and this also relates to thin-volume when taking snapshot. When suspend_origin_only operation is invoked on a pool with queued messages then only those messages are posted to thin-pool and actual suspend of thin pool and data and metadata volume is skipped. This makes taking a snapshot of thin-volume lighter operation and avoids blocking of other unrelated active thin volumes. Also fail now happens in 'suspend' state where the 'Fail' is more expected and it is better handled through error paths. Activation of thin-pool is now not sending any message and leaves upto a tool to decided later how to finish unfinished double-commit transaction. Problem which needs some API improvements relates to the lvm2 tree construction. For the suspend tree we do not add target table line into the tree, but only a device is inserted into a tree. Current mechanism to attach messages for thin-pool requires the libdm to know about thin-pool target, so lvm2 currently takes assumption, node is really a thin-pool and fills in the table line for this node (which should be ensured by the PRELOAD phase, but it's a misuse of internal API) we would possibly need to be able to attach message to 'any' node. Other thing to notice - current messaging interface in thin-pool target requires to suspend thin volume origin first and then send a create message, but this could not have any 'nice' solution on lvm2 side and IMHO we should introduce something like 'create_after_resume' message. Patch also changes the moment, where lvm2 transaction id is increased. Now it happens only after successful finish of kernel transaction id change. This change was needed to handle properly activation of pool, which is in the middle of unfinished transaction, and also this corrects usage of thin-pool by external apps like Docker.
2015-07-01 14:31:37 +03:00
log_error("Failed to activate thin %s.", lv->name);
goto deactivate_and_revert_new_lv;
}
thin: check for new pool before creating thin volume Call check_new_thin_pool() to detect in-use thin-pool. Save extra reactivation of thin-pool when thin pool is not active. (it's now a bit more expensive to invoke thin_check for new pools.) For new pools: We now active locally exclusively thin-pool as 'public' LV. Validate transaction_id is till 0. Deactive. Prepare create message for thin-pool and exclusively active pool. Active new thin LV. And deactivate thin pool if it used to be inactive.
2014-11-04 17:08:15 +03:00
thin: move pool messaging from resume to suspend Existing messaging intarface for thin-pool has a few 'weak' points: * Message were posted with each 'resume' operation, thus not allowing activation of thin-pool with the existing state. * Acceleration skipped suspend step has not worked in cluster, since clvmd resumes only nodes which are suspended (have proper lock state). * Resume may fail and code is not really designed to 'fail' in this phase (generic rule here is resume DOES NOT fail unless something serious is wrong and lvm2 tool usually doesn't handle recovery path in this case.) * Full thin-pool suspend happened, when taken a thin-volume snapshot. With this patch the new method relocates message passing into suspend state. This has a few drawbacks with current API, but overal it performs better and gives are more posibilities to deal with errors. Patch introduces a new logic for 'origin-only' suspend of thin-pool and this also relates to thin-volume when taking snapshot. When suspend_origin_only operation is invoked on a pool with queued messages then only those messages are posted to thin-pool and actual suspend of thin pool and data and metadata volume is skipped. This makes taking a snapshot of thin-volume lighter operation and avoids blocking of other unrelated active thin volumes. Also fail now happens in 'suspend' state where the 'Fail' is more expected and it is better handled through error paths. Activation of thin-pool is now not sending any message and leaves upto a tool to decided later how to finish unfinished double-commit transaction. Problem which needs some API improvements relates to the lvm2 tree construction. For the suspend tree we do not add target table line into the tree, but only a device is inserted into a tree. Current mechanism to attach messages for thin-pool requires the libdm to know about thin-pool target, so lvm2 currently takes assumption, node is really a thin-pool and fills in the table line for this node (which should be ensured by the PRELOAD phase, but it's a misuse of internal API) we would possibly need to be able to attach message to 'any' node. Other thing to notice - current messaging interface in thin-pool target requires to suspend thin volume origin first and then send a create message, but this could not have any 'nice' solution on lvm2 side and IMHO we should introduce something like 'create_after_resume' message. Patch also changes the moment, where lvm2 transaction id is increased. Now it happens only after successful finish of kernel transaction id change. This change was needed to handle properly activation of pool, which is in the middle of unfinished transaction, and also this corrects usage of thin-pool by external apps like Docker.
2015-07-01 14:31:37 +03:00
/* Restore inactive state if needed */
if (!thin_pool_was_active &&
!deactivate_lv(cmd, pool_lv)) {
log_error("Failed to deactivate thin pool %s.",
display_lvname(pool_lv));
return NULL;
Ensure right activation order Couple FIXMEs put into the code for parts of the code which may be improved later, since we might be able to add 'lazy' device creation later. For now require exclusive activation.
2011-10-20 14:35:14 +04:00
}
} else if (lp->snapshot) {
snapshot: virtual save commit More efficient spare volume creation. Save 1 extra commit and properly activate this volume according to our cluster activation rules (using lv_active_change() for this).
2014-11-05 17:15:07 +03:00
lv->status |= LV_TEMPORARY;
Remove unused clvm variations for active LVs Different flavors of activate_lv() and lv_is_active() which are meaningful in a clustered VG can be eliminated and replaced with whatever that flavor already falls back to in a local VG. e.g. lv_is_active_exclusive_locally() is distinct from lv_is_active() in a clustered VG, but in a local VG they are equivalent. So, all instances of the variant are replaced with the basic local equivalent. For local VGs, the same behavior remains as before. For shared VGs, lvmlockd was written with the explicit requirement of local behavior from these functions (lvmlockd requires locking_type 1), so the behavior in shared VGs also remains the same.
2018-06-05 21:21:28 +03:00
if (!activate_lv(cmd, lv)) {
Move _lvcreate into the internal library and rename to lv_create_single. After some refactorings, we can now move the bulk of _lvcreate into the internal library, and we can call from liblvm. In the future, we should refactor lv_create_single further, probably by segtype, to reduce the size of struct lvcreate_params. For now this is a reasonable refactor and allows us to re-use the function from liblvm. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-07-26 06:33:35 +04:00
log_error("Aborting. Failed to activate snapshot "
"exception store.");
goto revert_new_lv;
}
snapshot: virtual save commit More efficient spare volume creation. Save 1 extra commit and properly activate this volume according to our cluster activation rules (using lv_active_change() for this).
2014-11-05 17:15:07 +03:00
lv->status &= ~LV_TEMPORARY;
vdo: support lvcreate with skipped activation Support creation of VDO LV for 'lvcreate -ky...'.
2021-08-31 22:34:06 +03:00
} else if (seg_is_vdo_pool(lp)) {
lv->status |= LV_TEMPORARY;
if (!activate_lv(cmd, lv)) {
log_error("Aborting. Failed to activate temporary "
"volume for VDO pool creation.");
goto revert_new_lv;
}
lv->status &= ~LV_TEMPORARY;
Remove unused clvm variations for active LVs Different flavors of activate_lv() and lv_is_active() which are meaningful in a clustered VG can be eliminated and replaced with whatever that flavor already falls back to in a local VG. e.g. lv_is_active_exclusive_locally() is distinct from lv_is_active() in a clustered VG, but in a local VG they are equivalent. So, all instances of the variant are replaced with the basic local equivalent. For local VGs, the same behavior remains as before. For shared VGs, lvmlockd was written with the explicit requirement of local behavior from these functions (lvmlockd requires locking_type 1), so the behavior in shared VGs also remains the same.
2018-06-05 21:21:28 +03:00
} else if (!lv_active_change(cmd, lv, lp->activate)) {
lv_manip: add name of failing LV into error message
2018-06-29 18:26:01 +03:00
log_error("Failed to activate new LV %s.", display_lvname(lv));
lvcreate: new validation code Refactor lvcreate code. Prefer to use arg_outside_list_is_set() so we get automatic 'white-list' validation of supported options with different segment types. Drop used lp->cache, lp->cache and use seg_is_cache(), seg_is_thin() Draw clear border where is the last moment we could change create segment type. When segment type is given with --type - do not allow it to be changed later. Put together tests related to individual segment types. Finish cache conversion at proper part of lv_manip code after the vg_metadata are written - so we could correcly clean-up created stripe LV for cache volume.
2014-10-24 17:26:41 +04:00
goto deactivate_and_revert_new_lv;
Move _lvcreate into the internal library and rename to lv_create_single. After some refactorings, we can now move the bulk of _lvcreate into the internal library, and we can call from liblvm. In the future, we should refactor lv_create_single further, probably by segtype, to reduce the size of struct lvcreate_params. For now this is a reasonable refactor and allows us to re-use the function from liblvm. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-07-26 06:33:35 +04:00
}
lvconvert: suppress zeroing warning when converting to thin When volume was lvconvert-ed to a thin-volume with external origin, then in case thin-pool was in non-zeroing mode it's been printing WARNING about not zeroing thin volume - but this is wanted and expected - so nothing to warn about. So in this particular use case WARNING needs to be suppressed. Adding parameter support for lvcreate_params. So now lvconvert creates 'normal thin LV' in read-only mode (so any read will 'return 0' for a moment) then deactivate regular thin LV and reacreate in 'final R/RW' mode thin LV with external origin and activate again.
2016-07-27 14:36:25 +03:00
if (_should_wipe_lv(lp, lv, !lp->suppress_zero_warn)) {
cleanup: use compound literals for wipe_lv Optimize and cleanup recently introduced new function wipe_lv. Use compound literals to get nicely initialized wipe_params struct. Pass in lv as explicit argument for wipe_lv. Use cmd from lv structure. Initialize only non-null members so it's easy to see what is the special arg.
2013-11-28 14:22:24 +04:00
if (!wipe_lv(lv, (struct wipe_params)
{
.do_zero = lp->zero,
.do_wipe_signatures = lp->wipe_signatures,
.yes = lp->yes,
pool: zero metadata To avoid polution of metadata with some 'garbage' content or eventualy some leak of stale data in case user want to upload metadata somewhere, ensure upon allocation the metadata device is fully zeroed. Behaviour may slow down allocation of thin-pool or cache-pool a bit so the old behaviour can be restored with lvm.conf setting: allocation/zero_metadata=0 TODO: add zeroing for extension of metadata volume.
2020-06-24 13:11:21 +03:00
.force = lp->force,
.is_metadata = lp->is_metadata,
cleanup: use compound literals for wipe_lv Optimize and cleanup recently introduced new function wipe_lv. Use compound literals to get nicely initialized wipe_params struct. Pass in lv as explicit argument for wipe_lv. Use cmd from lv structure. Initialize only non-null members so it's easy to see what is the special arg.
2013-11-28 14:22:24 +04:00
})) {
cleanup: indent Various indents and tiny error message improvements.
2014-10-18 13:01:29 +04:00
log_error("Aborting. Failed to wipe %s.", lp->snapshot
? "snapshot exception store" : "start of new LV");
lv_manip: rename set_lv -> wipe_lv and include signature wiping capability Use common wipe_lv (former set_lv) fn to do zeroing as well as signature wiping if needed. Provide new struct wipe_lv_params to define the functionality. Bind "lvcreate -W/--wipesignatures y" with proper wipe_lv call. Also, add "yes" and "force" to lvcreate_params so it's possible to apply them for the prompt: "WARNING: %s detected on %s. Wipe it? [y/n]".
2013-11-06 19:16:34 +04:00
goto deactivate_and_revert_new_lv;
}
Move _lvcreate into the internal library and rename to lv_create_single. After some refactorings, we can now move the bulk of _lvcreate into the internal library, and we can call from liblvm. In the future, we should refactor lv_create_single further, probably by segtype, to reduce the size of struct lvcreate_params. For now this is a reasonable refactor and allows us to re-use the function from liblvm. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-07-26 06:33:35 +04:00
}
vdo: introduce segment types and manip functions Core functionality introducing lvm VDO support.
2018-06-29 12:11:14 +03:00
if (seg_is_vdo_pool(lp)) {
vdo: support vdo_pool_header_size Add profilable configurable setting for vdo pool header size, that is used as 'extra' empty space at the front and end of vdo-pool device to avoid having a disk in the system the may have same data is real vdo LV. For some conversion cases however we may need to allow using '0' header size. TODO: in this case we may eventually avoid adding 'linear' mapping layer in future - but this requires further modification over lvm code base.
2021-06-28 18:53:08 +03:00
if (!convert_vdo_pool_lv(lv, &lp->vdo_params, &lp->virtual_extents,
1, lp->vdo_pool_header_size)) {
vdo: introduce segment types and manip functions Core functionality introducing lvm VDO support.
2018-06-29 12:11:14 +03:00
stack;
goto deactivate_and_revert_new_lv;
}
vdo: support lvcreate with skipped activation Support creation of VDO LV for 'lvcreate -ky...'.
2021-08-31 22:34:06 +03:00
if ((lv->status & LV_ACTIVATION_SKIP) &&
!deactivate_lv(cmd, lv)) {
log_error("Aborting. Couldn't deactivate VDO LV %s with skipped activation.",
display_lvname(lv));
return NULL; /* Let's retry on error path */
}
vdo: introduce segment types and manip functions Core functionality introducing lvm VDO support.
2018-06-29 12:11:14 +03:00
} else if (seg_is_cache(lp) || (origin_lv && lv_is_cache_pool(lv))) {
lvcreate: new validation code Refactor lvcreate code. Prefer to use arg_outside_list_is_set() so we get automatic 'white-list' validation of supported options with different segment types. Drop used lp->cache, lp->cache and use seg_is_cache(), seg_is_thin() Draw clear border where is the last moment we could change create segment type. When segment type is given with --type - do not allow it to be changed later. Put together tests related to individual segment types. Finish cache conversion at proper part of lv_manip code after the vg_metadata are written - so we could correcly clean-up created stripe LV for cache volume.
2014-10-24 17:26:41 +04:00
/* Finish cache conversion magic */
if (origin_lv) {
/* Convert origin to cached LV */
if (!(tmp_lv = lv_cache_create(lv, origin_lv))) {
pre-release
2014-11-11 17:13:00 +03:00
/* FIXME Do a better revert */
lvcreate: new validation code Refactor lvcreate code. Prefer to use arg_outside_list_is_set() so we get automatic 'white-list' validation of supported options with different segment types. Drop used lp->cache, lp->cache and use seg_is_cache(), seg_is_thin() Draw clear border where is the last moment we could change create segment type. When segment type is given with --type - do not allow it to be changed later. Put together tests related to individual segment types. Finish cache conversion at proper part of lv_manip code after the vg_metadata are written - so we could correcly clean-up created stripe LV for cache volume.
2014-10-24 17:26:41 +04:00
log_error("Aborting. Leaving cache pool %s and uncached origin volume %s.",
display_lvname(lv), display_lvname(origin_lv));
return NULL;
}
} else {
if (!(tmp_lv = lv_cache_create(pool_lv, lv))) {
/* 'lv' still keeps created new LV */
stack;
goto deactivate_and_revert_new_lv;
}
}
lv = tmp_lv;
metadata: Add cache_policy to lvcreate_params and honour it.
2014-11-27 22:20:48 +03:00
lvcreate: improve --chunksize support for cached volume. Support parsing --chunksize option also when converting. Now user can use cache pool created with i.e. 32K chunksize, while in caching user can select 512K blocks. Tool is supposed to validate cache metadata size is big enough to support such chunk size. Otherwise error is shown.
2016-05-05 22:34:21 +03:00
if (!cache_set_params(first_seg(lv),
cache: set chunk_size as first param
2017-03-09 17:54:30 +03:00
lp->chunk_size,
cache: enable usage of --cachemetadataformat lvcreate and lvconvert may select cache metadata format when caching LV. By default lvm2 picks best available format.
2017-02-26 22:18:37 +03:00
lp->cache_metadata_format,
lvcreate: improve --chunksize support for cached volume. Support parsing --chunksize option also when converting. Now user can use cache pool created with i.e. 32K chunksize, while in caching user can select 512K blocks. Tool is supposed to validate cache metadata size is big enough to support such chunk size. Otherwise error is shown.
2016-05-05 22:34:21 +03:00
lp->cache_mode,
lp->policy_name,
cache: set chunk_size as first param
2017-03-09 17:54:30 +03:00
lp->policy_settings))
cache: api update Change logic and naming of some internal API functions. cache_set_mode() and cache_set_policy() both take segment. cache mode is now correctly 'masked-in'. If the passed segment is 'cache' segment - it will automatically try to find 'defaults' according to profiles if the are NOT specified on command line or they are NOT already set for cache-pool. These defaults are never set for cache-pool.
2015-08-11 15:01:12 +03:00
return_NULL; /* revert? */
lvcreate: new validation code Refactor lvcreate code. Prefer to use arg_outside_list_is_set() so we get automatic 'white-list' validation of supported options with different segment types. Drop used lp->cache, lp->cache and use seg_is_cache(), seg_is_thin() Draw clear border where is the last moment we could change create segment type. When segment type is given with --type - do not allow it to be changed later. Put together tests related to individual segment types. Finish cache conversion at proper part of lv_manip code after the vg_metadata are written - so we could correcly clean-up created stripe LV for cache volume.
2014-10-24 17:26:41 +04:00
if (!lv_update_and_reload(lv)) {
cache: implement better revert path When cache creation fails on table reload path, implemen more advanced revert solution, that tries to restore state of LVM metadata into is look before actual caching started.
2021-09-12 18:44:38 +03:00
char name[NAME_LEN];
log_debug("Reverting created caching layer.");
tmp_lv = seg_lv(first_seg(lv), 0); /* tmp corigin */
pool_lv = first_seg(lv)->pool_lv;
if (!detach_pool_lv(first_seg(lv)))
return_NULL;
if (!remove_layer_from_lv(lv, tmp_lv))
return_NULL;
if (!lv_remove(tmp_lv))
return_NULL;
/* Either we need to preserve existing LV and remove created cache pool LV.
Or we need to preserve existing cache pool LV and remove created new LV. */
if (origin_lv)
lv = pool_lv; // created cache pool to be reverted as new LV
else {
/* Cut off suffix _cpool from preserved existing cache pool */
if (!drop_lvname_suffix(name, pool_lv->name, "cpool")) {
/* likely older instance of metadata */
log_debug("LV %s has no suffix for cachepool (skipping rename).",
display_lvname(pool_lv));
} else if (!lv_uniq_rename_update(cmd, pool_lv, name, 0))
return_NULL;
}
goto deactivate_and_revert_new_lv;
lvcreate: new validation code Refactor lvcreate code. Prefer to use arg_outside_list_is_set() so we get automatic 'white-list' validation of supported options with different segment types. Drop used lp->cache, lp->cache and use seg_is_cache(), seg_is_thin() Draw clear border where is the last moment we could change create segment type. When segment type is given with --type - do not allow it to be changed later. Put together tests related to individual segment types. Finish cache conversion at proper part of lv_manip code after the vg_metadata are written - so we could correcly clean-up created stripe LV for cache volume.
2014-10-24 17:26:41 +04:00
}
} else if (lp->snapshot) {
snapshot: virtual save commit More efficient spare volume creation. Save 1 extra commit and properly activate this volume according to our cluster activation rules (using lv_active_change() for this).
2014-11-05 17:15:07 +03:00
/* Deactivate zeroed COW, avoid any race usage */
if (!deactivate_lv(cmd, lv)) {
log_error("Aborting. Couldn't deactivate snapshot COW area %s.",
display_lvname(lv));
goto deactivate_and_revert_new_lv; /* Let's retry on error path */
}
snapshot: add synchronization point Synchronize with udev logic before reusing device as snapshot. This patch tries to fix the problem with udev, where we manage to 'active' LV for clearing, then we deactivate such device and active again as member of 'origin&snapshot' tree all in 1 step. There needs to be a sync point where udev has time to remove all links, otherwise we race with scans and we may end-up with mysterious 'free' links in the system pointing to wrong dm names. This patch tries to fix failing topology cluster tests..
2015-06-24 16:12:43 +03:00
/* Get in sync with deactivation, before reusing LV as snapshot */
locking: Add missing error handling. Add missing error logging and detection to unlock_vg and callers of sync_local_dev_names etc.
2015-06-30 20:54:38 +03:00
if (!sync_local_dev_names(lv->vg->cmd)) {
log_error("Failed to sync local devices before creating snapshot using %s.",
display_lvname(lv));
goto revert_new_lv;
}
snapshot: add synchronization point Synchronize with udev logic before reusing device as snapshot. This patch tries to fix the problem with udev, where we manage to 'active' LV for clearing, then we deactivate such device and active again as member of 'origin&snapshot' tree all in 1 step. There needs to be a sync point where udev has time to remove all links, otherwise we race with scans and we may end-up with mysterious 'free' links in the system pointing to wrong dm names. This patch tries to fix failing topology cluster tests..
2015-06-24 16:12:43 +03:00
snapshot: virtual save commit More efficient spare volume creation. Save 1 extra commit and properly activate this volume according to our cluster activation rules (using lv_active_change() for this).
2014-11-05 17:15:07 +03:00
/* Create zero origin volume for spare snapshot */
if (lp->virtual_extents &&
!(origin_lv = _create_virtual_origin(cmd, vg, lv->name,
snapshot: create origin of virtual snap read only When creating old fashioned way thick virtual snapshot, use read-only 'zero' _vorigin device.
2021-02-10 00:31:31 +03:00
(lp->permission & ~LVM_WRITE),
snapshot: virtual save commit More efficient spare volume creation. Save 1 extra commit and properly activate this volume according to our cluster activation rules (using lv_active_change() for this).
2014-11-05 17:15:07 +03:00
lp->virtual_extents)))
goto revert_new_lv;
Move _lvcreate into the internal library and rename to lv_create_single. After some refactorings, we can now move the bulk of _lvcreate into the internal library, and we can call from liblvm. In the future, we should refactor lv_create_single further, probably by segtype, to reduce the size of struct lvcreate_params. For now this is a reasonable refactor and allows us to re-use the function from liblvm. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-07-26 06:33:35 +04:00
/* Reset permission after zeroing */
if (!(lp->permission & LVM_WRITE))
lv->status &= ~LVM_WRITE;
snapshot: rework cluster creation and removal Support for exclusive activation of snapshots revealed some problems. When snapshot is created, COW LV is activated first (for clearing) and then it's transformed into snapshot's COW LV, but it has left the lock for such LV active in cluster and this lock could not have been removed from dlm, unless snapshot has been removed within same dlm session. If the user tried to remove snapshot after rebooting node, the lock was missing, and COW LV could not have been detached. Patch modifes the approach in this way: Always deactivate COW LV for clustered vg after clearing (so it's activated again via imlicit snapshot activation rule when snapshot is activated). When snapshot is removed, activate COW LV as independend LV, so the lock will exist for such LV, but only when the snapshot is active. Also add test case for testing snapshot removal after cluster reboot.
2013-04-21 12:37:52 +04:00
/*
* COW LV is activated via implicit activation of origin LV
* Only the snapshot origin holds the LV lock in cluster
*/
lv_manip: add extra check for existin origin_lv clang: it's supposedly impossible path to hit, as we should always have origin_lv defined when running this path, but adding protection isn't a big issue to make this obvious to analyzer.
2020-01-30 17:54:19 +03:00
if (!origin_lv ||
!vg_add_snapshot(origin_lv, lv, NULL,
cleanup: rename _name, _lv and _size Use some standard names for lv char * names, logical_volume * lv and sizes internally.
2014-10-07 12:43:47 +04:00
origin_lv->le_count, lp->chunk_size)) {
Move _lvcreate into the internal library and rename to lv_create_single. After some refactorings, we can now move the bulk of _lvcreate into the internal library, and we can call from liblvm. In the future, we should refactor lv_create_single further, probably by segtype, to reduce the size of struct lvcreate_params. For now this is a reasonable refactor and allows us to re-use the function from liblvm. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-07-26 06:33:35 +04:00
log_error("Couldn't create snapshot.");
goto deactivate_and_revert_new_lv;
}
snapshot: virtual save commit More efficient spare volume creation. Save 1 extra commit and properly activate this volume according to our cluster activation rules (using lv_active_change() for this).
2014-11-05 17:15:07 +03:00
if (lp->virtual_extents) {
/* Store vg on disk(s) */
if (!vg_write(vg) || !vg_commit(vg))
return_NULL; /* Metadata update fails, deep troubles */
/*
pre-release
2014-11-11 17:13:00 +03:00
* FIXME We do not actually need snapshot-origin as an active device,
* as virtual origin is already 'hidden' private device without
* vg/lv links. As such it is not supposed to be used by any user.
* Also it would save one dm table entry, but it needs quite a few
* changes in the libdm/lvm2 code base to support it.
snapshot: virtual save commit More efficient spare volume creation. Save 1 extra commit and properly activate this volume according to our cluster activation rules (using lv_active_change() for this).
2014-11-05 17:15:07 +03:00
*/
pre-release
2014-11-11 17:13:00 +03:00
snapshot: virtual save commit More efficient spare volume creation. Save 1 extra commit and properly activate this volume according to our cluster activation rules (using lv_active_change() for this).
2014-11-05 17:15:07 +03:00
/* Activate spare snapshot once it is a complete LV */
Remove unused clvm variations for active LVs Different flavors of activate_lv() and lv_is_active() which are meaningful in a clustered VG can be eliminated and replaced with whatever that flavor already falls back to in a local VG. e.g. lv_is_active_exclusive_locally() is distinct from lv_is_active() in a clustered VG, but in a local VG they are equivalent. So, all instances of the variant are replaced with the basic local equivalent. For local VGs, the same behavior remains as before. For shared VGs, lvmlockd was written with the explicit requirement of local behavior from these functions (lvmlockd requires locking_type 1), so the behavior in shared VGs also remains the same.
2018-06-05 21:21:28 +03:00
if (!lv_active_change(cmd, origin_lv, lp->activate)) {
snapshot: virtual save commit More efficient spare volume creation. Save 1 extra commit and properly activate this volume according to our cluster activation rules (using lv_active_change() for this).
2014-11-05 17:15:07 +03:00
log_error("Failed to activate sparce volume %s.",
display_lvname(origin_lv));
return NULL;
}
} else if (!lv_update_and_reload(origin_lv)) {
log_error("Aborting. Manual intervention required.");
return NULL; /* FIXME: revert */
}
Move _lvcreate into the internal library and rename to lv_create_single. After some refactorings, we can now move the bulk of _lvcreate into the internal library, and we can call from liblvm. In the future, we should refactor lv_create_single further, probably by segtype, to reduce the size of struct lvcreate_params. For now this is a reasonable refactor and allows us to re-use the function from liblvm. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-07-26 06:33:35 +04:00
}
Fix lvchange --test to exit cleanly.
2011-01-24 17:19:05 +03:00
out:
lvcreate parsing for thin provisioning. The rest is incomplete so this isn't usable yet.
2011-09-06 04:26:42 +04:00
return lv;
Move _lvcreate into the internal library and rename to lv_create_single. After some refactorings, we can now move the bulk of _lvcreate into the internal library, and we can call from liblvm. In the future, we should refactor lv_create_single further, probably by segtype, to reduce the size of struct lvcreate_params. For now this is a reasonable refactor and allows us to re-use the function from liblvm. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-07-26 06:33:35 +04:00
deactivate_and_revert_new_lv:
lvcreate: add extra synchronization at error path Put explict udev synchronization before we try to deactive devices.
2020-09-04 19:08:59 +03:00
if (!sync_local_dev_names(lv->vg->cmd))
log_error("Failed to sync local devices before reverting %s.",
display_lvname(lv));
Move _lvcreate into the internal library and rename to lv_create_single. After some refactorings, we can now move the bulk of _lvcreate into the internal library, and we can call from liblvm. In the future, we should refactor lv_create_single further, probably by segtype, to reduce the size of struct lvcreate_params. For now this is a reasonable refactor and allows us to re-use the function from liblvm. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-07-26 06:33:35 +04:00
if (!deactivate_lv(cmd, lv)) {
snapshot: virtual save commit More efficient spare volume creation. Save 1 extra commit and properly activate this volume according to our cluster activation rules (using lv_active_change() for this).
2014-11-05 17:15:07 +03:00
log_error("Unable to deactivate failed new LV %s. "
"Manual intervention required.", display_lvname(lv));
lvcreate parsing for thin provisioning. The rest is incomplete so this isn't usable yet.
2011-09-06 04:26:42 +04:00
return NULL;
Move _lvcreate into the internal library and rename to lv_create_single. After some refactorings, we can now move the bulk of _lvcreate into the internal library, and we can call from liblvm. In the future, we should refactor lv_create_single further, probably by segtype, to reduce the size of struct lvcreate_params. For now this is a reasonable refactor and allows us to re-use the function from liblvm. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-07-26 06:33:35 +04:00
}
revert_new_lv:
cov: check return value Log problems on fail path.
2021-04-22 18:00:45 +03:00
if (!lockd_lv(cmd, lv, "un", LDLV_PERSISTENT))
log_warn("WARNING: Failed to unlock %s.", display_lvname(lv));
lvmlockd: fix reverting new lv in error path The wrong name was being used to free the LV lock in lvmlockd in the error exit path.
2018-05-31 23:35:48 +03:00
lockd_free_lv(vg->cmd, vg, lv->name, &lv->lvid.id[1], lv->lock_args);
Add lvmlockd
2015-03-05 23:00:44 +03:00
Move _lvcreate into the internal library and rename to lv_create_single. After some refactorings, we can now move the bulk of _lvcreate into the internal library, and we can call from liblvm. In the future, we should refactor lv_create_single further, probably by segtype, to reduce the size of struct lvcreate_params. For now this is a reasonable refactor and allows us to re-use the function from liblvm. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-07-26 06:33:35 +04:00
/* FIXME Better to revert to backup of metadata? */
lv_manip: avoid removing LV when converting In some cases we use 'creation' also during conversion. Here it can be actually unwanted side effect we may remove not just newly created layers - but also original converted LV. So until we make clear how to properly revert from some errors in middle of conversion, disable removal for any 'lvconvert' commands.
2021-02-17 13:09:41 +03:00
/* Do not remove anything for create during conversion operation */
if (!strncmp(cmd->name, "lvconvert", 9) ||
!lv_remove(lv) || !vg_write(vg) || !vg_commit(vg))
Move _lvcreate into the internal library and rename to lv_create_single. After some refactorings, we can now move the bulk of _lvcreate into the internal library, and we can call from liblvm. In the future, we should refactor lv_create_single further, probably by segtype, to reduce the size of struct lvcreate_params. For now this is a reasonable refactor and allows us to re-use the function from liblvm. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-07-26 06:33:35 +04:00
log_error("Manual intervention may be required to remove "
"abandoned LV(s) before retrying.");
lvcreate parsing for thin provisioning. The rest is incomplete so this isn't usable yet.
2011-09-06 04:26:42 +04:00
return NULL;
Move _lvcreate into the internal library and rename to lv_create_single. After some refactorings, we can now move the bulk of _lvcreate into the internal library, and we can call from liblvm. In the future, we should refactor lv_create_single further, probably by segtype, to reduce the size of struct lvcreate_params. For now this is a reasonable refactor and allows us to re-use the function from liblvm. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-07-26 06:33:35 +04:00
}
liblvm: internal API change Return LV/NULL instead of 1/0 which saves lookup for created LV.
2012-11-13 13:49:32 +04:00
struct logical_volume *lv_create_single(struct volume_group *vg,
struct lvcreate_params *lp)
lvcreate parsing for thin provisioning. The rest is incomplete so this isn't usable yet.
2011-09-06 04:26:42 +04:00
{
lvcreate: new validation code Refactor lvcreate code. Prefer to use arg_outside_list_is_set() so we get automatic 'white-list' validation of supported options with different segment types. Drop used lp->cache, lp->cache and use seg_is_cache(), seg_is_thin() Draw clear border where is the last moment we could change create segment type. When segment type is given with --type - do not allow it to be changed later. Put together tests related to individual segment types. Finish cache conversion at proper part of lv_manip code after the vg_metadata are written - so we could correcly clean-up created stripe LV for cache volume.
2014-10-24 17:26:41 +04:00
const struct segment_type *segtype;
lvcreate parsing for thin provisioning. The rest is incomplete so this isn't usable yet.
2011-09-06 04:26:42 +04:00
struct logical_volume *lv;
cache: improve creation code Move code to better locations. Improve test and remove invalid ones (i.e. no reason to require cache size to be >= then origin). Correctly comment where the code is doing actual conversion of other existing volume - we do already a similar thing with external origins. Lots of new command line options and combinations is now supported. Hopefully older syntax still works as well. lvcreate --cache --cachepool vg/pool -l1 lvcreate --type cache --cachepool vg/pool -l1 lvcreate --type cache-pool vg/pool -l1 lvcreate --type cache-pool --name pool vg -l1 ... and many many more ...
2014-10-04 01:51:54 +04:00
/* Create pool first if necessary */
lvcreate: new validation code Refactor lvcreate code. Prefer to use arg_outside_list_is_set() so we get automatic 'white-list' validation of supported options with different segment types. Drop used lp->cache, lp->cache and use seg_is_cache(), seg_is_thin() Draw clear border where is the last moment we could change create segment type. When segment type is given with --type - do not allow it to be changed later. Put together tests related to individual segment types. Finish cache conversion at proper part of lv_manip code after the vg_metadata are written - so we could correcly clean-up created stripe LV for cache volume.
2014-10-24 17:26:41 +04:00
if (lp->create_pool && !seg_is_pool(lp)) {
segtype = lp->segtype;
if (seg_is_thin_volume(lp)) {
segtypes: Use SEG_TYPE_NAME_ string constants.
2015-09-22 21:04:12 +03:00
if (!(lp->segtype = get_segtype_from_string(vg->cmd, SEG_TYPE_NAME_THIN_POOL)))
lvcreate: regression fix on lv name limits When we are given an existing LV name - it needs to be allowed to pass in even restricted name as the LV could have existed long before we introduced some new restriction on prefix/suffix.i Fix the regression on name limits and drop restriction to be applied on any existing LVs - only the new created LV names have to be complient with current name restrictions. FIXME: we are currently using restricted names incorrectly in few other places - device_is_usable() skips restricted names, and udev flags are also incorrectly set for restricted names so these LVs are not getting links properly.
2014-10-07 17:41:54 +04:00
return_NULL;
lvmlockd: enable lvcreate of thin pool and thin lv in one command Previously, thin pools and thin lvs need needed to be created with separate commands, now the combined command is permitted.
2018-05-25 20:53:53 +03:00
/* We want a lockd lock for the new thin pool, but not the thin lv. */
lp->needs_lockd_init = 1;
cleanup: rename _name, _lv and _size Use some standard names for lv char * names, logical_volume * lv and sizes internally.
2014-10-07 12:43:47 +04:00
if (!(lv = _lv_create_an_lv(vg, lp, lp->pool_name)))
cache: improve creation code Move code to better locations. Improve test and remove invalid ones (i.e. no reason to require cache size to be >= then origin). Correctly comment where the code is doing actual conversion of other existing volume - we do already a similar thing with external origins. Lots of new command line options and combinations is now supported. Hopefully older syntax still works as well. lvcreate --cache --cachepool vg/pool -l1 lvcreate --type cache --cachepool vg/pool -l1 lvcreate --type cache-pool vg/pool -l1 lvcreate --type cache-pool --name pool vg -l1 ... and many many more ...
2014-10-04 01:51:54 +04:00
return_NULL;
lvmlockd: enable lvcreate of thin pool and thin lv in one command Previously, thin pools and thin lvs need needed to be created with separate commands, now the combined command is permitted.
2018-05-25 20:53:53 +03:00
lp->needs_lockd_init = 0;
lvcreate: new validation code Refactor lvcreate code. Prefer to use arg_outside_list_is_set() so we get automatic 'white-list' validation of supported options with different segment types. Drop used lp->cache, lp->cache and use seg_is_cache(), seg_is_thin() Draw clear border where is the last moment we could change create segment type. When segment type is given with --type - do not allow it to be changed later. Put together tests related to individual segment types. Finish cache conversion at proper part of lv_manip code after the vg_metadata are written - so we could correcly clean-up created stripe LV for cache volume.
2014-10-24 17:26:41 +04:00
} else if (seg_is_cache(lp)) {
if (!lp->origin_name) {
/* Until we have --pooldatasize we are lost */
log_error(INTERNAL_ERROR "Unsupported creation of cache and cache pool volume.");
return NULL;
}
/* origin_name is defined -> creates cache LV with new cache pool */
segtypes: Use SEG_TYPE_NAME_ string constants.
2015-09-22 21:04:12 +03:00
if (!(lp->segtype = get_segtype_from_string(vg->cmd, SEG_TYPE_NAME_CACHE_POOL)))
lvcreate: regression fix on lv name limits When we are given an existing LV name - it needs to be allowed to pass in even restricted name as the LV could have existed long before we introduced some new restriction on prefix/suffix.i Fix the regression on name limits and drop restriction to be applied on any existing LVs - only the new created LV names have to be complient with current name restrictions. FIXME: we are currently using restricted names incorrectly in few other places - device_is_usable() skips restricted names, and udev flags are also incorrectly set for restricted names so these LVs are not getting links properly.
2014-10-07 17:41:54 +04:00
return_NULL;
cleanup: rename _name, _lv and _size Use some standard names for lv char * names, logical_volume * lv and sizes internally.
2014-10-07 12:43:47 +04:00
if (!(lv = _lv_create_an_lv(vg, lp, lp->pool_name)))
cache: improve creation code Move code to better locations. Improve test and remove invalid ones (i.e. no reason to require cache size to be >= then origin). Correctly comment where the code is doing actual conversion of other existing volume - we do already a similar thing with external origins. Lots of new command line options and combinations is now supported. Hopefully older syntax still works as well. lvcreate --cache --cachepool vg/pool -l1 lvcreate --type cache --cachepool vg/pool -l1 lvcreate --type cache-pool vg/pool -l1 lvcreate --type cache-pool --name pool vg -l1 ... and many many more ...
2014-10-04 01:51:54 +04:00
return_NULL;
cleanup: just switch error path Check for error case in if() like we normally do. Let code continue on success.
2016-05-06 00:12:30 +03:00
if (!lv_is_cache(lv)) {
log_error(INTERNAL_ERROR "Logical volume is not cache %s.",
display_lvname(lv));
return NULL;
cache: improve creation code Move code to better locations. Improve test and remove invalid ones (i.e. no reason to require cache size to be >= then origin). Correctly comment where the code is doing actual conversion of other existing volume - we do already a similar thing with external origins. Lots of new command line options and combinations is now supported. Hopefully older syntax still works as well. lvcreate --cache --cachepool vg/pool -l1 lvcreate --type cache --cachepool vg/pool -l1 lvcreate --type cache-pool vg/pool -l1 lvcreate --type cache-pool --name pool vg -l1 ... and many many more ...
2014-10-04 01:51:54 +04:00
}
cleanup: just switch error path Check for error case in if() like we normally do. Let code continue on success.
2016-05-06 00:12:30 +03:00
/* Convertion via lvcreate */
log_print_unless_silent("Logical volume %s is now cached.",
display_lvname(lv));
return lv;
vdo: introduce segment types and manip functions Core functionality introducing lvm VDO support.
2018-06-29 12:11:14 +03:00
} else if (seg_is_vdo(lp)) {
/* The VDO segment needs VDO pool which is layer above created striped data LV */
if (!(lp->segtype = get_segtype_from_string(vg->cmd, SEG_TYPE_NAME_VDO_POOL)))
return_NULL;
lvmlockd vdo: add support lvmlockd handling for vdo lv and vdo pool is like thin lv and thin pool.
2020-09-29 22:33:44 +03:00
/* We want a lockd lock for the new vdo pool, but not the vdo lv. */
lp->needs_lockd_init = 1;
vdo: with created names use vpool When user create vdo-pool - use different automatic name. So unlike with traditional LVs using lvol0, lvol1 use vpool0, vpool1... TODO: apply similar for thin-pool & cache-pool...
2018-07-03 21:14:48 +03:00
/* Use vpool names for vdo-pool */
if (!(lv = _lv_create_an_lv(vg, lp, lp->pool_name ? : "vpool%d")))
vdo: introduce segment types and manip functions Core functionality introducing lvm VDO support.
2018-06-29 12:11:14 +03:00
return_NULL;
lvmlockd vdo: add support lvmlockd handling for vdo lv and vdo pool is like thin lv and thin pool.
2020-09-29 22:33:44 +03:00
lp->needs_lockd_init = 0;
lvcreate: new validation code Refactor lvcreate code. Prefer to use arg_outside_list_is_set() so we get automatic 'white-list' validation of supported options with different segment types. Drop used lp->cache, lp->cache and use seg_is_cache(), seg_is_thin() Draw clear border where is the last moment we could change create segment type. When segment type is given with --type - do not allow it to be changed later. Put together tests related to individual segment types. Finish cache conversion at proper part of lv_manip code after the vg_metadata are written - so we could correcly clean-up created stripe LV for cache volume.
2014-10-24 17:26:41 +04:00
} else {
log_error(INTERNAL_ERROR "Creation of pool for unsupported segment type %s.",
lp->segtype->name);
cache: improve creation code Move code to better locations. Improve test and remove invalid ones (i.e. no reason to require cache size to be >= then origin). Correctly comment where the code is doing actual conversion of other existing volume - we do already a similar thing with external origins. Lots of new command line options and combinations is now supported. Hopefully older syntax still works as well. lvcreate --cache --cachepool vg/pool -l1 lvcreate --type cache --cachepool vg/pool -l1 lvcreate --type cache-pool vg/pool -l1 lvcreate --type cache-pool --name pool vg -l1 ... and many many more ...
2014-10-04 01:51:54 +04:00
return NULL;
}
lvcreate: new validation code Refactor lvcreate code. Prefer to use arg_outside_list_is_set() so we get automatic 'white-list' validation of supported options with different segment types. Drop used lp->cache, lp->cache and use seg_is_cache(), seg_is_thin() Draw clear border where is the last moment we could change create segment type. When segment type is given with --type - do not allow it to be changed later. Put together tests related to individual segment types. Finish cache conversion at proper part of lv_manip code after the vg_metadata are written - so we could correcly clean-up created stripe LV for cache volume.
2014-10-24 17:26:41 +04:00
lp->pool_name = lv->name;
lp->segtype = segtype;
lvcreate parsing for thin provisioning. The rest is incomplete so this isn't usable yet.
2011-09-06 04:26:42 +04:00
}
if (!(lv = _lv_create_an_lv(vg, lp, lp->lv_name)))
cache: improve creation code Move code to better locations. Improve test and remove invalid ones (i.e. no reason to require cache size to be >= then origin). Correctly comment where the code is doing actual conversion of other existing volume - we do already a similar thing with external origins. Lots of new command line options and combinations is now supported. Hopefully older syntax still works as well. lvcreate --cache --cachepool vg/pool -l1 lvcreate --type cache --cachepool vg/pool -l1 lvcreate --type cache-pool vg/pool -l1 lvcreate --type cache-pool --name pool vg -l1 ... and many many more ...
2014-10-04 01:51:54 +04:00
return_NULL;
lvcreate parsing for thin provisioning. The rest is incomplete so this isn't usable yet.
2011-09-06 04:26:42 +04:00
lvcreate: better logging for temporary device Hide creation of temporary LVs and print them only in verbose mode. e.g. hides confusing message about creation of _pmspare device during creation of pool.
2014-10-20 23:53:48 +04:00
if (lp->temporary)
log_verbose("Temporary logical volume \"%s\" created.", lv->name);
else
log_print_unless_silent("Logical volume \"%s\" created.", lv->name);
lvcreate parsing for thin provisioning. The rest is incomplete so this isn't usable yet.
2011-09-06 04:26:42 +04:00
liblvm: internal API change Return LV/NULL instead of 1/0 which saves lookup for created LV.
2012-11-13 13:49:32 +04:00
return lv;
lvcreate parsing for thin provisioning. The rest is incomplete so this isn't usable yet.
2011-09-06 04:26:42 +04:00
}
Copy Permalink