инструменты LVM2 (LVM2 tools)
ALLOCATION
When an operation needs to allocate Physical Extents for one or
more Logical Volumes, the tools proceed as follows:
First of all, they generate the complete set of unallocated
Physical Extents in the Volume Group. If any ranges of Physical
Extents are supplied at the end of the command line, only
unallocated Physical Extents within those ranges on the specified
Physical Volumes are considered.
Then they try each allocation policy in turn, starting with the
strictest policy (contiguous) and ending with the allocation
policy specified using --alloc or set as the default for the
particular Logical Volume or Volume Group concerned. For each
policy, working from the lowest-numbered Logical Extent of the
empty Logical Volume space that needs to be filled, they allocate
as much space as possible according to the restrictions imposed
by the policy. If more space is needed, they move on to the next
policy.
The restrictions are as follows:
Contiguous requires that the physical location of any Logical
Extent that is not the first Logical Extent of a Logical Volume
is adjacent to the physical location of the Logical Extent
immediately preceding it.
Cling requires that the Physical Volume used for any Logical
Extent to be added to an existing Logical Volume is already in
use by at least one Logical Extent earlier in that Logical
Volume. If the configuration parameter allocation/cling_tag_list
is defined, then two Physical Volumes are considered to match if
any of the listed tags is present on both Physical Volumes. This
allows groups of Physical Volumes with similar properties (such
as their physical location) to be tagged and treated as
equivalent for allocation purposes.
When a Logical Volume is striped or mirrored, the above
restrictions are applied independently to each stripe or mirror
image (leg) that needs space.
Normal will not choose a Physical Extent that shares the same
Physical Volume as a Logical Extent already allocated to a
parallel Logical Volume (i.e. a different stripe or mirror
image/leg) at the same offset within that parallel Logical
Volume.
When allocating a mirror log at the same time as Logical Volumes
to hold the mirror data, Normal will first try to select
different Physical Volumes for the log and the data. If that's
not possible and the allocation/mirror_logs_require_separate_pvs
configuration parameter is set to 0, it will then allow the log
to share Physical Volume(s) with part of the data.
When allocating thin pool metadata, similar considerations to
those of a mirror log in the last paragraph apply based on the
value of the allocation/thin_pool_metadata_require_separate_pvs
configuration parameter.
If you rely upon any layout behaviour beyond that documented
here, be aware that it might change in future versions of the
code.
For example, if you supply on the command line two empty Physical
Volumes that have an identical number of free Physical Extents
available for allocation, the current code considers using each
of them in the order they are listed, but there is no guarantee
that future releases will maintain that property. If it is
important to obtain a specific layout for a particular Logical
Volume, then you should build it up through a sequence of
lvcreate(8) and lvconvert(8) steps such that the restrictions
described above applied to each step leave the tools no
discretion over the layout.
To view the way the allocation process currently works in any
specific case, read the debug logging output, for example by
adding -vvvv to a command.
