| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The devices file, e.g. /etc/lvm/devices/lvm_devices.dat,
is a list of devices that lvm can use.
The option --devicesfile can specify a different file
with a separate set of devices for lvm to use.
This option allows different applications to use
lvm on different sets of devices.
In most cases (with limited exceptions), lvm will not
read or use a device not listed in the devices file.
When the devices file is used, the filter-regex is
not used and the filter settings in lvm.conf are
ignored. filter-deviceid is used when the devices
file is enabled and rejects any device that does not
match an entry in the devices file.
Set use_devicesfile = 0 in lvm.conf or set
--devicesfile "" on the command line to disable the
use of a devices file. When disabled, lvm will see
and use any device on the system that passes the
regex filter.
A device_id, e.g. wwid or serial number from sysfs,
is a unique ID that identifies a device without
reading it. Two devices with identical content
should have different device_ids in most common
cases. The device_id is used in the devices file
and is included in VG metadata sections.
Each device_id has a device_id_type which indicates
where the device_id comes from, e.g. "sys_wwid"
means the device_id comes from the sysfs wwid file.
Others are sys_serial, mpath_uuid, loop_file, devname.
(devname is the device path which is a fallback when
no other proper device_id_type is available.)
filter-deviceid permits lvm to use only devices
on the system that have a device_id matching a
devices file entry. Using the device_id, lvm can
determine the set of devices to use without reading
any devices, so the devices file will constrain lvm
in two ways:
1. it limits the devices that lvm will read.
2. it limits the devices that lvm will use.
In some uncommon cases, e.g. when devices have no
unique ID and device_id has to fall back to using
the devname, lvm may need to read all devices on the
system to determine which ones correspond to the
devices file entries. In this case, the devices file
does not limit the devices that lvm reads, but it does
limit the devices that lvm uses.
pvcreate/vgcreate/vgextend are not constrained by
the devices file, and will look outside it to find
the new PV. They assign the new PV a device_id
and add it to the devices file. It is also possible
to explicitly add new PVs to the devices file before
using them in pvcreate/etc, in which case these commands
would not need to access devices outside the devices file.
vgimportdevices VG looks at all devices on the system
to find an existing VG and add its devices to the
devices file. The command is not limited by an
existing devices file. The command will also add
device_ids to the VG metadata if the VG does not yet
include device_ids. vgimportdevices -a imports devices
for all accessible VGs. Since vgimportdevices does not
limit itself to devices in an existing devices file, the
lvm.conf regex filter applies. Adding --foreign will
import devices for foreign VGs, but device_ids are
not added to foreign VGs. Incomplete VGs are not
imported.
The lvmdevices command manages the devices file.
The primary purpose is to edit the devices file,
but it will read PV headers to find/check PVIDs.
(It does not read, process or modify VG metadata.)
lvmdevices
. Displays devices file entries.
lvmdevices --check
. Checks devices file entries.
lvmdevices --update
. Updates devices file entries.
lvmdevices --adddev <devname>
. Adds devices_file entry (reads pv header).
lvmdevices --deldev <devname>
. Removes devices file entry.
lvmdevices --addpvid <pvid>
. Reads pv header of all devices to find <pvid>,
and if found adds devices file entry.
lvmdevices --delpvid <pvid>
. Removes devices file entry.
TODO:
pvchange --deviceidupdate PV
vgchange --deviceidupdate VG
duplicate PV resolution using device_id
vgimportclone needs to update device file (change to pvids)
pvchange --uuid needs to update device file
search for pvid when no wwid is available and PV is missing
device_id_type for md devices
shortsystemid crc of systemid and written in pv header
use shortsystemid for new filter and orphan PV ownership
dmeventd and lvmpolld with devices file
|
| | |
|
| |
|
|
|
| |
Add man page info about this option, and add log messages
pointing to this option.
|
| |
|
|
|
|
| |
This fix can avoid bcache_fd will mistakenly open/close in later.
Signed-off-by: Zhao Heming <heming.zhao@suse.com>
|
| |
|
|
|
|
| |
This reverts commit 5410dd5441aa827b381ff64dfc6be6e4589d87a1.
Accidental push.
|
| |
|
|
|
|
|
| |
When lvconvert is used to remove raid images, we can
skip calling lv_add_integrity_to_raid(), which finds
nothing to do, but the the blocksize validation would
be called unnecessarily and trigger spurious errors.
|
| |
|
|
|
|
|
|
|
|
| |
The test was using a raid+integrity LV without
first waiting for the integrity sync, which could
cause the test to fail (depending on init speed)
where it depends on integrity to work in uninitialized
areas.
Also use cmp instead of diff.
|
| |
|
|
|
|
|
|
| |
pvck --dump headers reads the metadata text area
to compute the text metadata checksum to compare
with the mda_header checksum.
The new header_only will skip reading the metadata
text and not validate the mda_header checksum.
|
| |
|
|
|
| |
The first leg of integrity enabled raid device sometimes does not get
recalculated.
|
| |
|
|
|
| |
Check if LV is an existing cachevol before attempting
to use it again as a cachevol or cachepool.
|
| | |
|
| |
|
|
| |
...to avoid unnecessary dependency on python
|
| | |
|
| | |
|
| |
|
|
|
| |
Trying to avoid collision with udev watch rule preventing to
succeed 'dmsetup remove' becuase it keeps device open.
|
| |
|
|
| |
Reuse macro
|
| |
|
|
|
|
|
| |
arg_str_value() has built-in arg_is_set().
Also this makes it obvious to coverity 'dump != NULL' & 'repair != NULL'
at the branch code path.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
and free on a couple error paths.
|
| |
|
|
|
|
|
|
| |
It's possible for a dev-cache entry to remain after all
paths for it have been removed, and other parts of the
code expect that a dev always has a name. A better fix
may be to remove a device from dev-cache after all paths
to it have been removed.
|
| |
|
|
|
|
|
|
|
|
| |
When either logical block size or physical block size is 4K,
then lvmlockd creates sanlock leases based on 4K sectors,
but the lvm client side would create the internal lvmlock LV
based on the first logical block size it saw in the VG,
which could be 512. This could cause the lvmlock LV to be
too small to hold all the sanlock leases. Make the lvm client
side use the same sizing logic as lvmlockd.
|
| | |
|
| |
|
|
|
|
|
| |
The lock adopt feature was disabled since it had used
lvmetad as a source of info. This replaces the lvmetad
info with a local file and enables the adopt feature again
(enabled with lvmlockd --adopt 1).
|
| |
|
|
| |
Once converted results to error numbers but is now just a null check.
|
| |
|
|
|
|
| |
Filters are changed and need refresh in only one
place (vgimportclone), so avoid doing the refresh
for every other command that doesn't need it.
|
| |
|
|
|
|
| |
The --lock-opt autowait was dropped back in 9ab6bdce01,
and attempting to specify it has quite an opposite effect:
no waiting is done, which makes the unit almost useless.
|
| |
|
|
|
|
| |
The previous method of managing duplicate vgnames prevented
vgreduce from working if a foreign vg with the same name
existed.
|
| |
|
|
| |
no functional change
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
dm-integrity stores checksums of the data written to an
LV, and returns an error if data read from the LV does
not match the previously saved checksum. When used on
raid images, dm-raid will correct the error by reading
the block from another image, and the device user sees
no error. The integrity metadata (checksums) are stored
on an internal LV allocated by lvm for each linear image.
The internal LV is allocated on the same PV as the image.
Create a raid LV with an integrity layer over each
raid image (for raid levels 1,4,5,6,10):
lvcreate --type raidN --raidintegrity y [options]
Add an integrity layer to images of an existing raid LV:
lvconvert --raidintegrity y LV
Remove the integrity layer from images of a raid LV:
lvconvert --raidintegrity n LV
Settings
Use --raidintegritymode journal|bitmap (journal is default)
to configure the method used by dm-integrity to ensure
crash consistency.
Initialization
When integrity is added to an LV, the kernel needs to
initialize the integrity metadata/checksums for all blocks
in the LV. The data corruption checking performed by
dm-integrity will only operate on areas of the LV that
are already initialized. The progress of integrity
initialization is reported by the "syncpercent" LV
reporting field (and under the Cpy%Sync lvs column.)
Example: create a raid1 LV with integrity:
$ lvcreate --type raid1 -m1 --raidintegrity y -n rr -L1G foo
Creating integrity metadata LV rr_rimage_0_imeta with size 12.00 MiB.
Logical volume "rr_rimage_0_imeta" created.
Creating integrity metadata LV rr_rimage_1_imeta with size 12.00 MiB.
Logical volume "rr_rimage_1_imeta" created.
Logical volume "rr" created.
$ lvs -a foo
LV VG Attr LSize Origin Cpy%Sync
rr foo rwi-a-r--- 1.00g 4.93
[rr_rimage_0] foo gwi-aor--- 1.00g [rr_rimage_0_iorig] 41.02
[rr_rimage_0_imeta] foo ewi-ao---- 12.00m
[rr_rimage_0_iorig] foo -wi-ao---- 1.00g
[rr_rimage_1] foo gwi-aor--- 1.00g [rr_rimage_1_iorig] 39.45
[rr_rimage_1_imeta] foo ewi-ao---- 12.00m
[rr_rimage_1_iorig] foo -wi-ao---- 1.00g
[rr_rmeta_0] foo ewi-aor--- 4.00m
[rr_rmeta_1] foo ewi-aor--- 4.00m
|
| | |
|
| |
|
|
|
|
| |
Make it possible to tear down VDO volumes with blkdeactivate if VDO is
part of a device stack (and if VDO binary is installed). Also, support
optional -o|--vdooptions configfile=file.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
lvm2 supports thin-pool to be later used by other tools doing
virtual volumes themself (i.e. docker) - in this case we
shall not validate transaction Id - is this is used by
other tools and lvm2 keeps value 0 - so the transationId
validation need to be skipped in this case.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
When vdopool is activated standalone - we use a wrapping linear device
to hold actual vdo device active - for this we can set-up read-only
device to ensure there cannot be made write through this device to
actual pool device.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
When /dev entries or sysfs entries are changing
due to concurrent lvm commands, it can cause
warning/error messages about missing paths.
|
| |
|
|
| |
generated services use vgchange -aay (not -ay)
|
| |
|
|
|
|
|
|
|
| |
Creating a snapshot was using a persistent LV lock
on the origin, so if the origin LV was inactive at
the time of the snapshot the LV lock would remain.
(Running lvchange -an on the inactive LV would
clear the LV lock.) Use a transient LV lock so it
will be dropped if it was not locked previously.
|
| |
|
|
|
|
|
|
| |
Prevent attaching writecache to an active LV until
we can determine the block size of the fs on the LV,
and use that to enforce an appropriate writecache
block size. Changing the block size under a mounted
fs can cause panic/corruption.
|
| | |
|
