1
0
mirror of git://sourceware.org/git/lvm2.git synced 2025-03-08 08:58:50 +03:00

build: make generate

This commit is contained in:
Marian Csontos 2018-12-18 15:06:09 +01:00
parent e2be77fc40
commit 7062978bdf
8 changed files with 86 additions and 177 deletions

View File

@ -185,24 +185,19 @@ devices {
fw_raid_component_detection = 0
# Configuration option devices/md_chunk_alignment.
# Align the start of a PV data area with md device's stripe-width.
# Align PV data blocks with md device's stripe-width.
# This applies if a PV is placed directly on an md device.
# default_data_alignment will be overriden if it is not aligned
# with the value detected for this setting.
# This setting is overriden by data_alignment_detection,
# data_alignment, and the --dataalignment option.
md_chunk_alignment = 1
# Configuration option devices/default_data_alignment.
# Align the start of a PV data area with this number of MiB.
# Set to 1 for 1MiB, 2 for 2MiB, etc. Set to 0 to disable.
# This setting is overriden by data_alignment and the --dataalignment
# option.
# Default alignment of the start of a PV data area in MB.
# If set to 0, a value of 64KiB will be used.
# Set to 1 for 1MiB, 2 for 2MiB, etc.
# This configuration option has an automatic default value.
# default_data_alignment = 1
# Configuration option devices/data_alignment_detection.
# Align the start of a PV data area with sysfs io properties.
# Detect PV data alignment based on sysfs device information.
# The start of a PV data area will be a multiple of minimum_io_size or
# optimal_io_size exposed in sysfs. minimum_io_size is the smallest
# request the device can perform without incurring a read-modify-write
@ -210,29 +205,27 @@ devices {
# preferred unit of receiving I/O, e.g. MD stripe width.
# minimum_io_size is used if optimal_io_size is undefined (0).
# If md_chunk_alignment is enabled, that detects the optimal_io_size.
# default_data_alignment and md_chunk_alignment will be overriden
# if they are not aligned with the value detected for this setting.
# This setting is overriden by data_alignment and the --dataalignment
# option.
# This setting takes precedence over md_chunk_alignment.
data_alignment_detection = 1
# Configuration option devices/data_alignment.
# Align the start of a PV data area with this number of KiB.
# When non-zero, this setting overrides default_data_alignment.
# Set to 0 to disable, in which case default_data_alignment
# is used to align the first PE in units of MiB.
# This setting is overriden by the --dataalignment option.
# Alignment of the start of a PV data area in KiB.
# If a PV is placed directly on an md device and md_chunk_alignment or
# data_alignment_detection are enabled, then this setting is ignored.
# Otherwise, md_chunk_alignment and data_alignment_detection are
# disabled if this is set. Set to 0 to use the default alignment or the
# page size, if larger.
data_alignment = 0
# Configuration option devices/data_alignment_offset_detection.
# Shift the start of an aligned PV data area based on sysfs information.
# After a PV data area is aligned, it will be shifted by the
# Detect PV data alignment offset based on sysfs device information.
# The start of a PV aligned data area will be shifted by the
# alignment_offset exposed in sysfs. This offset is often 0, but may
# be non-zero. Certain 4KiB sector drives that compensate for windows
# partitioning will have an alignment_offset of 3584 bytes (sector 7
# is the lowest aligned logical block, the 4KiB sectors start at
# LBA -1, and consequently sector 63 is aligned on a 4KiB boundary).
# This setting is overriden by the --dataalignmentoffset option.
# pvcreate --dataalignmentoffset will skip this detection.
data_alignment_offset_detection = 1
# Configuration option devices/ignore_suspended_devices.
@ -1647,20 +1640,13 @@ activation {
# vgmetadatacopies = 0
# Configuration option metadata/pvmetadatasize.
# The default size of the metadata area in units of 512 byte sectors.
# The metadata area begins at an offset of the page size from the start
# of the device. The first PE is by default at 1 MiB from the start of
# the device. The space between these is the default metadata area size.
# The actual size of the metadata area may be larger than what is set
# here due to default_data_alignment making the first PE a MiB multiple.
# The metadata area begins with a 512 byte header and is followed by a
# circular buffer used for VG metadata text. The maximum size of the VG
# metadata is about half the size of the metadata buffer. VGs with large
# numbers of PVs or LVs, or VGs containing complex LV structures, may need
# additional space for VG metadata. The --metadatasize option overrides
# this setting.
# This configuration option does not have a default value defined.
# Approximate number of sectors to use for each metadata copy.
# VGs with large numbers of PVs or LVs, or VGs containing complex LV
# structures, may need additional space for VG metadata. The metadata
# areas are treated as circular buffers, so unused space becomes filled
# with an archive of the most recent previous versions of the metadata.
# This configuration option has an automatic default value.
# pvmetadatasize = 255
# Configuration option metadata/pvmetadataignore.
# Ignore metadata areas on a new PV.

View File

@ -567,7 +567,7 @@ Convert LV to a thin LV, using the original LV as an external origin.
.br
-
Attach a cache to an LV, converts the LV to type cache.
Convert LV to type cache.
.br
.P
\fBlvconvert\fP \fB--type\fP \fBcache\fP \fB--cachepool\fP \fILV\fP \fILV\fP\fI_linear_striped_thinpool_raid\fP
@ -626,21 +626,6 @@ Attach a cache to an LV, converts the LV to type cache.
.br
-
Attach a writecache to an LV, converts the LV to type writecache.
.br
.P
\fBlvconvert\fP \fB--type\fP \fBwritecache\fP \fB--cachepool\fP \fILV\fP \fILV\fP\fI_linear_striped_raid\fP
.br
.RS 4
.ad l
[ \fB--cachesettings\fP \fIString\fP ]
.ad b
.br
[ COMMON_OPTIONS ]
.RE
.br
-
Convert LV to type thin-pool.
.br
.P
@ -780,10 +765,10 @@ Convert LV to type vdopool.
.br
-
Detach a cache from an LV.
Separate and keep the cache pool from a cache LV.
.br
.P
\fBlvconvert\fP \fB--splitcache\fP \fILV\fP\fI_thinpool_cache_cachepool_writecache\fP
\fBlvconvert\fP \fB--splitcache\fP \fILV\fP\fI_thinpool_cache_cachepool\fP
.br
.RS 4
[ COMMON_OPTIONS ]
@ -1688,7 +1673,7 @@ Convert LV to a thin LV, using the original LV as an external origin
.br
-
Attach a cache to an LV (infers --type cache).
Convert LV to type cache (infers --type cache).
.br
.P
\fBlvconvert\fP \fB-H\fP|\fB--cache\fP \fB--cachepool\fP \fILV\fP \fILV\fP\fI_linear_striped_thinpool_raid\fP
@ -1778,10 +1763,10 @@ Convert LV to type vdopool.
.br
-
Detach and delete a cache from an LV.
Separate and delete the cache pool from a cache LV.
.br
.P
\fBlvconvert\fP \fB--uncache\fP \fILV\fP\fI_thinpool_cache_writecache\fP
\fBlvconvert\fP \fB--uncache\fP \fILV\fP\fI_thinpool_cache\fP
.br
.RS 4
[ COMMON_OPTIONS ]

View File

@ -569,8 +569,8 @@ Inconsistencies are detected by initiating a "check" on a RAID logical volume.
(The scrubbing operations, "check" and "repair", can be performed on a RAID
logical volume via the 'lvchange' command.) (w)ritemostly signifies the
devices in a RAID 1 logical volume that have been marked write-mostly.
Re(s)haping shows a Raid Logical Volume is undergoing a reshape (ie. striped
addition/removal, stripe size or RAID algorithm change).
Re(s)haping signifies a RAID Logical Volume is either undergoing a stripe
addition/removal, a stripe size or RAID algorithm change.
(R)emove after reshape signifies freed striped raid images to be removed.
.IP
Related to Thin pool Logical Volumes: (F)ailed, out of (D)ata space,

View File

@ -8,84 +8,27 @@ pvcreate - Initialize physical volume(s) for use by LVM
[ \fIoption_args\fP ]
.br
.SH DESCRIPTION
pvcreate initializes a Physical Volume (PV) on a device so the device is
recognized as belonging to LVM. This allows the PV to be used in a Volume
Group (VG). An LVM disk label is written to the device, and LVM metadata
areas are initialized. A PV can be placed on a whole device or partition.
pvcreate initializes a PV so that it is recognized as belonging to LVM,
and allows the PV to be used in a VG. A PV can be a disk partition, whole
disk, meta device, or loopback file.
For DOS disk partitions, the partition id should be set to 0x8e using
.BR fdisk (8),
.BR cfdisk (8),
or a equivalent. For GUID Partition Table (GPT), the id is
E6D6D379-F507-44C2-A23C-238F2A3DF928. For
whole disk devices only
the partition table must be erased, which will effectively destroy all
data on that disk. This can be done by zeroing the first sector with:
.BI "dd if=/dev/zero of=" PhysicalVolume " bs=512 count=1"
Use \fBvgcreate\fP(8) to create a new VG on the PV, or \fBvgextend\fP(8)
to add the PV to an existing VG. Use \fBpvremove\fP(8) to remove the LVM
disk label from the device.
to add the PV to existing VG.
The force option will create a PV without confirmation. Repeating the
force option (\fB-ff\fP) will forcibly create a PV, overriding checks that
normally prevent it, e.g. if the PV is already in a VG.
.B Metadata location, size, and alignment
The LVM disk label begins 512 bytes from the start of the device, and is
512 bytes in size.
The LVM metadata area begins at an offset (from the start of the device)
equal to the page size of the machine creating the PV (often 4 KiB.) The
metadata area contains a 512 byte header and a multi-KiB circular buffer
that holds text copies of the VG metadata.
With default settings, the first physical extent (PE), which contains LV
data, is 1 MiB from the start of the device. This location is controlled
by \fBdefault_data_alignment\fP in lvm.conf, which is set to 1 (MiB) by
default. The pe_start will be a multiple of this many MiB. This location
can be checked with:
.br
.B pvs -o pe_start
.I PV
The size of the LVM metadata area is the space between the the start of
the metadata area and the first PE. When metadata begins at 4 KiB and the
first PE is at 1024 KiB, the metadata area size is 1020 KiB. This can be
checked with:
.br
.B pvs -o mda_size
.I PV
The mda_size cannot be increased after pvcreate, so if larger metadata is
needed, it must be set during pvcreate. Two copies of the VG metadata
must always fit within the metadata area, so the maximum VG metadata size
is around half the mda_size. This can be checked with:
.br
.B vgs -o mda_free
.I VG
A larger metadata area can be set with --metadatasize. The resulting
mda_size may be larger than specified due to default_data_alignment
placing pe_start on a MiB boundary, and the fact that the metadata area
extends to the first PE. With metadata starting at 4 KiB and
default_data_alignment 1 (MiB), setting --metadatasize 2048k results in
pe_start of 3 MiB and mda_size of 3068 KiB. Alternatively, --metadatasize
2044k results in pe_start at 2 MiB and mda_size of 2044 KiB.
The alignment of pe_start described above may be automatically overriden
based on md device properties or device i/o properties reported in sysfs.
These automatic adjustments can be enabled/disabled using lvm.conf
settings md_chunk_alignment and data_alignment_offset_detection.
To use a different pe_start alignment, use the --dataalignment option.
The --metadatasize option would also typically be used in this case
because the metadata area size also determines the location of pe_start.
When using these two options together, pe_start is calculated as:
metadata area start (page size), plus the specified --metadatasize,
rounded up to the next multiple of --dataalignment.
With metadata starting at 4 KiB, --metadatasize 2048k, and --dataalignment 128k,
pe_start is 2176 KiB and mda_size is 2172 KiB.
The pe_start of 2176 KiB is the nearest even multiple of 128 KiB that
provides at least 2048 KiB of metadata space.
Always check the resulting alignment and metadata size when using
these options.
To shift an aligned pe_start value, use the --dataaligmentoffset option.
The pe_start alignment is calculated as described above, and then the
value specified with --dataaligmentoffset is added to produce the final
pe_start value.
.SH USAGE
\fBpvcreate\fP \fIPV\fP ...
.br
@ -218,16 +161,14 @@ Common options for lvm:
.ad l
\fB--bootloaderareasize\fP \fISize\fP[m|UNIT]
.br
Reserve space for the bootloader between the LVM metadata area and the first PE.
The bootloader area is reserved for bootloaders to embed their own data or
metadata; LVM will not use it.
The bootloader area begins where the first PE would otherwise be located.
The first PE is moved out by the size of the bootloader area, and then moved
out further if necessary to match the data alignment.
Create a separate bootloader area of specified size besides PV's data
area. The bootloader area is an area of reserved space on the PV from
which LVM will not allocate any extents and it's kept untouched. This is
primarily aimed for use with bootloaders to embed their own data or metadata.
The start of the bootloader area is always aligned, see also --dataalignment
and --dataalignmentoffset. The bootloader area may be larger than requested
due to the alignment, but it's never less than the requested size.
To see the bootloader area start and size of
and --dataalignmentoffset. The bootloader area size may eventually
end up increased due to the alignment, but it's never less than the
size that is requested. To see the bootloader area start and size of
an existing PV use pvs -o +pv_ba_start,pv_ba_size.
.ad b
.HP
@ -250,17 +191,17 @@ See \fBlvm.conf\fP(5) for more information about config.
.ad l
\fB--dataalignment\fP \fISize\fP[k|UNIT]
.br
Align the start of a PV data area with a multiple of this number.
To see the location of the first Physical Extent (PE) of an existing PV,
use pvs -o +pe_start. In addition, it may be shifted by an alignment offset,
see --dataalignmentoffset.
Also specify an appropriate PE size when creating a VG.
Align the start of the data to a multiple of this number.
Also specify an appropriate Physical Extent size when creating a VG.
To see the location of the first Physical Extent of an existing PV,
use pvs -o +pe_start. In addition, it may be shifted by an alignment offset.
See lvm.conf/data_alignment_offset_detection and --dataalignmentoffset.
.ad b
.HP
.ad l
\fB--dataalignmentoffset\fP \fISize\fP[k|UNIT]
.br
Shift the start of the PV data area by this additional offset.
Shift the start of the data area by this additional offset.
.ad b
.HP
.ad l
@ -362,7 +303,8 @@ on the command.
The number of metadata areas to set aside on a PV for storing VG metadata.
When 2, one copy of the VG metadata is stored at the front of the PV
and a second copy is stored at the end.
When 1, one copy of the VG metadata is stored at the front of the PV.
When 1, one copy of the VG metadata is stored at the front of the PV
(starting in the 5th sector).
When 0, no copies of the VG metadata are stored on the given PV.
This may be useful in VGs containing many PVs (this places limitations
on the ability to use vgsplit later.)

View File

@ -912,7 +912,8 @@ on the command.
The number of metadata areas to set aside on a PV for storing VG metadata.
When 2, one copy of the VG metadata is stored at the front of the PV
and a second copy is stored at the end.
When 1, one copy of the VG metadata is stored at the front of the PV.
When 1, one copy of the VG metadata is stored at the front of the PV
(starting in the 5th sector).
When 0, no copies of the VG metadata are stored on the given PV.
This may be useful in VGs containing many PVs (this places limitations
on the ability to use vgsplit later.)

View File

@ -111,16 +111,14 @@ Common options for lvm:
.ad l
\fB--bootloaderareasize\fP \fISize\fP[m|UNIT]
.br
Reserve space for the bootloader between the LVM metadata area and the first PE.
The bootloader area is reserved for bootloaders to embed their own data or
metadata; LVM will not use it.
The bootloader area begins where the first PE would otherwise be located.
The first PE is moved out by the size of the bootloader area, and then moved
out further if necessary to match the data alignment.
Create a separate bootloader area of specified size besides PV's data
area. The bootloader area is an area of reserved space on the PV from
which LVM will not allocate any extents and it's kept untouched. This is
primarily aimed for use with bootloaders to embed their own data or metadata.
The start of the bootloader area is always aligned, see also --dataalignment
and --dataalignmentoffset. The bootloader area may be larger than requested
due to the alignment, but it's never less than the requested size.
To see the bootloader area start and size of
and --dataalignmentoffset. The bootloader area size may eventually
end up increased due to the alignment, but it's never less than the
size that is requested. To see the bootloader area start and size of
an existing PV use pvs -o +pv_ba_start,pv_ba_size.
.ad b
.HP
@ -223,7 +221,8 @@ on the command.
The number of metadata areas to set aside on a PV for storing VG metadata.
When 2, one copy of the VG metadata is stored at the front of the PV
and a second copy is stored at the end.
When 1, one copy of the VG metadata is stored at the front of the PV.
When 1, one copy of the VG metadata is stored at the front of the PV
(starting in the 5th sector).
When 0, no copies of the VG metadata are stored on the given PV.
This may be useful in VGs containing many PVs (this places limitations
on the ability to use vgsplit later.)

View File

@ -12,12 +12,6 @@ vgcreate creates a new VG on block devices. If the devices were not
previously intialized as PVs with \fBpvcreate\fP(8), vgcreate will
inititialize them, making them PVs. The pvcreate options for initializing
devices are also available with vgcreate.
When vgcreate uses an existing PV, that PV's existing values for metadata
size, PE start, etc, are used, even if different values are specified in
the vgcreate command. To change these values, first use pvremove on the
device.
.SH USAGE
\fBvgcreate\fP \fIVG\fP\fI_new\fP \fIPV\fP ...
.br
@ -232,17 +226,17 @@ See \fBlvm.conf\fP(5) for more information about config.
.ad l
\fB--dataalignment\fP \fISize\fP[k|UNIT]
.br
Align the start of a PV data area with a multiple of this number.
To see the location of the first Physical Extent (PE) of an existing PV,
use pvs -o +pe_start. In addition, it may be shifted by an alignment offset,
see --dataalignmentoffset.
Also specify an appropriate PE size when creating a VG.
Align the start of the data to a multiple of this number.
Also specify an appropriate Physical Extent size when creating a VG.
To see the location of the first Physical Extent of an existing PV,
use pvs -o +pe_start. In addition, it may be shifted by an alignment offset.
See lvm.conf/data_alignment_offset_detection and --dataalignmentoffset.
.ad b
.HP
.ad l
\fB--dataalignmentoffset\fP \fISize\fP[k|UNIT]
.br
Shift the start of the PV data area by this additional offset.
Shift the start of the data area by this additional offset.
.ad b
.HP
.ad l
@ -368,7 +362,8 @@ on the command.
The number of metadata areas to set aside on a PV for storing VG metadata.
When 2, one copy of the VG metadata is stored at the front of the PV
and a second copy is stored at the end.
When 1, one copy of the VG metadata is stored at the front of the PV.
When 1, one copy of the VG metadata is stored at the front of the PV
(starting in the 5th sector).
When 0, no copies of the VG metadata are stored on the given PV.
This may be useful in VGs containing many PVs (this places limitations
on the ability to use vgsplit later.)

View File

@ -162,17 +162,17 @@ See \fBlvm.conf\fP(5) for more information about config.
.ad l
\fB--dataalignment\fP \fISize\fP[k|UNIT]
.br
Align the start of a PV data area with a multiple of this number.
To see the location of the first Physical Extent (PE) of an existing PV,
use pvs -o +pe_start. In addition, it may be shifted by an alignment offset,
see --dataalignmentoffset.
Also specify an appropriate PE size when creating a VG.
Align the start of the data to a multiple of this number.
Also specify an appropriate Physical Extent size when creating a VG.
To see the location of the first Physical Extent of an existing PV,
use pvs -o +pe_start. In addition, it may be shifted by an alignment offset.
See lvm.conf/data_alignment_offset_detection and --dataalignmentoffset.
.ad b
.HP
.ad l
\fB--dataalignmentoffset\fP \fISize\fP[k|UNIT]
.br
Shift the start of the PV data area by this additional offset.
Shift the start of the data area by this additional offset.
.ad b
.HP
.ad l
@ -267,7 +267,8 @@ on the command.
The number of metadata areas to set aside on a PV for storing VG metadata.
When 2, one copy of the VG metadata is stored at the front of the PV
and a second copy is stored at the end.
When 1, one copy of the VG metadata is stored at the front of the PV.
When 1, one copy of the VG metadata is stored at the front of the PV
(starting in the 5th sector).
When 0, no copies of the VG metadata are stored on the given PV.
This may be useful in VGs containing many PVs (this places limitations
on the ability to use vgsplit later.)