| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
| |
This reverts commit c6639056e0bb2fc5f072b2c0d6bb629ad17eee6e.
Next commit restores this feature.
|
| | |
|
| |
|
|
| |
Use existing lv_is_active
|
| |
|
|
|
| |
Caching of DM states optimisation revealed some missing
synchronisation points.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a dm device is suspended, we can't run blkid on it. But earlier
rules (e.g. 11-dm-parts.rules) might have imported previously scanned
properties from the udev db, in particular if the device had been correctly
set up beforehand (DM_UDEV_PRIMARY_SOURCE_FLAG==1). Symlinks for existing
ID_FS_xyz properties must be preserved in this case. Otherwise lower-priority
devices (such as multipath components) might take over the symlink
temporarily.
Likewise, we should't stop watching a temporarily suspended, but previously
correctly configured dm device.
Signed-off-by: Martin Wilck <mwilck@suse.com>
|
| |
|
|
|
|
|
|
|
| |
event based autoactivation is now the only method that lvm
provides for autoactivation.
Setting lvm.conf event_activation=0 can still be used to disable
event based autoactivation commands, but doing so will no longer
enable static autoactivation.
|
| | |
|
| |
|
|
|
| |
Make all possible string buffers to fit so they are not shortened in the
middle.
|
| |
|
|
| |
Although hypothetical case....
|
| | |
|
| |
|
|
| |
FIXME
|
| | |
|
| | |
|
| |
|
|
| |
Fix aplication crash when creating writecached LV with 'automatic' name.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
User can place default settings into lvm.conf i.e.:
allocation {
cache_settings {
writecache {
block_size = 4096
}
}
}
|
| |
|
|
|
|
|
| |
Removes some incorrect and unnecessary checks for other entries
when adding a new devices. The removed checks and corrections were
mostly redundant with what is already done by device id matching.
Other checking is reworked so the warnings are a bit different.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a device has a wwid (from sysfs), but lvm ignores the wwid,
e.g. because it contains an unreliable "QEMU" value, then lvm
falls back to using IDTYPE=devname (the device name) as the
device id. If the device name changes after reboot, then lvm
automatically searches for the PV on other devices to find the
new device name and correct system.devices. When searching for
the PV, lvm skips looking at devices that would use other id types,
e.g. if a device would use a wwid and not a devname, then it
skips checking it. However, it failed to account for the fact
that a device may have wwid that was ignored, in which case it
should be checked.
|
| |
|
|
|
|
| |
This reverts commit d5a950ca67c106403054ecb847e226e8b5a7c30e.
This commit did not properly recognize GPT cases.
|
| |
|
|
|
|
|
|
| |
. error exit means that lvmdevices --update would make a change.
. remove check of PART field from --check because it isn't used.
. unlink searched_devnames file to ensure check|update will search
|
| |
|
|
|
|
|
| |
$ pvcreate /dev/sdc
Cannot use /dev/sdc: device is partitioned
$ pvcreate -f /dev/sdc
Physical volume "/dev/sdc" successfully created.
|
| |
|
|
|
| |
resulting from commit cb798ee1c102aadde93965a894c5aa59d4e76e4a
"lvmcache: remove lvmcache_update_vg_from_write"
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The approach to duplicate VGIDs has been that it is not possible
or not allowed, so the behavior has been undefined. The actual
result was unpredictable and/or broken, and generally unhelpful.
Improve this by recognizing the problem, displaying the VGs,
and printing a warning to fix the problem. Beyond this,
using VGs with duplicate VGIDs remains undefined, but should
work well enough to correct the problem with vgchange -u.
It's possible to create this condition without too much difficulty
by cloning PVs, followed by an incomplete attempt at making the two
VGs unique (vgrename and pvchange -u, but missing vgchange -u.)
|
| |
|
|
|
|
|
|
| |
After a vg_write, this function was used to attempt to
make lvmcache data match the new state written to disk.
It was not updated correctly in a many or most cases,
and the resulting lvmcache is not actually used after
vg_write, making the update unnecessary.
|
| |
|
|
|
|
|
| |
The destination vg is first written with the EXPORTED flag,
then the source vg is written, then the destination vg is
written again without the EXPORTED flag. Remove an unnecessary
vg_read of the destination vg just before the second write.
|
| |
|
|
|
|
|
|
| |
This reverts commit bd2baeaaa67da3885df9f06700565dc201c82861.
This commit broke vgrename because vgrename relies on old bugs
in lvmcache_update_vg_from_write and lvmcache_update_vgname
which need to be fixed first.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The approach to duplicate VGIDs has been that it is not possible
or not allowed, so the behavior has been undefined. The actual
result was unpredictable and/or broken, and generally unhelpful.
Improve this by recognizing the problem, displaying the VGs,
and printing a warning to fix the problem. Beyond this,
using VGs with duplicate VGIDs remains undefined, but should
work well enough to correct the problem with vgchange -u.
It's possible to create this condition without too much difficulty
by cloning PVs, followed by an incomplete attempt at making the two
VGs unique (vgrename and pvchange -u, but missing vgchange -u.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
When storage is lost under a sanlock VG, and kill_vg/drop_vg
are used, sanlock_rem_lockspace() may return an error, but
the cleanup steps should still be performed. Without the
cleanup, gl_lsname_sanlock was not cleared. This caused
future lock requests to fail with ENOLS, but the NO_GL_LS
flag was not set due to gl_lsname_sanlock being set.
This caused lockd_global(sh) in lvm commands to fail when
they could succeed.
Fix from guozhonghua216
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since we check for present DM devices - cache result for
futher use of checking presence of such device.
lvm2 uses cache result for label scan, but also when
it tries to activate or deactivate LV - however only simple
target 'striped' is reasonably supported.
Use disable_dm_devs to be able to control when lv_info()
get cache or uncached results.
TODO: support more type, however this is getting very complicated.
|
| |
|
|
|
| |
Add funtion get_device_list() to get list of active DM devices.
Handled through new dm_task_get_device_list().
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
New API extension (internal ATM) for getting a list
of active DM device with extra features like i.e. uuid.
To easily lookout for existing UUID in device list,
there is: dm_device_list_find_by_uuid()
Once the returned structure is no longer usable call:
dm_device_list_destroy()
Struct dm_active_device {} holds all the info,
but is always allocated and destroyed within library.
TODO: once it's stable, copy to libdm
|
| |
|
|
|
| |
Properly unmangle UUID if they are provided as result
of DM_DEVICE_LIST ioctl on newer linux kernels.
|
| |
|
|
|
| |
Move checking of usable uuid into separate function
and pass in also cmd context.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We used to reset 'settings' to their defaults after command is finished.
This however has a drawback we lose all the logging after this point.
So this patch disables this 'reset' to observe for side-effects.
lvm shell should be getting reset when next command is run -
so this might or might not have some 'hidden' effects.
ATM it looks like nothing really bad should happen - we just should be
able to get more logs - at least from normal commands.
|
| |
|
|
|
| |
If there ever would be API version 5,
these check would give incorrect results.
|
| | |
|
| |
|
|
|
| |
Call existing destroy_config_context() to destroy
some parts of cmd_context.
|
| |
|
|
|
| |
With slightly bigger hash tables, there is considerable
less hash collisions.
|
| |
|
|
| |
Call just once unlink after every deactivation of LV from VG.
|
| |
|
|
|
|
|
| |
Make sure to remove the VDO config after conversion
of LVM-backed VDO.
Addresses point 3 in rhbz#1987024#c5
|
| | |
|
| |
|
|
|
|
|
|
| |
If the transient service remains after it's done, then
it prevents the same transient service from being run
again later if the PVs are detached and reattached
(although the behavior of a second autoactivation is not
well defined and may only work in limited cases.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Description stolen from linux d/b/rbd.c L3:
rbd.c -- Export ceph rados objects as a Linux block device
16 partitions seem to make sense according to L90:
#define RBD_SINGLE_MAJOR_PART_SHIFT 4
Running *scan -vvvvvvdddddd yields
#filters/filter-type.c:28 /dev/rbd1p5: Skipping: Unrecognised LVM device type 252
#filters/filter-persistent.c:131 filter caching bad /dev/rbd1p5
right now, and adding
types = ["rbd", 252]
to /e/l/lvm.conf (with the matching "252 rbd" in /p/devices) works as a
per-machine fix:
rbd1 252:16 0 1T 1 disk
|-rbd1p1 252:17 0 243M 1 part
|-rbd1p2 252:18 0 1K 1 part
`-rbd1p5 252:21 0 1023.8G 1 part
`-dev01--vg-root 253:0 0 1023.8G 0 lvm
but rbd is supported by upstream so it'd be nice to have it work OOB
|
| |
|
|
|
| |
The permitted option list in lvcreate has not kept
up with command-lines.in.
|
| | |
|
| |
|
|
|
| |
non-standard wwid can be reported from sysfs with spaces/etc.
replace with "_"
|
| | |
|
| |
|
|
|
| |
uninitialized name buffer used in message.
fixes "pvs_online: include devname in pvid files"
|
| |
|
|
|
|
| |
Fixes commit "pvscan: match device arg to filter symlink"
which failed to account for the fact that filter entries
are not just path names but include "a" or "r", etc.
|
| | |
|
| | |
|
