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
4310dfd4e1
lvm2/lib/metadata/lv_alloc.h

87 lines
3.3 KiB
C
Raw Normal View History

Improve segment merge/split code.
2003-09-15 22:22:50 +04:00
/*
Update copyright notices.
2004-03-30 23:35:44 +04:00
* Copyright (C) 2003-2004 Sistina Software, Inc. All rights reserved.
Set missing header define
2012-01-26 02:37:48 +04:00
* Copyright (C) 2004-2012 Red Hat, Inc. All rights reserved.
Improve segment merge/split code.
2003-09-15 22:22:50 +04: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,
* Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
Improve segment merge/split code.
2003-09-15 22:22:50 +04:00
*/
#ifndef _LVM_LV_ALLOC_H
Set missing header define
2012-01-26 02:37:48 +04:00
#define _LVM_LV_ALLOC_H
Improve segment merge/split code.
2003-09-15 22:22:50 +04:00
cleanup: self compilable headers
2012-01-26 02:26:33 +04:00
#include "metadata-exported.h"
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,
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,
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);
extend alloc_lv_segment
2005-04-22 19:44:00 +04:00
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);
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);
Various allocation-related pvmove fixes.
2005-06-14 21:54:48 +04:00
int move_lv_segment_area(struct lv_segment *seg_to, uint32_t area_to,
struct lv_segment *seg_from, uint32_t 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
int release_lv_segment_area(struct lv_segment *seg, uint32_t s,
uint32_t area_reduction);
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);
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
struct alloc_handle;
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,
Calculate mirror log size instead of hardcoding 1 extent size. It fails for 1k PE now. Patch adds log_region_size into allocation habdle struct and use it in _alloc_parallel_area() for proper log size calculation instead of hardcoded 1 extent - which can fail. Reproducer for incorrect log size calculation: DEV=/dev/sd[bcd] pvcreate $DEV vgcreate -s 1k vg_test $DEV lvcreate -m1 -L 12M -n mirr vg_test https://bugzilla.redhat.com/show_bug.cgi?id=477040 The log size calculation is mostly copied from kernel code.
2008-12-19 18:24:52 +03:00
uint32_t log_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
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);
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
int lv_add_mirror_areas(struct alloc_handle *ah,
struct logical_volume *lv, uint32_t le,
uint32_t region_size);
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
int lv_add_segmented_mirror_image(struct alloc_handle *ah,
struct logical_volume *lv, uint32_t le,
uint32_t region_size);
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);
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);
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);
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
void alloc_destroy(struct alloc_handle *ah);
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
Improve segment merge/split code.
2003-09-15 22:22:50 +04:00
#endif
Copy Permalink