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:
parent
e2be77fc40
commit
7062978bdf
@ -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.
|
||||
|
@ -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 ]
|
||||
|
@ -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,
|
||||
|
@ -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.)
|
||||
|
@ -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.)
|
||||
|
@ -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.)
|
||||
|
@ -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.)
|
||||
|
@ -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.)
|
||||
|
Loading…
x
Reference in New Issue
Block a user