1
0
mirror of git://sourceware.org/git/lvm2.git synced 2024-12-29 15:22:30 +03:00
Commit Graph

44 Commits

Author SHA1 Message Date
Joe Thornber
7f97c7ea9a 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 10:30:20 +01:00
Zdenek Kabelac
876c4a1b3b tidy: declaration names match implementation
Put in sync some naming used for function declaration and
actual in-code implementation.
2017-07-20 19:16:41 +02:00
Heinz Mauelshagen
e2354ea344 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 05:20:58 +01:00
Zdenek Kabelac
fcbef05aae 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 12:11:37 +01:00
Zdenek Kabelac
753a496348 snapshot: relocate alloc_snapshot_seg
Move alloc_snapshot_seg to snapshot_manip and make it local static.
2016-01-14 11:34:05 +01:00
Zdenek Kabelac
ff2e8b0de6 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 18:37:13 +01:00
Jonathan Brassow
b35fb0b15a 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-25 21:20:41 -05:00
Jonathan Brassow
5ebff6cc9f 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-17 22:59:36 -05:00
Jonathan Brassow
4b6e3b5e5e 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-13 21:10:28 -06:00
Zdenek Kabelac
30a81e5989 cleanup: self compilable headers 2013-12-12 13:28:19 +01:00
Alasdair G Kergon
07a25c249b 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-27 22:12:01 +01:00
Alasdair G Kergon
a5ddb347e5 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:11:49 +01:00
Zdenek Kabelac
42beb34826 Set missing header define 2012-01-25 22:37:48 +00:00
Zdenek Kabelac
72ff89d279 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 16:02:01 +00:00
Alasdair Kergon
9ac61d2ba2 lvcreate parsing for thin provisioning.
The rest is incomplete so this isn't usable yet.
2011-09-06 00:26:42 +00:00
Jonathan Earl Brassow
7411a44871 Remove and unneeded parameter from build_parallel_areas_from_lv() 2011-07-19 16:37:42 +00:00
Alasdair Kergon
aab7a3978b 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 00:28:57 +00:00
Jonathan Earl Brassow
7a369d3704 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-26 22:15:43 +00:00
Alasdair Kergon
16d9293bd7 Extend core allocation code in preparation for mirrored log areas. 2010-03-01 20:00:20 +00:00
Dave Wysochanski
59baeb838c 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 17:48:32 +00:00
Mike Snitzer
a2552d4f59 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-24 22:55:55 +00:00
Milan Broz
6d1b3b5385 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 15:24:52 +00:00
Alasdair Kergon
2c44337bd5 Right, a simple build (without options) is working again. 2008-11-03 22:14:30 +00:00
Alasdair Kergon
72baf0c345 Maintain lists of stacked LV segments using each LV. 2008-01-16 19:00:59 +00:00
Alasdair Kergon
a69ab65278 Major restructuring of pvmove and lvconvert layer manipulation code 2007-12-20 15:42:55 +00:00
Alasdair Kergon
b680c5c677 export can_split parameter until rest of pvmove allocation restructuring gets done 2007-12-05 22:11:20 +00:00
Alasdair Kergon
940d710ece drop mirrored_pv/mirrored_pe from alloc handle 2007-11-22 14:54:35 +00:00
Alasdair Kergon
21bc366486 Clean up numerous compiler warnings that crept in recently.
Remove several unused parameters from _allocate().
2007-08-22 14:38:18 +00:00
Alasdair Kergon
be6845999b Fix inconsistent licence notices: executables are GPLv2; libraries LGPLv2.1. 2007-08-20 20:55:30 +00:00
Alasdair Kergon
72b2cb613a 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-09 21:23:51 +00:00
Alasdair Kergon
c0a33e10ae preparation for parallel_areas changes to allocation code 2005-11-24 20:58:44 +00:00
Alasdair Kergon
1817dbaf60 more mirror library functions 2005-10-28 12:48:50 +00:00
Alasdair Kergon
2262b32057 Use hash, bitset, malloc, pool from libdevmapper. 2005-10-16 23:03:59 +00:00
Alasdair Kergon
5e947dac48 Various allocation-related pvmove fixes. 2005-06-14 17:54:48 +00:00
Alasdair Kergon
8211a13ce0 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 14:49:51 +00:00
Alasdair Kergon
60f13f01d2 Basic support for mirrors. 2005-06-01 16:51:55 +00:00
Alasdair Kergon
15db9fcfbf Reinstate full PV size when removing from VG.
Support loopfiles for testing.
Complete the pv_segment support.
2005-05-03 17:28:23 +00:00
Alasdair Kergon
22c1a65f74 extend alloc_lv_segment 2005-04-22 15:44:00 +00:00
Alasdair Kergon
e40d124e14 set_lv_segment_area_pv/lv 2005-04-22 15:43:02 +00:00
Alasdair Kergon
072893aabd Internal snapshot code restructuring. 2005-04-07 12:39:44 +00:00
Alasdair Kergon
6606c3ae81 Update copyright notices. 2004-03-30 19:35:44 +00:00
Alasdair Kergon
ff6d21103b LV allocation variable renaming 2004-03-26 20:35:14 +00:00
Alasdair Kergon
842a35c7ca Remove incorrect comments. 2003-09-16 16:23:21 +00:00
Alasdair Kergon
85c1926171 Improve segment merge/split code. 2003-09-15 18:22:50 +00:00