shaba/lvm2
1
0
Fork 0
mirror of git://sourceware.org/git/lvm2.git synced 2024-12-21 13:34:40 +03:00
Code Releases Activity
0d572d14ad
lvm2/lib/cache/lvmcache.c

2943 lines
84 KiB
C
Raw Normal View History

A new cache.
2002-11-18 16:53:58 +03:00
/*
Some whitespace tidy-ups.
2008-01-30 17:00:02 +03:00
* Copyright (C) 2001-2004 Sistina Software, Inc. All rights reserved.
Cache and share generated VG structs Extend vginfo cache with cached VG structure. So if the same metadata are use, skip mda decoding in the case, the same data are in use. This helps for operations like activation of all LVs in one VG, where same data were decoded giving the same output result. Patch adds 1-to-1 connection between volume_group and lvmcache_vginfo.
2011-08-11 21:24:23 +04:00
* Copyright (C) 2004-2011 Red Hat, Inc. All rights reserved.
A new cache.
2002-11-18 16:53:58 +03:00
*
Update copyright notices.
2004-03-30 23:35:44 +04:00
* This file is part of LVM2.
*
* This copyrighted material is made available to anyone wishing to use,
* modify, copy, or redistribute it subject to the terms and conditions
Fix inconsistent licence notices: executables are GPLv2; libraries LGPLv2.1.
2007-08-21 00:55:30 +04:00
* of the GNU Lesser General Public License v.2.1.
Update copyright notices.
2004-03-30 23:35:44 +04:00
*
Fix inconsistent licence notices: executables are GPLv2; libraries LGPLv2.1.
2007-08-21 00:55:30 +04:00
* You should have received a copy of the GNU Lesser General Public License
Update copyright notices.
2004-03-30 23:35:44 +04:00
* along with this program; if not, write to the Free Software Foundation,
doc: change fsf address Hmm rpmlint suggest fsf is using a different address these days, so lets keep it up-to-date
2016-01-21 13:49:46 +03:00
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
A new cache.
2002-11-18 16:53:58 +03:00
*/
device_mapper: remove dbg_malloc. I wrote dbg_malloc before we had valgrind. These days there's just no need.
2018-06-08 15:40:53 +03:00
#include "base/memory/zalloc.h"
build: Don't generate symlinks in include/ dir As we start refactoring the code to break dependencies (see doc/refactoring.txt), I want us to use full paths in the includes (eg, #include "base/data-struct/list.h"). This makes it more obvious when we're breaking abstraction boundaries, eg, including a file in metadata/ from base/
2018-05-14 12:30:20 +03:00
#include "lib/misc/lib.h"
#include "lib/cache/lvmcache.h"
#include "lib/commands/toolcontext.h"
#include "lib/device/dev-cache.h"
device usage based on devices file The LVM devices file lists devices that lvm can use. The default file is /etc/lvm/devices/system.devices, and the lvmdevices(8) command is used to add or remove device entries. If the file does not exist, or if lvm.conf includes use_devicesfile=0, then lvm will not use a devices file. When the devices file is in use, the regex filter is not used, and the filter settings in lvm.conf or on the command line are ignored. LVM records devices in the devices file using hardware-specific IDs, such as the WWID, and attempts to use subsystem-specific IDs for virtual device types. These device IDs are also written in the VG metadata. When no hardware or virtual ID is available, lvm falls back using the unstable device name as the device ID. When devnames are used, lvm performs extra scanning to find devices if their devname changes, e.g. after reboot. When proper device IDs are used, an lvm command will not look at devices outside the devices file, but when devnames are used as a fallback, lvm will scan devices outside the devices file to locate PVs on renamed devices. A config setting search_for_devnames can be used to control the scanning for renamed devname entries. Related to the devices file, the new command option --devices <devnames> allows a list of devices to be specified for the command to use, overriding the devices file. The listed devices act as a sort of devices file in terms of limiting which devices lvm will see and use. Devices that are not listed will appear to be missing to the lvm command. Multiple devices files can be kept in /etc/lvm/devices, which allows lvm to be used with different sets of devices, e.g. system devices do not need to be exposed to a specific application, and the application can use lvm on its own set of devices that are not exposed to the system. The option --devicesfile <filename> is used to select the devices file to use with the command. Without the option set, the default system devices file is used. Setting --devicesfile "" causes lvm to not use a devices file. An existing, empty devices file means lvm will see no devices. The new command vgimportdevices adds PVs from a VG to the devices file and updates the VG metadata to include the device IDs. vgimportdevices -a will import all VGs into the system devices file. LVM commands run by dmeventd not use a devices file by default, and will look at all devices on the system. A devices file can be created for dmeventd (/etc/lvm/devices/dmeventd.devices) If this file exists, lvm commands run by dmeventd will use it. Internal implementaion: - device_ids_read - read the devices file . add struct dev_use (du) to cmd->use_devices for each devices file entry - dev_cache_scan - get /dev entries . add struct device (dev) to dev_cache for each device on the system - device_ids_match - match devices file entries to /dev entries . match each du on cmd->use_devices to a dev in dev_cache, using device ID . on match, set du->dev, dev->id, dev->flags MATCHED_USE_ID - label_scan - read lvm headers and metadata from devices . filters are applied, those that do not need data from the device . filter-deviceid skips devs without MATCHED_USE_ID, i.e. skips /dev entries that are not listed in the devices file . read lvm label from dev . filters are applied, those that use data from the device . read lvm metadata from dev . add info/vginfo structs for PVs/VGs (info is "lvmcache") - device_ids_find_renamed_devs - handle devices with unstable devname ID where devname changed . this step only needed when devs do not have proper device IDs, and their dev names change, e.g. after reboot sdb becomes sdc. . detect incorrect match because PVID in the devices file entry does not match the PVID found when the device was read above . undo incorrect match between du and dev above . search system devices for new location of PVID . update devices file with new devnames for PVIDs on renamed devices . label_scan the renamed devs - continue with command processing
2020-06-23 21:25:41 +03:00
#include "lib/device/device_id.h"
build: Don't generate symlinks in include/ dir As we start refactoring the code to break dependencies (see doc/refactoring.txt), I want us to use full paths in the includes (eg, #include "base/data-struct/list.h"). This makes it more obvious when we're breaking abstraction boundaries, eg, including a file in metadata/ from base/
2018-05-14 12:30:20 +03:00
#include "lib/locking/locking.h"
#include "lib/metadata/metadata.h"
#include "lib/mm/memlock.h"
#include "lib/format_text/format-text.h"
#include "lib/config/config.h"
devices: support printing the filter that rejects a device Use of this new message function needs to be added to various commands to improve the output.
2020-07-20 20:48:36 +03:00
#include "lib/filters/filter.h"
Detect duplicate PV uuids - select the one on an md device if appropriate.
2003-01-07 00:10:43 +03:00
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
/* One per device */
struct lvmcache_info {
struct dm_list list; /* Join VG members together */
struct dm_list mdas; /* list head for metadata areas */
struct dm_list das; /* list head for data areas */
refactor: rename embedding area -> bootloader area
2013-05-28 14:37:22 +04:00
struct dm_list bas; /* list head for bootloader areas */
ability to keep track of bad mdas in lvmcache mda's that cannot be processed by lvm because of some corruption can be kept on a separate list. These will be used for more advanced repair in a subsequent commit.
2019-02-05 21:39:08 +03:00
struct dm_list bad_mdas;/* list head for bad metadata areas */
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
struct lvmcache_vginfo *vginfo; /* NULL == unknown */
struct label *label;
const struct format_type *fmt;
struct device *dev;
uint64_t device_size; /* Bytes */
lvmcache/lvmetad: cache PV extension version Store PV extension version in lvmcache/lvmetad for use throughout the code.
2016-02-11 18:25:36 +03:00
uint32_t ext_version; /* Extension version */
lvmcache/lvmetad: cache PV extension flags Store PV extension flags in lvmcache/lvmetad for use throughout the code.
2015-03-09 14:52:07 +03:00
uint32_t ext_flags; /* Extension flags */
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
uint32_t status;
ability to keep track of bad mdas in lvmcache mda's that cannot be processed by lvm because of some corruption can be kept on a separate list. These will be used for more advanced repair in a subsequent commit.
2019-02-05 21:39:08 +03:00
bool mda1_bad; /* label scan found bad metadata in mda1 */
bool mda2_bad; /* label scan found bad metadata in mda2 */
keep track of which mdas have old metadata in lvmcache This will be used for more advanced repair in a subsequent commit.
2019-02-05 22:09:56 +03:00
bool summary_seqno_mismatch; /* two mdas on this dev has mismatching metadata */
lvmcache: use uint32_t for seqno caching
2020-08-28 20:48:40 +03:00
uint32_t summary_seqno; /* vg seqno found on this dev during scan */
uint32_t mda1_seqno;
uint32_t mda2_seqno;
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
};
/* One per VG */
struct lvmcache_vginfo {
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
struct dm_list list; /* _vginfos */
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
struct dm_list infos; /* List head for lvmcache_infos */
ability to keep track of outdated pvs in lvmcache Outdated PVs hold metadata for VG from which they have been removed. Add the ability to keep track of these in lvmcache. This will be used for more advanced repair in a subsequent commit.
2019-02-05 21:55:51 +03:00
struct dm_list outdated_infos; /* vg_read moves info from infos to outdated_infos */
scan: add PV summary info to lvmcache Expand the lvmcache info that is saved by the scan to include PV info from the metadata.
2019-09-26 19:27:38 +03:00
struct dm_list pvsummaries; /* pv_list taken directly from vgsummary */
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
const struct format_type *fmt;
char *vgname; /* "" == orphan */
uint32_t status;
char vgid[ID_LEN + 1];
char _padding[7];
char *creation_host;
lvmcache: include system_id in vginfo cache Save system_id just like creation_host and lock_type strings in vginfo cache.
2015-11-30 20:32:17 +03:00
char *system_id;
lvmcache: add lock_type to VG summary and info structs vgsummary information contains provisional VG information that is obtained without holding the VG lock. This info can be used to lock the VG, and then read it with vg_read(). After the VG is read properly, the vgsummary info should be verified. Add the VG lock_type to the vgsummary. It needs to be known before the VG can be locked and read.
2015-07-24 23:20:37 +03:00
char *lock_type;
cache: Store metadata size and checksum. Refactor the recent metadata-reading optimisation patches. Remove the recently-added cache fields from struct labeller and struct format_instance. Instead, introduce struct lvmcache_vgsummary to wrap the VG information that lvmcache holds and add the metadata size and checksum to it. Allow this VG summary information to be looked up by metadata size + checksum. Adjust the debug log messages to make it clear when this shortcut has been successful. (This changes the optimisation slightly, and might be extendable further.) Add struct cached_vg_fmtdata to format-specific vg_read calls to preserve state alongside the VG across separate calls and indicate if the details supplied match, avoiding the need to read and process the VG metadata again.
2015-03-19 02:43:02 +03:00
uint32_t mda_checksum;
size_t mda_size;
lvmcache: use uint32_t for seqno caching
2020-08-28 20:48:40 +03:00
uint32_t seqno;
keep track of which mdas have old metadata in lvmcache This will be used for more advanced repair in a subsequent commit.
2019-02-05 22:09:56 +03:00
bool scan_summary_mismatch; /* vgsummary from devs had mismatching seqno or checksum */
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
bool has_duplicate_local_vgname; /* this local vg and another local vg have same name */
bool has_duplicate_foreign_vgname; /* this foreign vg and another foreign vg have same name */
clvmd: separate saved_vg from vginfo The clvmd saved_vg data is independent from the normal lvm lvmcache vginfo data, so separate saved_vg from vginfo. Normal lvm doesn't need to use save_vg at all, and in clvmd, lvmcache changes on vginfo can be made without worrying about unwanted effects on saved_vg.
2018-05-03 00:58:49 +03:00
};
lvmcache: simplify metadata cache The copy of VG metadata stored in lvmcache was not being used in general. It pretended to be a generic VG metadata cache, but was not being used except for clvmd activation. There it was used to avoid reading from disk while devices were suspended, i.e. in resume. This removes the code that attempted to make this look like a generic metadata cache, and replaces with with something narrowly targetted to what it's actually used for. This is a way of passing the VG from suspend to resume in clvmd. Since in the case of clvmd one caller can't simply pass the same VG to both suspend and resume, suspend needs to stash the VG somewhere that resume can grab it from. (resume doesn't want to read it from disk since devices are suspended.) The lvmcache vginfo struct is used as a convenient place to stash the VG to pass it from suspend to resume, even though it isn't related to the lvmcache or vginfo. These suspended_vg* vginfo fields should not be used or touched anywhere else, they are only to be used for passing the VG data from suspend to resume in clvmd. The VG data being passed between suspend and resume is never modified, and will only exist in the brief period between suspend and resume in clvmd. suspend has both old (current) and new (precommitted) copies of the VG metadata. It stashes both of these in the vginfo prior to suspending devices. When vg_commit is successful, it sets a flag in vginfo as before, signaling the transition from old to new metadata. resume grabs the VG stashed by suspend. If the vg_commit happened, it grabs the new VG, and if the vg_commit didn't happen it grabs the old VG. The VG is then used to resume LVs. This isolates clvmd-specific code and usage from the normal lvm vg_read code, making the code simpler and the behavior easier to verify. Sequence of operations: - lv_suspend() has both vg_old and vg_new and stashes a copy of each onto the vginfo: lvmcache_save_suspended_vg(vg_old); lvmcache_save_suspended_vg(vg_new); - vg_commit() happens, which causes all clvmd instances to call lvmcache_commit_metadata(vg). A flag is set in the vginfo indicating the transition from the old to new VG: vginfo->suspended_vg_committed = 1; - lv_resume() needs either vg_old or vg_new to use in resuming LVs. It doesn't want to read the VG from disk since devices are suspended, so it gets the VG stashed by lv_suspend: vg = lvmcache_get_suspended_vg(vgid); If the vg_commit did not happen, suspended_vg_committed will not be set, and in this case, lvmcache_get_suspended_vg() will return the old VG instead of the new VG, and it will resume LVs based on the old metadata.
2017-11-01 17:35:40 +03:00
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
/*
* Each VG found during scan gets a vginfo struct.
* Each vginfo is in _vginfos and _vgid_hash, and
* _vgname_hash (unless disabled due to duplicate vgnames).
*/
Use hash, bitset, malloc, pool from libdevmapper.
2005-10-17 03:03:59 +04:00
static struct dm_hash_table *_pvid_hash = NULL;
static struct dm_hash_table *_vgid_hash = NULL;
static struct dm_hash_table *_vgname_hash = NULL;
Initialise _vginfos list staticaly so there is no problem with using uninitialised variables in case, lvmcache_destory() is called without lvmcache_init().
2010-04-30 16:54:31 +04:00
static DM_LIST_INIT(_vginfos);
lvmcache: renaming functions and variables related to duplicates, no functional changes.
2019-08-01 21:50:04 +03:00
static DM_LIST_INIT(_initial_duplicates);
static DM_LIST_INIT(_unused_duplicates);
lvmcache: remove unused_duplicate_devs list from cmd Save the previous duplicate PVs in a global list instead of a list on the cmd struct. dmeventd reuses the cmd struct for multiple commands, and the list entries between commands were being freed (apparently), causing a segfault in dmeventd when it tried to use items in cmd->unused_duplicate_devs that had been saved there by the previous command.
2019-06-07 18:12:52 +03:00
static DM_LIST_INIT(_prev_unused_duplicate_devs);
Another sync point - numerous fixes & clean ups.
2003-07-05 02:34:56 +04:00
static int _vgs_locked = 0;
add device hints to reduce scanning Save the list of PVs in /run/lvm/hints. These hints are used to reduce scanning in a number of commands to only the PVs on the system, or only the PVs in a requested VG (rather than all devices on the system.)
2018-12-07 23:35:22 +03:00
static int _found_duplicate_vgnames = 0;
improve info about vgck updatemetadata Add man page info about this option, and add log messages pointing to this option.
2020-06-03 20:38:27 +03:00
static int _outdated_warning = 0;
A new cache.
2002-11-18 16:53:58 +03:00
clvmd: separate saved_vg from vginfo The clvmd saved_vg data is independent from the normal lvm lvmcache vginfo data, so separate saved_vg from vginfo. Normal lvm doesn't need to use save_vg at all, and in clvmd, lvmcache changes on vginfo can be made without worrying about unwanted effects on saved_vg.
2018-05-03 00:58:49 +03:00
int lvmcache_init(struct cmd_context *cmd)
A new cache.
2002-11-18 16:53:58 +03:00
{
Reset _vgs_locked in lvmcache_init() Upon successful fork(), _become_daemon() must assert that the locks that are currently held belong to the parent, not the child. All of the child's internal state saying 'this process holds a lock' has to be reset. A proper lvmcache_locking_reset() should follow later.
2010-01-11 22:08:18 +03:00
/*
* FIXME add a proper lvmcache_locking_reset() that
* resets the cache so no previous locks are locked
*/
_vgs_locked = 0;
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
dm_list_init(&_vginfos);
lvmcache: renaming functions and variables related to duplicates, no functional changes.
2019-08-01 21:50:04 +03:00
dm_list_init(&_initial_duplicates);
dm_list_init(&_unused_duplicates);
lvmcache: remove unused_duplicate_devs list from cmd Save the previous duplicate PVs in a global list instead of a list on the cmd struct. dmeventd reuses the cmd struct for multiple commands, and the list entries between commands were being freed (apparently), causing a segfault in dmeventd when it tried to use items in cmd->unused_duplicate_devs that had been saved there by the previous command.
2019-06-07 18:12:52 +03:00
dm_list_init(&_prev_unused_duplicate_devs);
A new cache.
2002-11-18 16:53:58 +03:00
hash: use individual hint sizes Use different 'hint' size for dm_hash_create() call - so when debug info about hash is printed we can recognize which hash was in use. This patch doesn't change actual used size since that is always rounded to be power of 2 and >=16 - so as such is only a help to developer. We could eventually use 'name' arg, but since this would have changed API and this patchset will be routed to libdm & stable - we will just use this small trick.
2021-03-07 17:33:50 +03:00
if (!(_vgname_hash = dm_hash_create(127)))
A new cache.
2002-11-18 16:53:58 +03:00
return 0;
hash: use individual hint sizes Use different 'hint' size for dm_hash_create() call - so when debug info about hash is printed we can recognize which hash was in use. This patch doesn't change actual used size since that is always rounded to be power of 2 and >=16 - so as such is only a help to developer. We could eventually use 'name' arg, but since this would have changed API and this patchset will be routed to libdm & stable - we will just use this small trick.
2021-03-07 17:33:50 +03:00
if (!(_vgid_hash = dm_hash_create(126)))
A new cache.
2002-11-18 16:53:58 +03:00
return 0;
hash: use individual hint sizes Use different 'hint' size for dm_hash_create() call - so when debug info about hash is printed we can recognize which hash was in use. This patch doesn't change actual used size since that is always rounded to be power of 2 and >=16 - so as such is only a help to developer. We could eventually use 'name' arg, but since this would have changed API and this patchset will be routed to libdm & stable - we will just use this small trick.
2021-03-07 17:33:50 +03:00
if (!(_pvid_hash = dm_hash_create(125)))
A new cache.
2002-11-18 16:53:58 +03:00
return 0;
return 1;
}
Use __attribute__ consistently throughout.
2010-07-09 19:34:40 +04:00
void lvmcache_lock_vgname(const char *vgname, int read_only __attribute__((unused)))
A new cache.
2002-11-18 16:53:58 +03:00
{
locking: unify global lock for flock and lockd There have been two file locks used to protect lvm "global state": "ORPHANS" and "GLOBAL". Commands that used the ORPHAN flock in exclusive mode: pvcreate, pvremove, vgcreate, vgextend, vgremove, vgcfgrestore Commands that used the ORPHAN flock in shared mode: vgimportclone, pvs, pvscan, pvresize, pvmove, pvdisplay, pvchange, fullreport Commands that used the GLOBAL flock in exclusive mode: pvchange, pvscan, vgimportclone, vgscan Commands that used the GLOBAL flock in shared mode: pvscan --cache, pvs The ORPHAN lock covers the important cases of serializing the use of orphan PVs. It also partially covers the reporting of orphan PVs (although not correctly as explained below.) The GLOBAL lock doesn't seem to have a clear purpose (it may have eroded over time.) Neither lock correctly protects the VG namespace, or orphan PV properties. To simplify and correct these issues, the two separate flocks are combined into the one GLOBAL flock, and this flock is used from the locking sites that are in place for the lvmlockd global lock. The logic behind the lvmlockd (distributed) global lock is that any command that changes "global state" needs to take the global lock in ex mode. Global state in lvm is: the list of VG names, the set of orphan PVs, and any properties of orphan PVs. Reading this global state can use the global lock in sh mode to ensure it doesn't change while being reported. The locking of global state now looks like: lockd_global() previously named lockd_gl(), acquires the distributed global lock through lvmlockd. This is unchanged. It serializes distributed lvm commands that are changing global state. This is a no-op when lvmlockd is not in use. lockf_global() acquires an flock on a local file. It serializes local lvm commands that are changing global state. lock_global() first calls lockf_global() to acquire the local flock for global state, and if this succeeds, it calls lockd_global() to acquire the distributed lock for global state. Replace instances of lockd_gl() with lock_global(), so that the existing sites for lvmlockd global state locking are now also used for local file locking of global state. Remove the previous file locking calls lock_vol(GLOBAL) and lock_vol(ORPHAN). The following commands which change global state are now serialized with the exclusive global flock: pvchange (of orphan), pvresize (of orphan), pvcreate, pvremove, vgcreate, vgextend, vgremove, vgreduce, vgrename, vgcfgrestore, vgimportclone, vgmerge, vgsplit Commands that use a shared flock to read global state (and will be serialized against the prior list) are those that use process_each functions that are based on processing a list of all VG names, or all PVs. The list of all VGs or all PVs is global state and the shared lock prevents those lists from changing while the command is processing them. The ORPHAN lock previously attempted to produce an accurate listing of orphan PVs, but it was only acquired at the end of the command during the fake vg_read of the fake orphan vg. This is not when orphan PVs were determined; they were determined by elimination beforehand by processing all real VGs, and subtracting the PVs in the real VGs from the list of all PVs that had been identified during the initial scan. This is fixed by holding the single global lock in shared mode while processing all VGs to determine the list of orphan PVs.
2019-04-18 23:01:19 +03:00
_vgs_locked++;
Another sync point - numerous fixes & clean ups.
2003-07-05 02:34:56 +04:00
}
void lvmcache_unlock_vgname(const char *vgname)
{
/* FIXME Do this per-VG */
locking: unify global lock for flock and lockd There have been two file locks used to protect lvm "global state": "ORPHANS" and "GLOBAL". Commands that used the ORPHAN flock in exclusive mode: pvcreate, pvremove, vgcreate, vgextend, vgremove, vgcfgrestore Commands that used the ORPHAN flock in shared mode: vgimportclone, pvs, pvscan, pvresize, pvmove, pvdisplay, pvchange, fullreport Commands that used the GLOBAL flock in exclusive mode: pvchange, pvscan, vgimportclone, vgscan Commands that used the GLOBAL flock in shared mode: pvscan --cache, pvs The ORPHAN lock covers the important cases of serializing the use of orphan PVs. It also partially covers the reporting of orphan PVs (although not correctly as explained below.) The GLOBAL lock doesn't seem to have a clear purpose (it may have eroded over time.) Neither lock correctly protects the VG namespace, or orphan PV properties. To simplify and correct these issues, the two separate flocks are combined into the one GLOBAL flock, and this flock is used from the locking sites that are in place for the lvmlockd global lock. The logic behind the lvmlockd (distributed) global lock is that any command that changes "global state" needs to take the global lock in ex mode. Global state in lvm is: the list of VG names, the set of orphan PVs, and any properties of orphan PVs. Reading this global state can use the global lock in sh mode to ensure it doesn't change while being reported. The locking of global state now looks like: lockd_global() previously named lockd_gl(), acquires the distributed global lock through lvmlockd. This is unchanged. It serializes distributed lvm commands that are changing global state. This is a no-op when lvmlockd is not in use. lockf_global() acquires an flock on a local file. It serializes local lvm commands that are changing global state. lock_global() first calls lockf_global() to acquire the local flock for global state, and if this succeeds, it calls lockd_global() to acquire the distributed lock for global state. Replace instances of lockd_gl() with lock_global(), so that the existing sites for lvmlockd global state locking are now also used for local file locking of global state. Remove the previous file locking calls lock_vol(GLOBAL) and lock_vol(ORPHAN). The following commands which change global state are now serialized with the exclusive global flock: pvchange (of orphan), pvresize (of orphan), pvcreate, pvremove, vgcreate, vgextend, vgremove, vgreduce, vgrename, vgcfgrestore, vgimportclone, vgmerge, vgsplit Commands that use a shared flock to read global state (and will be serialized against the prior list) are those that use process_each functions that are based on processing a list of all VG names, or all PVs. The list of all VGs or all PVs is global state and the shared lock prevents those lists from changing while the command is processing them. The ORPHAN lock previously attempted to produce an accurate listing of orphan PVs, but it was only acquired at the end of the command during the fake vg_read of the fake orphan vg. This is not when orphan PVs were determined; they were determined by elimination beforehand by processing all real VGs, and subtracting the PVs in the real VGs from the list of all PVs that had been identified during the initial scan. This is fixed by holding the single global lock in shared mode while processing all VGs to determine the list of orphan PVs.
2019-04-18 23:01:19 +03:00
if (!--_vgs_locked) {
lvmcache: invalidate all cached dev sizes if all VGs got unlocked
2016-01-22 13:13:00 +03:00
dev_size_seqno_inc(); /* invalidate all cached dev sizes */
}
Another sync point - numerous fixes & clean ups.
2003-07-05 02:34:56 +04:00
}
device usage based on devices file The LVM devices file lists devices that lvm can use. The default file is /etc/lvm/devices/system.devices, and the lvmdevices(8) command is used to add or remove device entries. If the file does not exist, or if lvm.conf includes use_devicesfile=0, then lvm will not use a devices file. When the devices file is in use, the regex filter is not used, and the filter settings in lvm.conf or on the command line are ignored. LVM records devices in the devices file using hardware-specific IDs, such as the WWID, and attempts to use subsystem-specific IDs for virtual device types. These device IDs are also written in the VG metadata. When no hardware or virtual ID is available, lvm falls back using the unstable device name as the device ID. When devnames are used, lvm performs extra scanning to find devices if their devname changes, e.g. after reboot. When proper device IDs are used, an lvm command will not look at devices outside the devices file, but when devnames are used as a fallback, lvm will scan devices outside the devices file to locate PVs on renamed devices. A config setting search_for_devnames can be used to control the scanning for renamed devname entries. Related to the devices file, the new command option --devices <devnames> allows a list of devices to be specified for the command to use, overriding the devices file. The listed devices act as a sort of devices file in terms of limiting which devices lvm will see and use. Devices that are not listed will appear to be missing to the lvm command. Multiple devices files can be kept in /etc/lvm/devices, which allows lvm to be used with different sets of devices, e.g. system devices do not need to be exposed to a specific application, and the application can use lvm on its own set of devices that are not exposed to the system. The option --devicesfile <filename> is used to select the devices file to use with the command. Without the option set, the default system devices file is used. Setting --devicesfile "" causes lvm to not use a devices file. An existing, empty devices file means lvm will see no devices. The new command vgimportdevices adds PVs from a VG to the devices file and updates the VG metadata to include the device IDs. vgimportdevices -a will import all VGs into the system devices file. LVM commands run by dmeventd not use a devices file by default, and will look at all devices on the system. A devices file can be created for dmeventd (/etc/lvm/devices/dmeventd.devices) If this file exists, lvm commands run by dmeventd will use it. Internal implementaion: - device_ids_read - read the devices file . add struct dev_use (du) to cmd->use_devices for each devices file entry - dev_cache_scan - get /dev entries . add struct device (dev) to dev_cache for each device on the system - device_ids_match - match devices file entries to /dev entries . match each du on cmd->use_devices to a dev in dev_cache, using device ID . on match, set du->dev, dev->id, dev->flags MATCHED_USE_ID - label_scan - read lvm headers and metadata from devices . filters are applied, those that do not need data from the device . filter-deviceid skips devs without MATCHED_USE_ID, i.e. skips /dev entries that are not listed in the devices file . read lvm label from dev . filters are applied, those that use data from the device . read lvm metadata from dev . add info/vginfo structs for PVs/VGs (info is "lvmcache") - device_ids_find_renamed_devs - handle devices with unstable devname ID where devname changed . this step only needed when devs do not have proper device IDs, and their dev names change, e.g. after reboot sdb becomes sdc. . detect incorrect match because PVID in the devices file entry does not match the PVID found when the device was read above . undo incorrect match between du and dev above . search system devices for new location of PVID . update devices file with new devnames for PVIDs on renamed devices . label_scan the renamed devs - continue with command processing
2020-06-23 21:25:41 +03:00
unsigned int lvmcache_vg_info_count(void)
{
struct lvmcache_vginfo *vginfo;
unsigned int count = 0;
dm_list_iterate_items(vginfo, &_vginfos) {
if (is_orphan_vg(vginfo->vgname))
continue;
count++;
}
return count;
}
improve duplicate pv handling for md components Eliminate md components at the start so they don't interfere with actual duplicates, and don't need to be removed later. This also allows for choosing no copy of a PVID if they all happen to be md components.
2019-08-01 23:04:10 +03:00
int lvmcache_found_duplicate_vgnames(void)
{
return _found_duplicate_vgnames;
}
lvmcache: use devl list helper
2019-08-01 21:58:14 +03:00
static struct device_list *_get_devl_in_device_list(struct device *dev, struct dm_list *head)
{
struct device_list *devl;
dm_list_iterate_items(devl, head) {
if (devl->dev == dev)
return devl;
}
return NULL;
}
int dev_in_device_list(struct device *dev, struct dm_list *head)
{
struct device_list *devl;
dm_list_iterate_items(devl, head) {
if (devl->dev == dev)
return 1;
}
return 0;
}
lvmcache: renaming functions and variables related to duplicates, no functional changes.
2019-08-01 21:50:04 +03:00
bool lvmcache_has_duplicate_devs(void)
toollib: search for duplicate PVs only when needed A full search for duplicate PVs in the case of pvs -a is only necessary when duplicates have previously been detected in lvmcache. Use a global variable from lvmcache to indicate that duplicate PVs exist, so we can skip the search for duplicates when none exist.
2015-01-14 23:38:05 +03:00
{
lvmcache: replace found_duplicates variable With just checking if the duplicates lists are empty.
2019-08-01 21:53:20 +03:00
if (dm_list_empty(&_unused_duplicates) && dm_list_empty(&_initial_duplicates))
return false;
return true;
toollib: search for duplicate PVs only when needed A full search for duplicate PVs in the case of pvs -a is only necessary when duplicates have previously been detected in lvmcache. Use a global variable from lvmcache to indicate that duplicate PVs exist, so we can skip the search for duplicates when none exist.
2015-01-14 23:38:05 +03:00
}
lvmcache: renaming functions and variables related to duplicates, no functional changes.
2019-08-01 21:50:04 +03:00
int lvmcache_get_unused_duplicates(struct cmd_context *cmd, struct dm_list *head)
lvmcache: process duplicate PVs directly Previously, duplicate PVs were processed as a side effect of processing the "chosen" PV in lvmcache. The duplicate PV would be hacked into lvmcache temporarily in place of the chosen PV. In the old way, we had to always process the "chosen" PV device, even if a duplicate of it was named on the command line. This meant we were processing a different device than was asked for. This could be worked around by naming multiple duplicate devs on the command line in which case they were swapped in and out of lvmcache for processing. Now, the duplicate devs are processed directly in their own processing loop. This means we can remove the old hacks related to processing dups as a side effect of processing the chosen device. We can now simply process the device that was named on the command line. When the same PVID exists on two or more devices, one device is preferred and used in the VG, and the others are duplicates and are not used in the VG. The preferred device exists in lvmcache as usual. The duplicates exist in a specical list of unused duplicate devices. The duplicate devs have the "d" attribute and the "duplicate" reporting field displays "duplicate" for them. 'pvs' warns about duplicates, but the formal output only includes the single preferred PV. 'pvs -a' has the same warnings, and the duplicate devs are included in the output. 'pvs <path>' has the same warnings, and displays the named device, whether it is preferred or a duplicate.
2016-02-11 21:37:36 +03:00
{
struct device_list *devl, *devl2;
lvmcache: renaming functions and variables related to duplicates, no functional changes.
2019-08-01 21:50:04 +03:00
dm_list_iterate_items(devl, &_unused_duplicates) {
lvmcache: process duplicate PVs directly Previously, duplicate PVs were processed as a side effect of processing the "chosen" PV in lvmcache. The duplicate PV would be hacked into lvmcache temporarily in place of the chosen PV. In the old way, we had to always process the "chosen" PV device, even if a duplicate of it was named on the command line. This meant we were processing a different device than was asked for. This could be worked around by naming multiple duplicate devs on the command line in which case they were swapped in and out of lvmcache for processing. Now, the duplicate devs are processed directly in their own processing loop. This means we can remove the old hacks related to processing dups as a side effect of processing the chosen device. We can now simply process the device that was named on the command line. When the same PVID exists on two or more devices, one device is preferred and used in the VG, and the others are duplicates and are not used in the VG. The preferred device exists in lvmcache as usual. The duplicates exist in a specical list of unused duplicate devices. The duplicate devs have the "d" attribute and the "duplicate" reporting field displays "duplicate" for them. 'pvs' warns about duplicates, but the formal output only includes the single preferred PV. 'pvs -a' has the same warnings, and the duplicate devs are included in the output. 'pvs <path>' has the same warnings, and displays the named device, whether it is preferred or a duplicate.
2016-02-11 21:37:36 +03:00
if (!(devl2 = dm_pool_alloc(cmd->mem, sizeof(*devl2)))) {
log_error("device_list element allocation failed");
return 0;
}
devl2->dev = devl->dev;
dm_list_add(head, &devl2->list);
}
return 1;
}
lvmcache: renaming functions and variables related to duplicates, no functional changes.
2019-08-01 21:50:04 +03:00
void lvmcache_del_dev_from_duplicates(struct device *dev)
pvremove: allow clearing a duplicate PV Add a special case to allow modifying a duplicate PV to erase it with pvremove -ff.
2016-05-13 00:19:57 +03:00
{
struct device_list *devl;
improve duplicate pv handling for md components Eliminate md components at the start so they don't interfere with actual duplicates, and don't need to be removed later. This also allows for choosing no copy of a PVID if they all happen to be md components.
2019-08-01 23:04:10 +03:00
if ((devl = _get_devl_in_device_list(dev, &_initial_duplicates))) {
log_debug_cache("delete dev from initial duplicates %s", dev_name(dev));
dm_list_del(&devl->list);
}
lvmcache: use devl list helper
2019-08-01 21:58:14 +03:00
if ((devl = _get_devl_in_device_list(dev, &_unused_duplicates))) {
log_debug_cache("delete dev from unused duplicates %s", dev_name(dev));
dm_list_del(&devl->list);
pvremove: allow clearing a duplicate PV Add a special case to allow modifying a duplicate PV to erase it with pvremove -ff.
2016-05-13 00:19:57 +03:00
}
}
lvmcache: renaming functions and variables related to duplicates, no functional changes.
2019-08-01 21:50:04 +03:00
static void _destroy_device_list(struct dm_list *head)
lvmcache: fix duplicate handling with multiple scans Some commands scan labels to populate lvmcache multiple times, i.e. lvmcache_init, scan labels to fill lvmcache, lvmcache_destroy, then later repeat Each time labels are scanned, duplicates are detected, and preferred devices are chosen. Each time this is done within a single command, we want to choose the same preferred devices. So, check for existing preferences when choosing preferred devices. This also fixes a problem with the list of unused duplicate devs when run in an lvm shell. The devs had been allocated from cmd memory, resulting in invalid list entries between commands.
2016-06-06 23:20:55 +03:00
{
struct device_list *devl, *devl2;
dm_list_iterate_items_safe(devl, devl2, head) {
dm_list_del(&devl->list);
device_mapper: remove dbg_malloc. I wrote dbg_malloc before we had valgrind. These days there's just no need.
2018-06-08 15:40:53 +03:00
free(devl);
lvmcache: fix duplicate handling with multiple scans Some commands scan labels to populate lvmcache multiple times, i.e. lvmcache_init, scan labels to fill lvmcache, lvmcache_destroy, then later repeat Each time labels are scanned, duplicates are detected, and preferred devices are chosen. Each time this is done within a single command, we want to choose the same preferred devices. So, check for existing preferences when choosing preferred devices. This also fixes a problem with the list of unused duplicate devs when run in an lvm shell. The devs had been allocated from cmd memory, resulting in invalid list entries between commands.
2016-06-06 23:20:55 +03:00
}
dm_list_init(head);
}
pvremove: allow clearing a duplicate PV Add a special case to allow modifying a duplicate PV to erase it with pvremove -ff.
2016-05-13 00:19:57 +03:00
ability to keep track of bad mdas in lvmcache mda's that cannot be processed by lvm because of some corruption can be kept on a separate list. These will be used for more advanced repair in a subsequent commit.
2019-02-05 21:39:08 +03:00
bool lvmcache_has_bad_metadata(struct device *dev)
{
struct lvmcache_info *info;
if (!(info = lvmcache_info_from_pvid(dev->pvid, dev, 0))) {
/* shouldn't happen */
log_error("No lvmcache info for checking bad metadata on %s", dev_name(dev));
return false;
}
if (info->mda1_bad || info->mda2_bad)
return true;
return false;
}
void lvmcache_save_bad_mda(struct lvmcache_info *info, struct metadata_area *mda)
{
if (mda->mda_num == 1)
info->mda1_bad = true;
else if (mda->mda_num == 2)
info->mda2_bad = true;
dm_list_add(&info->bad_mdas, &mda->list);
}
void lvmcache_get_bad_mdas(struct cmd_context *cmd,
const char *vgname, const char *vgid,
struct dm_list *bad_mda_list)
{
struct lvmcache_vginfo *vginfo;
struct lvmcache_info *info;
struct mda_list *mdal;
struct metadata_area *mda, *mda2;
if (!(vginfo = lvmcache_vginfo_from_vgname(vgname, vgid))) {
log_error(INTERNAL_ERROR "lvmcache_get_bad_mdas no vginfo %s", vgname);
return;
}
dm_list_iterate_items(info, &vginfo->infos) {
dm_list_iterate_items_safe(mda, mda2, &info->bad_mdas) {
if (!(mdal = zalloc(sizeof(*mdal))))
continue;
mdal->mda = mda;
dm_list_add(bad_mda_list, &mdal->list);
}
}
}
scanning: optimize by checking text offset and checksum After the VG lock is taken for vg_read, reread the mda_header and compare the metadata text offset and checksum to what was seen during label scan. If it is unchanged, then the metadata has not changed since the label scan, and the metadata does not need to be reread under the lock for command processing. For commands that do not make changes (e.g. reporting), the mda_header is reread and checked on one mda to decide if the full metadata rereading can be skipped. For other commands (e.g. modifying the vg) the mda_header is reread and checked from all PVs. (These could probably just check one mda also.)
2019-11-26 20:56:51 +03:00
void lvmcache_get_mdas(struct cmd_context *cmd,
const char *vgname, const char *vgid,
struct dm_list *mda_list)
{
struct lvmcache_vginfo *vginfo;
struct lvmcache_info *info;
struct mda_list *mdal;
struct metadata_area *mda, *mda2;
if (!(vginfo = lvmcache_vginfo_from_vgname(vgname, vgid))) {
log_error(INTERNAL_ERROR "lvmcache_get_mdas no vginfo %s", vgname);
return;
}
dm_list_iterate_items(info, &vginfo->infos) {
dm_list_iterate_items_safe(mda, mda2, &info->mdas) {
if (!(mdal = zalloc(sizeof(*mdal))))
continue;
mdal->mda = mda;
dm_list_add(mda_list, &mdal->list);
}
}
}
lvmcache: add lvmcache_get_dev_mda for future patch
2020-10-15 20:53:01 +03:00
struct metadata_area *lvmcache_get_dev_mda(struct device *dev, int mda_num)
{
struct lvmcache_info *info;
struct metadata_area *mda;
if (!(info = lvmcache_info_from_pvid(dev->pvid, dev, 0)))
return NULL;
dm_list_iterate_items(mda, &info->mdas) {
if (mda->mda_num == mda_num)
return mda;
}
return NULL;
}
Refactor some vginfo manipulation code.
2008-05-19 23:49:56 +04:00
static void _vginfo_detach_info(struct lvmcache_info *info)
{
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
if (!dm_list_empty(&info->list)) {
dm_list_del(&info->list);
dm_list_init(&info->list);
Refactor some vginfo manipulation code.
2008-05-19 23:49:56 +04:00
}
info->vginfo = NULL;
}
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
static struct lvmcache_vginfo *_search_vginfos_list(const char *vgname, const char *vgid)
Another sync point - numerous fixes & clean ups.
2003-07-05 02:34:56 +04:00
{
struct lvmcache_vginfo *vginfo;
A new cache.
2002-11-18 16:53:58 +03:00
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
if (vgid) {
dm_list_iterate_items(vginfo, &_vginfos) {
if (!strcmp(vgid, vginfo->vgid))
If two or more VGs are found with the same name, use one that is not exported.
2006-04-12 21:54:11 +04:00
return vginfo;
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
}
} else {
dm_list_iterate_items(vginfo, &_vginfos) {
if (!strcmp(vgname, vginfo->vgname))
return vginfo;
}
}
return NULL;
A new cache.
2002-11-18 16:53:58 +03:00
}
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
static struct lvmcache_vginfo *_vginfo_lookup(const char *vgname, const char *vgid)
A new cache.
2002-11-18 16:53:58 +03:00
{
Another sync point - numerous fixes & clean ups.
2003-07-05 02:34:56 +04:00
struct lvmcache_vginfo *vginfo;
Use __attribute__ consistently throughout.
2010-07-09 19:34:40 +04:00
char id[ID_LEN + 1] __attribute__((aligned(8)));
A new cache.
2002-11-18 16:53:58 +03:00
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
if (vgid) {
/* vgid not necessarily NULL-terminated */
(void) dm_strncpy(id, vgid, sizeof(id));
if ((vginfo = dm_hash_lookup(_vgid_hash, id))) {
if (vgname && strcmp(vginfo->vgname, vgname)) {
/* should never happen */
log_error(INTERNAL_ERROR "vginfo_lookup vgid %s has two names %s %s",
id, vginfo->vgname, vgname);
return NULL;
}
return vginfo;
} else {
/* lookup by vgid that doesn't exist */
return NULL;
}
lvmcache: add mode debug prints Decorate NULL returns with debug_cache output so the debug log doesn't contain spurios <bactrace> line without any reason for it. Add internal errors when cache is misused.
2014-03-18 13:24:32 +04:00
}
A new cache.
2002-11-18 16:53:58 +03:00
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
if (vgname && !_found_duplicate_vgnames) {
if ((vginfo = dm_hash_lookup(_vgname_hash, vgname))) {
if (vginfo->has_duplicate_local_vgname) {
/* should never happen, found_duplicate_vgnames should be set */
debug: drop vgid from debug From the code can be seen the VGID will be always NULL here as vgid != NULL is already handled before. Thus drop from being displayed.
2020-10-02 23:22:25 +03:00
log_error(INTERNAL_ERROR "vginfo_lookup %s has_duplicate_local_vgname.", vgname);
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
return NULL;
}
return vginfo;
}
}
Fix (rare) cache bug on machines with large /dev directories.
2003-01-10 22:14:01 +03:00
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
if (vgname && _found_duplicate_vgnames) {
if ((vginfo = _search_vginfos_list(vgname, vgid))) {
if (vginfo->has_duplicate_local_vgname) {
debug: drop vgid from debug From the code can be seen the VGID will be always NULL here as vgid != NULL is already handled before. Thus drop from being displayed.
2020-10-02 23:22:25 +03:00
log_debug("vginfo_lookup %s has_duplicate_local_vgname return none.", vgname);
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
return NULL;
}
return vginfo;
}
lvmcache: add mode debug prints Decorate NULL returns with debug_cache output so the debug log doesn't contain spurios <bactrace> line without any reason for it. Add internal errors when cache is misused.
2014-03-18 13:24:32 +04:00
}
A new cache.
2002-11-18 16:53:58 +03:00
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
/* lookup by vgname that doesn't exist */
return NULL;
}
struct lvmcache_vginfo *lvmcache_vginfo_from_vgname(const char *vgname, const char *vgid)
{
return _vginfo_lookup(vgname, vgid);
}
struct lvmcache_vginfo *lvmcache_vginfo_from_vgid(const char *vgid)
{
return _vginfo_lookup(NULL, vgid);
A new cache.
2002-11-18 16:53:58 +03:00
}
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
const char *lvmcache_vgname_from_vgid(struct dm_pool *mem, const char *vgid)
Fix vgexport/vgimport to set/reset PV exported flag so pv_attr is correct. Add vgid to struct physical_volume and pass with vg_name to some functions.
2006-04-13 01:23:04 +04:00
{
struct lvmcache_vginfo *vginfo;
Fix PV tools to include orphaned PVs in default output again.
2006-06-15 00:11:22 +04:00
const char *vgname = NULL;
Fix vgexport/vgimport to set/reset PV exported flag so pv_attr is correct. Add vgid to struct physical_volume and pass with vg_name to some functions.
2006-04-13 01:23:04 +04:00
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
if ((vginfo = lvmcache_vginfo_from_vgid(vgid)))
Fix PV tools to include orphaned PVs in default output again.
2006-06-15 00:11:22 +04:00
vgname = vginfo->vgname;
if (mem && vgname)
return dm_pool_strdup(mem, vgname);
Fix vgexport/vgimport to set/reset PV exported flag so pv_attr is correct. Add vgid to struct physical_volume and pass with vg_name to some functions.
2006-04-13 01:23:04 +04:00
Fix PV tools to include orphaned PVs in default output again.
2006-06-15 00:11:22 +04:00
return vgname;
Fix vgexport/vgimport to set/reset PV exported flag so pv_attr is correct. Add vgid to struct physical_volume and pass with vg_name to some functions.
2006-04-13 01:23:04 +04:00
}
vg_read: look up vgid from name After recent changes to process_each, vg_read() is usually given both the vgname and vgid for the intended VG. However, in some cases vg_read() is given a vgid with no vgname, or is given a vgname with no vgid. When given a vgid with no vgname, vg_read() uses lvmcache to look up the vgname using the vgid. If the vgname is not found, vg_read() fails. When given a vgname with no vgid, vg_read() should also use lvmcache to look up the vgid using the vgname. If the vgid is not found, vg_read() fails. If the lvmcache lookup finds multiple vgids for the vgname, then the lookup fails, causing vg_read() to fail because the intended VG is uncertain. Usually, both vgname and vgid for the intended VG are passed to vg_read(), which means the lvmcache translations between vgname and vgid are not done.
2015-12-01 00:12:01 +03:00
const char *lvmcache_vgid_from_vgname(struct cmd_context *cmd, const char *vgname)
{
struct lvmcache_vginfo *vginfo;
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
if (_found_duplicate_vgnames) {
if (!(vginfo = _search_vginfos_list(vgname, NULL)))
return_NULL;
} else {
if (!(vginfo = dm_hash_lookup(_vgname_hash, vgname)))
return_NULL;
}
vg_read: look up vgid from name After recent changes to process_each, vg_read() is usually given both the vgname and vgid for the intended VG. However, in some cases vg_read() is given a vgid with no vgname, or is given a vgname with no vgid. When given a vgid with no vgname, vg_read() uses lvmcache to look up the vgname using the vgid. If the vgname is not found, vg_read() fails. When given a vgname with no vgid, vg_read() should also use lvmcache to look up the vgid using the vgname. If the vgid is not found, vg_read() fails. If the lvmcache lookup finds multiple vgids for the vgname, then the lookup fails, causing vg_read() to fail because the intended VG is uncertain. Usually, both vgname and vgid for the intended VG are passed to vg_read(), which means the lvmcache translations between vgname and vgid are not done.
2015-12-01 00:12:01 +03:00
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
if (vginfo->has_duplicate_local_vgname) {
/*
* return NULL if there is a local VG with the same name since
* we don't know which to use.
*/
return NULL;
}
vg_read: look up vgid from name After recent changes to process_each, vg_read() is usually given both the vgname and vgid for the intended VG. However, in some cases vg_read() is given a vgid with no vgname, or is given a vgname with no vgid. When given a vgid with no vgname, vg_read() uses lvmcache to look up the vgname using the vgid. If the vgname is not found, vg_read() fails. When given a vgname with no vgid, vg_read() should also use lvmcache to look up the vgid using the vgname. If the vgid is not found, vg_read() fails. If the lvmcache lookup finds multiple vgids for the vgname, then the lookup fails, causing vg_read() to fail because the intended VG is uncertain. Usually, both vgname and vgid for the intended VG are passed to vg_read(), which means the lvmcache translations between vgname and vgid are not done.
2015-12-01 00:12:01 +03:00
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
if (vginfo->has_duplicate_foreign_vgname)
return NULL;
return dm_pool_strdup(cmd->mem, vginfo->vgid);
}
bool lvmcache_has_duplicate_local_vgname(const char *vgid, const char *vgname)
{
struct lvmcache_vginfo *vginfo;
if (_found_duplicate_vgnames) {
if (!(vginfo = _search_vginfos_list(vgname, vgid)))
return false;
} else {
if (!(vginfo = dm_hash_lookup(_vgname_hash, vgname)))
return false;
}
if (vginfo->has_duplicate_local_vgname)
return true;
return false;
vg_read: look up vgid from name After recent changes to process_each, vg_read() is usually given both the vgname and vgid for the intended VG. However, in some cases vg_read() is given a vgid with no vgname, or is given a vgname with no vgid. When given a vgid with no vgname, vg_read() uses lvmcache to look up the vgname using the vgid. If the vgname is not found, vg_read() fails. When given a vgname with no vgid, vg_read() should also use lvmcache to look up the vgid using the vgname. If the vgid is not found, vg_read() fails. If the lvmcache lookup finds multiple vgids for the vgname, then the lookup fails, causing vg_read() to fail because the intended VG is uncertain. Usually, both vgname and vgid for the intended VG are passed to vg_read(), which means the lvmcache translations between vgname and vgid are not done.
2015-12-01 00:12:01 +03:00
}
Rely upon internally-cached PV labels while corresponding VG lock is held.
2008-01-30 02:45:48 +03:00
/*
* If valid_only is set, data will only be returned if the cached data is
* known still to be valid.
lvmcache: add optional dev arg to lvmcache_info_from_pvid A number of places are working on a specific dev when they call lvmcache_info_from_pvid() to look up an info struct based on a pvid. In those cases, pass the dev being used to lvmcache_info_from_pvid(). When a dev is specified, lvmcache_info_from_pvid() will verify that the cached info it's using matches the dev being processed before returning the info. Calling code will not mistakenly get info for the wrong dev when duplicate devs exist. This confusion was happening when scanning labels when duplicate devs existed. label_read for the first dev would add an info struct to lvmcache for that dev/pvid. label_read for the second dev would see the pvid in lvmcache from first dev, and mistakenly conclude that the label_read from the second dev can be skipped because it's already been done. By verifying that the dev for the cached pvid matches the dev being read, this mismatch is avoided and the label is actually read from the second duplicate.
2016-06-06 22:04:17 +03:00
*
* When the device being worked with is known, pass that dev as the second arg.
* This ensures that when duplicates exist, the wrong dev isn't used.
Rely upon internally-cached PV labels while corresponding VG lock is held.
2008-01-30 02:45:48 +03:00
*/
lvmcache: add optional dev arg to lvmcache_info_from_pvid A number of places are working on a specific dev when they call lvmcache_info_from_pvid() to look up an info struct based on a pvid. In those cases, pass the dev being used to lvmcache_info_from_pvid(). When a dev is specified, lvmcache_info_from_pvid() will verify that the cached info it's using matches the dev being processed before returning the info. Calling code will not mistakenly get info for the wrong dev when duplicate devs exist. This confusion was happening when scanning labels when duplicate devs existed. label_read for the first dev would add an info struct to lvmcache for that dev/pvid. label_read for the second dev would see the pvid in lvmcache from first dev, and mistakenly conclude that the label_read from the second dev can be skipped because it's already been done. By verifying that the dev for the cached pvid matches the dev being read, this mismatch is avoided and the label is actually read from the second duplicate.
2016-06-06 22:04:17 +03:00
struct lvmcache_info *lvmcache_info_from_pvid(const char *pvid, struct device *dev, int valid_only)
A new cache.
2002-11-18 16:53:58 +03:00
{
Another sync point - numerous fixes & clean ups.
2003-07-05 02:34:56 +04:00
struct lvmcache_info *info;
Use __attribute__ consistently throughout.
2010-07-09 19:34:40 +04:00
char id[ID_LEN + 1] __attribute__((aligned(8)));
A new cache.
2002-11-18 16:53:58 +03:00
if (!_pvid_hash || !pvid)
return NULL;
cleanup: more usage of dm_strncpy Use existing wrapper function arournd strncpy + buf[] = 0;
2018-03-02 18:25:37 +03:00
(void) dm_strncpy(id, pvid, sizeof(id));
Fix (rare) cache bug on machines with large /dev directories.
2003-01-10 22:14:01 +03:00
Use hash, bitset, malloc, pool from libdevmapper.
2005-10-17 03:03:59 +04:00
if (!(info = dm_hash_lookup(_pvid_hash, id)))
A new cache.
2002-11-18 16:53:58 +03:00
return NULL;
lvmcache: add optional dev arg to lvmcache_info_from_pvid A number of places are working on a specific dev when they call lvmcache_info_from_pvid() to look up an info struct based on a pvid. In those cases, pass the dev being used to lvmcache_info_from_pvid(). When a dev is specified, lvmcache_info_from_pvid() will verify that the cached info it's using matches the dev being processed before returning the info. Calling code will not mistakenly get info for the wrong dev when duplicate devs exist. This confusion was happening when scanning labels when duplicate devs existed. label_read for the first dev would add an info struct to lvmcache for that dev/pvid. label_read for the second dev would see the pvid in lvmcache from first dev, and mistakenly conclude that the label_read from the second dev can be skipped because it's already been done. By verifying that the dev for the cached pvid matches the dev being read, this mismatch is avoided and the label is actually read from the second duplicate.
2016-06-06 22:04:17 +03:00
/*
* When handling duplicate PVs, more than one device can have this pvid.
*/
if (dev && info->dev && (info->dev != dev)) {
log_debug_cache("Ignoring lvmcache info for dev %s because dev %s was requested for PVID %s.",
dev_name(info->dev), dev_name(dev), id);
return NULL;
}
A new cache.
2002-11-18 16:53:58 +03:00
return info;
}
lvmcache: process duplicate PVs directly Previously, duplicate PVs were processed as a side effect of processing the "chosen" PV in lvmcache. The duplicate PV would be hacked into lvmcache temporarily in place of the chosen PV. In the old way, we had to always process the "chosen" PV device, even if a duplicate of it was named on the command line. This meant we were processing a different device than was asked for. This could be worked around by naming multiple duplicate devs on the command line in which case they were swapped in and out of lvmcache for processing. Now, the duplicate devs are processed directly in their own processing loop. This means we can remove the old hacks related to processing dups as a side effect of processing the chosen device. We can now simply process the device that was named on the command line. When the same PVID exists on two or more devices, one device is preferred and used in the VG, and the others are duplicates and are not used in the VG. The preferred device exists in lvmcache as usual. The duplicates exist in a specical list of unused duplicate devices. The duplicate devs have the "d" attribute and the "duplicate" reporting field displays "duplicate" for them. 'pvs' warns about duplicates, but the formal output only includes the single preferred PV. 'pvs -a' has the same warnings, and the duplicate devs are included in the output. 'pvs <path>' has the same warnings, and displays the named device, whether it is preferred or a duplicate.
2016-02-11 21:37:36 +03:00
const struct format_type *lvmcache_fmt_from_info(struct lvmcache_info *info)
{
return info->fmt;
}
The lvmetad client-side integration. Only active when use_lvmetad = 1 is set in lvm.conf *and* lvmetad is running.
2012-02-23 17:11:07 +04:00
const char *lvmcache_vgname_from_info(struct lvmcache_info *info)
{
if (info->vginfo)
return info->vginfo->vgname;
return NULL;
}
scan: use PV size for choosing duplicate PV Prefer a device if it matches the size of the PV.
2019-09-27 19:11:57 +03:00
static uint64_t _get_pvsummary_size(char *pvid)
{
char pvid_s[ID_LEN + 1] __attribute__((aligned(8)));
struct lvmcache_vginfo *vginfo;
struct pv_list *pvl;
dm_list_iterate_items(vginfo, &_vginfos) {
dm_list_iterate_items(pvl, &vginfo->pvsummaries) {
(void) dm_strncpy(pvid_s, (char *) &pvl->pv->id, sizeof(pvid_s));
if (!strcmp(pvid_s, pvid))
return pvl->pv->size;
}
}
return 0;
}
scan: use PV device name hint for choosing duplicate PV Prefer a device if its name matches the PV device name hint.
2019-09-27 19:34:55 +03:00
static const char *_get_pvsummary_device_hint(char *pvid)
{
char pvid_s[ID_LEN + 1] __attribute__((aligned(8)));
struct lvmcache_vginfo *vginfo;
struct pv_list *pvl;
dm_list_iterate_items(vginfo, &_vginfos) {
dm_list_iterate_items(pvl, &vginfo->pvsummaries) {
(void) dm_strncpy(pvid_s, (char *) &pvl->pv->id, sizeof(pvid_s));
if (!strcmp(pvid_s, pvid))
return pvl->pv->device_hint;
}
}
return NULL;
}
device usage based on devices file The LVM devices file lists devices that lvm can use. The default file is /etc/lvm/devices/system.devices, and the lvmdevices(8) command is used to add or remove device entries. If the file does not exist, or if lvm.conf includes use_devicesfile=0, then lvm will not use a devices file. When the devices file is in use, the regex filter is not used, and the filter settings in lvm.conf or on the command line are ignored. LVM records devices in the devices file using hardware-specific IDs, such as the WWID, and attempts to use subsystem-specific IDs for virtual device types. These device IDs are also written in the VG metadata. When no hardware or virtual ID is available, lvm falls back using the unstable device name as the device ID. When devnames are used, lvm performs extra scanning to find devices if their devname changes, e.g. after reboot. When proper device IDs are used, an lvm command will not look at devices outside the devices file, but when devnames are used as a fallback, lvm will scan devices outside the devices file to locate PVs on renamed devices. A config setting search_for_devnames can be used to control the scanning for renamed devname entries. Related to the devices file, the new command option --devices <devnames> allows a list of devices to be specified for the command to use, overriding the devices file. The listed devices act as a sort of devices file in terms of limiting which devices lvm will see and use. Devices that are not listed will appear to be missing to the lvm command. Multiple devices files can be kept in /etc/lvm/devices, which allows lvm to be used with different sets of devices, e.g. system devices do not need to be exposed to a specific application, and the application can use lvm on its own set of devices that are not exposed to the system. The option --devicesfile <filename> is used to select the devices file to use with the command. Without the option set, the default system devices file is used. Setting --devicesfile "" causes lvm to not use a devices file. An existing, empty devices file means lvm will see no devices. The new command vgimportdevices adds PVs from a VG to the devices file and updates the VG metadata to include the device IDs. vgimportdevices -a will import all VGs into the system devices file. LVM commands run by dmeventd not use a devices file by default, and will look at all devices on the system. A devices file can be created for dmeventd (/etc/lvm/devices/dmeventd.devices) If this file exists, lvm commands run by dmeventd will use it. Internal implementaion: - device_ids_read - read the devices file . add struct dev_use (du) to cmd->use_devices for each devices file entry - dev_cache_scan - get /dev entries . add struct device (dev) to dev_cache for each device on the system - device_ids_match - match devices file entries to /dev entries . match each du on cmd->use_devices to a dev in dev_cache, using device ID . on match, set du->dev, dev->id, dev->flags MATCHED_USE_ID - label_scan - read lvm headers and metadata from devices . filters are applied, those that do not need data from the device . filter-deviceid skips devs without MATCHED_USE_ID, i.e. skips /dev entries that are not listed in the devices file . read lvm label from dev . filters are applied, those that use data from the device . read lvm metadata from dev . add info/vginfo structs for PVs/VGs (info is "lvmcache") - device_ids_find_renamed_devs - handle devices with unstable devname ID where devname changed . this step only needed when devs do not have proper device IDs, and their dev names change, e.g. after reboot sdb becomes sdc. . detect incorrect match because PVID in the devices file entry does not match the PVID found when the device was read above . undo incorrect match between du and dev above . search system devices for new location of PVID . update devices file with new devnames for PVIDs on renamed devices . label_scan the renamed devs - continue with command processing
2020-06-23 21:25:41 +03:00
static const char *_get_pvsummary_device_id(char *pvid, const char **device_id_type)
{
char pvid_s[ID_LEN + 1] __attribute__((aligned(8)));
struct lvmcache_vginfo *vginfo;
struct pv_list *pvl;
dm_list_iterate_items(vginfo, &_vginfos) {
dm_list_iterate_items(pvl, &vginfo->pvsummaries) {
(void) dm_strncpy(pvid_s, (char *) &pvl->pv->id, sizeof(pvid_s));
if (!strcmp(pvid_s, pvid)) {
*device_id_type = pvl->pv->device_id_type;
return pvl->pv->device_id;
}
}
}
return NULL;
}
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
/*
* Check if any PVs in vg->pvs have the same PVID as any
improve duplicate pv handling for md components Eliminate md components at the start so they don't interfere with actual duplicates, and don't need to be removed later. This also allows for choosing no copy of a PVID if they all happen to be md components.
2019-08-01 23:04:10 +03:00
* entries in _unused_duplicates.
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
*/
int vg_has_duplicate_pvs(struct volume_group *vg)
{
struct pv_list *pvl;
struct device_list *devl;
dm_list_iterate_items(pvl, &vg->pvs) {
lvmcache: renaming functions and variables related to duplicates, no functional changes.
2019-08-01 21:50:04 +03:00
dm_list_iterate_items(devl, &_unused_duplicates) {
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
if (id_equal(&pvl->pv->id, (const struct id *)devl->dev->pvid))
return 1;
}
}
return 0;
}
lvmcache: renaming functions and variables related to duplicates, no functional changes.
2019-08-01 21:50:04 +03:00
bool lvmcache_dev_is_unused_duplicate(struct device *dev)
lvmcache: fix duplicate handling with multiple scans Some commands scan labels to populate lvmcache multiple times, i.e. lvmcache_init, scan labels to fill lvmcache, lvmcache_destroy, then later repeat Each time labels are scanned, duplicates are detected, and preferred devices are chosen. Each time this is done within a single command, we want to choose the same preferred devices. So, check for existing preferences when choosing preferred devices. This also fixes a problem with the list of unused duplicate devs when run in an lvm shell. The devs had been allocated from cmd memory, resulting in invalid list entries between commands.
2016-06-06 23:20:55 +03:00
{
lvmcache: renaming functions and variables related to duplicates, no functional changes.
2019-08-01 21:50:04 +03:00
return dev_in_device_list(dev, &_unused_duplicates) ? true : false;
lvmcache: fix duplicate handling with multiple scans Some commands scan labels to populate lvmcache multiple times, i.e. lvmcache_init, scan labels to fill lvmcache, lvmcache_destroy, then later repeat Each time labels are scanned, duplicates are detected, and preferred devices are chosen. Each time this is done within a single command, we want to choose the same preferred devices. So, check for existing preferences when choosing preferred devices. This also fixes a problem with the list of unused duplicate devs when run in an lvm shell. The devs had been allocated from cmd memory, resulting in invalid list entries between commands.
2016-06-06 23:20:55 +03:00
}
lvmcache: renaming functions and variables related to duplicates, no functional changes.
2019-08-01 21:50:04 +03:00
static void _warn_unused_duplicates(struct cmd_context *cmd)
scan: move warnings about duplicate devices We have been warning about duplicate devices (and disabling lvmetad) immediately when the dup was detected (during label_scan). Move the warnings (and the disabling) to happen later, after label_scan is finished. This lets us avoid an unwanted warning message about duplicates in the special case were md components are eliminated during the duplicate device resolution.
2018-05-21 22:20:19 +03:00
{
char uuid[64] __attribute__((aligned(8)));
struct lvmcache_info *info;
improve duplicate pv handling for md components Eliminate md components at the start so they don't interfere with actual duplicates, and don't need to be removed later. This also allows for choosing no copy of a PVID if they all happen to be md components.
2019-08-01 23:04:10 +03:00
struct device_list *devl;
scan: move warnings about duplicate devices We have been warning about duplicate devices (and disabling lvmetad) immediately when the dup was detected (during label_scan). Move the warnings (and the disabling) to happen later, after label_scan is finished. This lets us avoid an unwanted warning message about duplicates in the special case were md components are eliminated during the duplicate device resolution.
2018-05-21 22:20:19 +03:00
improve duplicate pv handling for md components Eliminate md components at the start so they don't interfere with actual duplicates, and don't need to be removed later. This also allows for choosing no copy of a PVID if they all happen to be md components.
2019-08-01 23:04:10 +03:00
dm_list_iterate_items(devl, &_unused_duplicates) {
scan: move warnings about duplicate devices We have been warning about duplicate devices (and disabling lvmetad) immediately when the dup was detected (during label_scan). Move the warnings (and the disabling) to happen later, after label_scan is finished. This lets us avoid an unwanted warning message about duplicates in the special case were md components are eliminated during the duplicate device resolution.
2018-05-21 22:20:19 +03:00
if (!id_write_format((const struct id *)devl->dev->pvid, uuid, sizeof(uuid)))
stack;
log_warn("WARNING: Not using device %s for PV %s.", dev_name(devl->dev), uuid);
}
improve duplicate pv handling for md components Eliminate md components at the start so they don't interfere with actual duplicates, and don't need to be removed later. This also allows for choosing no copy of a PVID if they all happen to be md components.
2019-08-01 23:04:10 +03:00
dm_list_iterate_items(devl, &_unused_duplicates) {
scan: move warnings about duplicate devices We have been warning about duplicate devices (and disabling lvmetad) immediately when the dup was detected (during label_scan). Move the warnings (and the disabling) to happen later, after label_scan is finished. This lets us avoid an unwanted warning message about duplicates in the special case were md components are eliminated during the duplicate device resolution.
2018-05-21 22:20:19 +03:00
/* info for the preferred device that we're actually using */
devs: clear coverity warning about null info a theoretical possibility.
2018-06-01 18:15:48 +03:00
if (!(info = lvmcache_info_from_pvid(devl->dev->pvid, NULL, 0)))
continue;
scan: move warnings about duplicate devices We have been warning about duplicate devices (and disabling lvmetad) immediately when the dup was detected (during label_scan). Move the warnings (and the disabling) to happen later, after label_scan is finished. This lets us avoid an unwanted warning message about duplicates in the special case were md components are eliminated during the duplicate device resolution.
2018-05-21 22:20:19 +03:00
if (!id_write_format((const struct id *)info->dev->pvid, uuid, sizeof(uuid)))
stack;
log_warn("WARNING: PV %s prefers device %s because %s.",
uuid, dev_name(info->dev), info->dev->duplicate_prefer_reason);
}
scan: ignore duplicates that are md component devs md devices using an older superblock version have superblocks at the end of the md device. For commands that skip reading the end of devices during filtering, the md component devs will be scanned, and will appear as duplicate PVs to the original md device. Remove these md components from the list of unused duplicate devices, so they are treated as if they had been ignored during filtering. This avoids the restrictions that are placed on using PVs with duplicates.
2018-05-11 23:52:22 +03:00
}
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
/*
improve duplicate pv handling for md components Eliminate md components at the start so they don't interfere with actual duplicates, and don't need to be removed later. This also allows for choosing no copy of a PVID if they all happen to be md components.
2019-08-01 23:04:10 +03:00
* If we've found devices with the same PVID, decide which one
* to use.
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
*
improve duplicate pv handling for md components Eliminate md components at the start so they don't interfere with actual duplicates, and don't need to be removed later. This also allows for choosing no copy of a PVID if they all happen to be md components.
2019-08-01 23:04:10 +03:00
* Compare _initial_duplicates entries with the corresponding
* dev (matching PVID) in lvmcache. There may be multiple
* entries in _initial_duplicates for a given PVID. If a dev
* from _initial is preferred over the comparable dev in lvmcache,
* then drop the comparable dev from lvmcache and rescan the dev
* from _initial (rescanning adds it to lvmcache.)
*
* When a preferred dev is chosen, the dispreferred duplicate for
* it is kept in _unused_duplicates.
*
* For some duplicate entries, like a PV detected on an MD dev and
* on a component of that MD dev, we simply ignore the component
* dev, like it was excluded by a filter. In this case we do not
* keep the ignored dev on the _unused list.
*
* _initial_duplicates: duplicate devs found during label_scan.
* The first dev with a given PVID is added to lvmcache, and any
* subsequent devs with that PVID are not added to lvmcache, but
* are kept in the _initial_duplicates list. When label_scan is
* done, the caller (lvmcache_label_scan) compares the dev in
* lvmcache with the matching entries in _initial_duplicates to
* decide which dev should be the one used by the command (which
* will be the one kept in lvmcache.)
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
*
lvmcache: renaming functions and variables related to duplicates, no functional changes.
2019-08-01 21:50:04 +03:00
* _unused_duplicates: duplicate devs not chosen to be used.
improve duplicate pv handling for md components Eliminate md components at the start so they don't interfere with actual duplicates, and don't need to be removed later. This also allows for choosing no copy of a PVID if they all happen to be md components.
2019-08-01 23:04:10 +03:00
* After label_scan adds entries to _initial_duplicates, the
* _initial entries are processed. If the current lvmcache dev is
* preferred over the _initial entry, then the _initial entry is
* moved to _unused_duplicates. If the current lvmcache dev
* is dispreferred vs the _initial duplicate, then the current
* lvmcache dev is added to _unused, the lvmcache info for it is
* dropped, the _initial dev is removed, that _initial dev is
* scanned and added to lvmcache.
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
*
* del_cache_devs: devices to drop from lvmcache
* add_cache_devs: devices to scan to add to lvmcache
*/
lvmcache: renaming functions and variables related to duplicates, no functional changes.
2019-08-01 21:50:04 +03:00
static void _choose_duplicates(struct cmd_context *cmd,
struct dm_list *del_cache_devs,
struct dm_list *add_cache_devs)
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
{
improve duplicate pv handling for md components Eliminate md components at the start so they don't interfere with actual duplicates, and don't need to be removed later. This also allows for choosing no copy of a PVID if they all happen to be md components.
2019-08-01 23:04:10 +03:00
char *pvid;
cleanup: drop assign before use Drop unneeded assigns singe vars are set later in code before their first use (Coverity).
2016-10-03 14:04:16 +03:00
const char *reason;
scan: use PV device name hint for choosing duplicate PV Prefer a device if its name matches the PV device name hint.
2019-09-27 19:34:55 +03:00
const char *device_hint;
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
struct dm_list altdevs;
lvmcache: fix duplicate handling with multiple scans Some commands scan labels to populate lvmcache multiple times, i.e. lvmcache_init, scan labels to fill lvmcache, lvmcache_destroy, then later repeat Each time labels are scanned, duplicates are detected, and preferred devices are chosen. Each time this is done within a single command, we want to choose the same preferred devices. So, check for existing preferences when choosing preferred devices. This also fixes a problem with the list of unused duplicate devs when run in an lvm shell. The devs had been allocated from cmd memory, resulting in invalid list entries between commands.
2016-06-06 23:20:55 +03:00
struct dm_list new_unused;
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
struct dev_types *dt = cmd->dev_types;
improve duplicate pv handling for md components Eliminate md components at the start so they don't interfere with actual duplicates, and don't need to be removed later. This also allows for choosing no copy of a PVID if they all happen to be md components.
2019-08-01 23:04:10 +03:00
struct device_list *devl, *devl_safe, *devl_add, *devl_del;
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
struct lvmcache_info *info;
struct device *dev1, *dev2;
device usage based on devices file The LVM devices file lists devices that lvm can use. The default file is /etc/lvm/devices/system.devices, and the lvmdevices(8) command is used to add or remove device entries. If the file does not exist, or if lvm.conf includes use_devicesfile=0, then lvm will not use a devices file. When the devices file is in use, the regex filter is not used, and the filter settings in lvm.conf or on the command line are ignored. LVM records devices in the devices file using hardware-specific IDs, such as the WWID, and attempts to use subsystem-specific IDs for virtual device types. These device IDs are also written in the VG metadata. When no hardware or virtual ID is available, lvm falls back using the unstable device name as the device ID. When devnames are used, lvm performs extra scanning to find devices if their devname changes, e.g. after reboot. When proper device IDs are used, an lvm command will not look at devices outside the devices file, but when devnames are used as a fallback, lvm will scan devices outside the devices file to locate PVs on renamed devices. A config setting search_for_devnames can be used to control the scanning for renamed devname entries. Related to the devices file, the new command option --devices <devnames> allows a list of devices to be specified for the command to use, overriding the devices file. The listed devices act as a sort of devices file in terms of limiting which devices lvm will see and use. Devices that are not listed will appear to be missing to the lvm command. Multiple devices files can be kept in /etc/lvm/devices, which allows lvm to be used with different sets of devices, e.g. system devices do not need to be exposed to a specific application, and the application can use lvm on its own set of devices that are not exposed to the system. The option --devicesfile <filename> is used to select the devices file to use with the command. Without the option set, the default system devices file is used. Setting --devicesfile "" causes lvm to not use a devices file. An existing, empty devices file means lvm will see no devices. The new command vgimportdevices adds PVs from a VG to the devices file and updates the VG metadata to include the device IDs. vgimportdevices -a will import all VGs into the system devices file. LVM commands run by dmeventd not use a devices file by default, and will look at all devices on the system. A devices file can be created for dmeventd (/etc/lvm/devices/dmeventd.devices) If this file exists, lvm commands run by dmeventd will use it. Internal implementaion: - device_ids_read - read the devices file . add struct dev_use (du) to cmd->use_devices for each devices file entry - dev_cache_scan - get /dev entries . add struct device (dev) to dev_cache for each device on the system - device_ids_match - match devices file entries to /dev entries . match each du on cmd->use_devices to a dev in dev_cache, using device ID . on match, set du->dev, dev->id, dev->flags MATCHED_USE_ID - label_scan - read lvm headers and metadata from devices . filters are applied, those that do not need data from the device . filter-deviceid skips devs without MATCHED_USE_ID, i.e. skips /dev entries that are not listed in the devices file . read lvm label from dev . filters are applied, those that use data from the device . read lvm metadata from dev . add info/vginfo structs for PVs/VGs (info is "lvmcache") - device_ids_find_renamed_devs - handle devices with unstable devname ID where devname changed . this step only needed when devs do not have proper device IDs, and their dev names change, e.g. after reboot sdb becomes sdc. . detect incorrect match because PVID in the devices file entry does not match the PVID found when the device was read above . undo incorrect match between du and dev above . search system devices for new location of PVID . update devices file with new devnames for PVIDs on renamed devices . label_scan the renamed devs - continue with command processing
2020-06-23 21:25:41 +03:00
const char *device_id = NULL, *device_id_type = NULL;
const char *idname1 = NULL, *idname2 = NULL;
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
uint32_t dev1_major, dev1_minor, dev2_major, dev2_minor;
gcc: avoid warning: declaration of xxx shadows a global declaration Fix some gcc complaints again shadowing global declarations
2019-10-21 13:32:11 +03:00
uint64_t dev1_size, dev2_size, pvsummary_size;
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
int in_subsys1, in_subsys2;
int is_dm1, is_dm2;
int has_fs1, has_fs2;
lvmcache: use active LVs and device sizes to choose between duplicates If duplicate devices exist for a PV, and one device's size matches the PV size, but the other doesn't, then prefer the matching device. If one device is used by an active LV, prefer that device.
2016-03-29 21:29:39 +03:00
int has_lv1, has_lv2;
scan: use PV size for choosing duplicate PV Prefer a device if it matches the size of the PV.
2019-09-27 19:11:57 +03:00
int same_size1, same_size2;
scan: use PV device name hint for choosing duplicate PV Prefer a device if its name matches the PV device name hint.
2019-09-27 19:34:55 +03:00
int same_name1 = 0, same_name2 = 0;
device usage based on devices file The LVM devices file lists devices that lvm can use. The default file is /etc/lvm/devices/system.devices, and the lvmdevices(8) command is used to add or remove device entries. If the file does not exist, or if lvm.conf includes use_devicesfile=0, then lvm will not use a devices file. When the devices file is in use, the regex filter is not used, and the filter settings in lvm.conf or on the command line are ignored. LVM records devices in the devices file using hardware-specific IDs, such as the WWID, and attempts to use subsystem-specific IDs for virtual device types. These device IDs are also written in the VG metadata. When no hardware or virtual ID is available, lvm falls back using the unstable device name as the device ID. When devnames are used, lvm performs extra scanning to find devices if their devname changes, e.g. after reboot. When proper device IDs are used, an lvm command will not look at devices outside the devices file, but when devnames are used as a fallback, lvm will scan devices outside the devices file to locate PVs on renamed devices. A config setting search_for_devnames can be used to control the scanning for renamed devname entries. Related to the devices file, the new command option --devices <devnames> allows a list of devices to be specified for the command to use, overriding the devices file. The listed devices act as a sort of devices file in terms of limiting which devices lvm will see and use. Devices that are not listed will appear to be missing to the lvm command. Multiple devices files can be kept in /etc/lvm/devices, which allows lvm to be used with different sets of devices, e.g. system devices do not need to be exposed to a specific application, and the application can use lvm on its own set of devices that are not exposed to the system. The option --devicesfile <filename> is used to select the devices file to use with the command. Without the option set, the default system devices file is used. Setting --devicesfile "" causes lvm to not use a devices file. An existing, empty devices file means lvm will see no devices. The new command vgimportdevices adds PVs from a VG to the devices file and updates the VG metadata to include the device IDs. vgimportdevices -a will import all VGs into the system devices file. LVM commands run by dmeventd not use a devices file by default, and will look at all devices on the system. A devices file can be created for dmeventd (/etc/lvm/devices/dmeventd.devices) If this file exists, lvm commands run by dmeventd will use it. Internal implementaion: - device_ids_read - read the devices file . add struct dev_use (du) to cmd->use_devices for each devices file entry - dev_cache_scan - get /dev entries . add struct device (dev) to dev_cache for each device on the system - device_ids_match - match devices file entries to /dev entries . match each du on cmd->use_devices to a dev in dev_cache, using device ID . on match, set du->dev, dev->id, dev->flags MATCHED_USE_ID - label_scan - read lvm headers and metadata from devices . filters are applied, those that do not need data from the device . filter-deviceid skips devs without MATCHED_USE_ID, i.e. skips /dev entries that are not listed in the devices file . read lvm label from dev . filters are applied, those that use data from the device . read lvm metadata from dev . add info/vginfo structs for PVs/VGs (info is "lvmcache") - device_ids_find_renamed_devs - handle devices with unstable devname ID where devname changed . this step only needed when devs do not have proper device IDs, and their dev names change, e.g. after reboot sdb becomes sdc. . detect incorrect match because PVID in the devices file entry does not match the PVID found when the device was read above . undo incorrect match between du and dev above . search system devices for new location of PVID . update devices file with new devnames for PVIDs on renamed devices . label_scan the renamed devs - continue with command processing
2020-06-23 21:25:41 +03:00
int same_id1 = 0, same_id2 = 0;
lvmcache: fix duplicate handling with multiple scans Some commands scan labels to populate lvmcache multiple times, i.e. lvmcache_init, scan labels to fill lvmcache, lvmcache_destroy, then later repeat Each time labels are scanned, duplicates are detected, and preferred devices are chosen. Each time this is done within a single command, we want to choose the same preferred devices. So, check for existing preferences when choosing preferred devices. This also fixes a problem with the list of unused duplicate devs when run in an lvm shell. The devs had been allocated from cmd memory, resulting in invalid list entries between commands.
2016-06-06 23:20:55 +03:00
int prev_unchosen1, prev_unchosen2;
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
int change;
lvmcache: fix duplicate handling with multiple scans Some commands scan labels to populate lvmcache multiple times, i.e. lvmcache_init, scan labels to fill lvmcache, lvmcache_destroy, then later repeat Each time labels are scanned, duplicates are detected, and preferred devices are chosen. Each time this is done within a single command, we want to choose the same preferred devices. So, check for existing preferences when choosing preferred devices. This also fixes a problem with the list of unused duplicate devs when run in an lvm shell. The devs had been allocated from cmd memory, resulting in invalid list entries between commands.
2016-06-06 23:20:55 +03:00
dm_list_init(&new_unused);
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
/*
* Create a list of all alternate devs for the same pvid: altdevs.
*/
next:
dm_list_init(&altdevs);
improve duplicate pv handling for md components Eliminate md components at the start so they don't interfere with actual duplicates, and don't need to be removed later. This also allows for choosing no copy of a PVID if they all happen to be md components.
2019-08-01 23:04:10 +03:00
pvid = NULL;
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
lvmcache: renaming functions and variables related to duplicates, no functional changes.
2019-08-01 21:50:04 +03:00
dm_list_iterate_items_safe(devl, devl_safe, &_initial_duplicates) {
improve duplicate pv handling for md components Eliminate md components at the start so they don't interfere with actual duplicates, and don't need to be removed later. This also allows for choosing no copy of a PVID if they all happen to be md components.
2019-08-01 23:04:10 +03:00
if (!pvid) {
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
dm_list_move(&altdevs, &devl->list);
improve duplicate pv handling for md components Eliminate md components at the start so they don't interfere with actual duplicates, and don't need to be removed later. This also allows for choosing no copy of a PVID if they all happen to be md components.
2019-08-01 23:04:10 +03:00
pvid = devl->dev->pvid;
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
} else {
improve duplicate pv handling for md components Eliminate md components at the start so they don't interfere with actual duplicates, and don't need to be removed later. This also allows for choosing no copy of a PVID if they all happen to be md components.
2019-08-01 23:04:10 +03:00
if (!strcmp(pvid, devl->dev->pvid))
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
dm_list_move(&altdevs, &devl->list);
}
}
improve duplicate pv handling for md components Eliminate md components at the start so they don't interfere with actual duplicates, and don't need to be removed later. This also allows for choosing no copy of a PVID if they all happen to be md components.
2019-08-01 23:04:10 +03:00
/* done, no more entries to process */
if (!pvid) {
lvmcache: renaming functions and variables related to duplicates, no functional changes.
2019-08-01 21:50:04 +03:00
_destroy_device_list(&_unused_duplicates);
dm_list_splice(&_unused_duplicates, &new_unused);
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
return;
lvmcache: fix duplicate handling with multiple scans Some commands scan labels to populate lvmcache multiple times, i.e. lvmcache_init, scan labels to fill lvmcache, lvmcache_destroy, then later repeat Each time labels are scanned, duplicates are detected, and preferred devices are chosen. Each time this is done within a single command, we want to choose the same preferred devices. So, check for existing preferences when choosing preferred devices. This also fixes a problem with the list of unused duplicate devs when run in an lvm shell. The devs had been allocated from cmd memory, resulting in invalid list entries between commands.
2016-06-06 23:20:55 +03:00
}
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
improve duplicate pv handling for md components Eliminate md components at the start so they don't interfere with actual duplicates, and don't need to be removed later. This also allows for choosing no copy of a PVID if they all happen to be md components.
2019-08-01 23:04:10 +03:00
/*
* Get rid of any md components before comparing alternatives.
* (Since an md component can never be used, it's not an
* option to use like other kinds of alternatives.)
*/
info = lvmcache_info_from_pvid(pvid, NULL, 0);
devices: rework libudev usage related to config settings: obtain_device_info_from_udev (controls if lvm gets a list of devices from readdir /dev or from libudev) external_device_info_source (controls if lvm asks libudev for device information) . Make the obtain_device_list_from_udev setting affect only the choice of readdir /dev vs libudev. The setting no longer controls if udev is used for device type checks. . Change obtain_device_list_from_udev default to 0. This helps avoid boot timeouts due to slow libudev queries, avoids reported failures from udev_enumerate_scan_devices, and avoids delays from "device not initialized in udev database" errors. Even without errors, for a system booting with 1024 PVs, lvm2-pvscan times improve from about 100 sec to 15 sec, and the pvscan command from about 64 sec to about 4 sec. . For external_device_info_source="none", remove all libudev device info queries, and use only lvm native device info. . For external_device_info_source="udev", first check lvm native device info, then check libudev info. . Remove sleep/retry loop when attempting libudev queries for device info. udev info will simply be skipped if it's not immediately available. . Only set up a libdev connection if it will be used by obtain_device_list_from_udev/external_device_info_source. . For native multipath component detection, use /etc/multipath/wwids. If a device has a wwid matching an entry in the wwids file, then it's considered a multipath component. This is necessary to natively detect multipath components when the mpath device is not set up.
2021-06-09 01:12:09 +03:00
if (info && dev_is_md_component(cmd, info->dev, NULL, 1)) {
improve duplicate pv handling for md components Eliminate md components at the start so they don't interfere with actual duplicates, and don't need to be removed later. This also allows for choosing no copy of a PVID if they all happen to be md components.
2019-08-01 23:04:10 +03:00
/* does not go in del_cache_devs which become unused_duplicates */
log_debug_cache("PV %s drop MD component from scan selection %s", pvid, dev_name(info->dev));
lvmcache_del(info);
info = NULL;
}
dm_list_iterate_items_safe(devl, devl_safe, &altdevs) {
devices: rework libudev usage related to config settings: obtain_device_info_from_udev (controls if lvm gets a list of devices from readdir /dev or from libudev) external_device_info_source (controls if lvm asks libudev for device information) . Make the obtain_device_list_from_udev setting affect only the choice of readdir /dev vs libudev. The setting no longer controls if udev is used for device type checks. . Change obtain_device_list_from_udev default to 0. This helps avoid boot timeouts due to slow libudev queries, avoids reported failures from udev_enumerate_scan_devices, and avoids delays from "device not initialized in udev database" errors. Even without errors, for a system booting with 1024 PVs, lvm2-pvscan times improve from about 100 sec to 15 sec, and the pvscan command from about 64 sec to about 4 sec. . For external_device_info_source="none", remove all libudev device info queries, and use only lvm native device info. . For external_device_info_source="udev", first check lvm native device info, then check libudev info. . Remove sleep/retry loop when attempting libudev queries for device info. udev info will simply be skipped if it's not immediately available. . Only set up a libdev connection if it will be used by obtain_device_list_from_udev/external_device_info_source. . For native multipath component detection, use /etc/multipath/wwids. If a device has a wwid matching an entry in the wwids file, then it's considered a multipath component. This is necessary to natively detect multipath components when the mpath device is not set up.
2021-06-09 01:12:09 +03:00
if (dev_is_md_component(cmd, devl->dev, NULL, 1)) {
improve duplicate pv handling for md components Eliminate md components at the start so they don't interfere with actual duplicates, and don't need to be removed later. This also allows for choosing no copy of a PVID if they all happen to be md components.
2019-08-01 23:04:10 +03:00
log_debug_cache("PV %s drop MD component from scan duplicates %s", pvid, dev_name(devl->dev));
dm_list_del(&devl->list);
}
}
if (dm_list_empty(&altdevs))
goto next;
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
/*
* Find the device for the pvid that's currently in lvmcache.
*/
improve duplicate pv handling for md components Eliminate md components at the start so they don't interfere with actual duplicates, and don't need to be removed later. This also allows for choosing no copy of a PVID if they all happen to be md components.
2019-08-01 23:04:10 +03:00
if (!(info = lvmcache_info_from_pvid(pvid, NULL, 0))) {
Additional MD component checking If udev info is missing for a device, (which would indicate if it's an MD component), then do an end-of-device read to check if a PV is an MD component. (This is skipped when using hints since we already know devs in hints are good.) A new config setting md_component_checks can be used to disable the additional end-of-device MD checks, or to always enable end-of-device MD checks. When both hints and udev info are disabled/unavailable, the end of PVs will now be scanned by default. If md devices with end-of-device superblocks are not being used, the extra I/O overhead can be avoided by setting md_component_checks="start".
2019-05-21 20:06:34 +03:00
/*
improve duplicate pv handling for md components Eliminate md components at the start so they don't interfere with actual duplicates, and don't need to be removed later. This also allows for choosing no copy of a PVID if they all happen to be md components.
2019-08-01 23:04:10 +03:00
* This will happen if the lvmcache dev was already recognized
* as an md component and already dropped from lvmcache.
* One of the altdev entries for the PVID should be added to
* lvmcache.
Additional MD component checking If udev info is missing for a device, (which would indicate if it's an MD component), then do an end-of-device read to check if a PV is an MD component. (This is skipped when using hints since we already know devs in hints are good.) A new config setting md_component_checks can be used to disable the additional end-of-device MD checks, or to always enable end-of-device MD checks. When both hints and udev info are disabled/unavailable, the end of PVs will now be scanned by default. If md devices with end-of-device superblocks are not being used, the extra I/O overhead can be avoided by setting md_component_checks="start".
2019-05-21 20:06:34 +03:00
*/
improve duplicate pv handling for md components Eliminate md components at the start so they don't interfere with actual duplicates, and don't need to be removed later. This also allows for choosing no copy of a PVID if they all happen to be md components.
2019-08-01 23:04:10 +03:00
if (dm_list_size(&altdevs) == 1) {
devl = dm_list_item(dm_list_first(&altdevs), struct device_list);
dm_list_del(&devl->list);
dm_list_add(add_cache_devs, &devl->list);
log_debug_cache("PV %s with duplicates unselected using %s.",
pvid, dev_name(devl->dev));
goto next;
} else {
devl = dm_list_item(dm_list_first(&altdevs), struct device_list);
dev1 = devl->dev;
log_debug_cache("PV %s with duplicates unselected comparing alternatives", pvid);
}
} else {
log_debug_cache("PV %s with duplicates comparing alternatives for %s",
pvid, dev_name(info->dev));
dev1 = info->dev;
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
}
/*
* Compare devices for the given pvid to find one that's preferred.
*/
dm_list_iterate_items(devl, &altdevs) {
dev2 = devl->dev;
improve duplicate pv handling for md components Eliminate md components at the start so they don't interfere with actual duplicates, and don't need to be removed later. This also allows for choosing no copy of a PVID if they all happen to be md components.
2019-08-01 23:04:10 +03:00
/* Took the first altdev to start with above. */
if (dev1 == dev2)
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
continue;
lvmcache: renaming functions and variables related to duplicates, no functional changes.
2019-08-01 21:50:04 +03:00
prev_unchosen1 = dev_in_device_list(dev1, &_unused_duplicates);
prev_unchosen2 = dev_in_device_list(dev2, &_unused_duplicates);
lvmcache: fix duplicate handling with multiple scans Some commands scan labels to populate lvmcache multiple times, i.e. lvmcache_init, scan labels to fill lvmcache, lvmcache_destroy, then later repeat Each time labels are scanned, duplicates are detected, and preferred devices are chosen. Each time this is done within a single command, we want to choose the same preferred devices. So, check for existing preferences when choosing preferred devices. This also fixes a problem with the list of unused duplicate devs when run in an lvm shell. The devs had been allocated from cmd memory, resulting in invalid list entries between commands.
2016-06-06 23:20:55 +03:00
if (!prev_unchosen1 && !prev_unchosen2) {
/*
lvmcache: remove unused_duplicate_devs list from cmd Save the previous duplicate PVs in a global list instead of a list on the cmd struct. dmeventd reuses the cmd struct for multiple commands, and the list entries between commands were being freed (apparently), causing a segfault in dmeventd when it tried to use items in cmd->unused_duplicate_devs that had been saved there by the previous command.
2019-06-07 18:12:52 +03:00
* The prev list saves the unchosen preference across
lvmcache: fix duplicate handling with multiple scans Some commands scan labels to populate lvmcache multiple times, i.e. lvmcache_init, scan labels to fill lvmcache, lvmcache_destroy, then later repeat Each time labels are scanned, duplicates are detected, and preferred devices are chosen. Each time this is done within a single command, we want to choose the same preferred devices. So, check for existing preferences when choosing preferred devices. This also fixes a problem with the list of unused duplicate devs when run in an lvm shell. The devs had been allocated from cmd memory, resulting in invalid list entries between commands.
2016-06-06 23:20:55 +03:00
* lvmcache_destroy. Sometimes a single command will
* fill lvmcache, destroy it, and refill it, and we
* want the same duplicate preference to be preserved
* in each instance of lvmcache for a single command.
*/
lvmcache: remove unused_duplicate_devs list from cmd Save the previous duplicate PVs in a global list instead of a list on the cmd struct. dmeventd reuses the cmd struct for multiple commands, and the list entries between commands were being freed (apparently), causing a segfault in dmeventd when it tried to use items in cmd->unused_duplicate_devs that had been saved there by the previous command.
2019-06-07 18:12:52 +03:00
prev_unchosen1 = dev_in_device_list(dev1, &_prev_unused_duplicate_devs);
prev_unchosen2 = dev_in_device_list(dev2, &_prev_unused_duplicate_devs);
lvmcache: fix duplicate handling with multiple scans Some commands scan labels to populate lvmcache multiple times, i.e. lvmcache_init, scan labels to fill lvmcache, lvmcache_destroy, then later repeat Each time labels are scanned, duplicates are detected, and preferred devices are chosen. Each time this is done within a single command, we want to choose the same preferred devices. So, check for existing preferences when choosing preferred devices. This also fixes a problem with the list of unused duplicate devs when run in an lvm shell. The devs had been allocated from cmd memory, resulting in invalid list entries between commands.
2016-06-06 23:20:55 +03:00
}
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
dev1_major = MAJOR(dev1->dev);
dev1_minor = MINOR(dev1->dev);
dev2_major = MAJOR(dev2->dev);
dev2_minor = MINOR(dev2->dev);
scan: use PV size for choosing duplicate PV Prefer a device if it matches the size of the PV.
2019-09-27 19:11:57 +03:00
if (!dev_get_size(dev1, &dev1_size))
dev1_size = 0;
if (!dev_get_size(dev2, &dev2_size))
dev2_size = 0;
gcc: avoid warning: declaration of xxx shadows a global declaration Fix some gcc complaints again shadowing global declarations
2019-10-21 13:32:11 +03:00
pvsummary_size = _get_pvsummary_size(devl->dev->pvid);
same_size1 = (dev1_size == pvsummary_size);
same_size2 = (dev2_size == pvsummary_size);
scan: use PV size for choosing duplicate PV Prefer a device if it matches the size of the PV.
2019-09-27 19:11:57 +03:00
scan: use PV device name hint for choosing duplicate PV Prefer a device if its name matches the PV device name hint.
2019-09-27 19:34:55 +03:00
if ((device_hint = _get_pvsummary_device_hint(devl->dev->pvid))) {
same_name1 = !strcmp(device_hint, dev_name(dev1));
same_name2 = !strcmp(device_hint, dev_name(dev2));
}
device usage based on devices file The LVM devices file lists devices that lvm can use. The default file is /etc/lvm/devices/system.devices, and the lvmdevices(8) command is used to add or remove device entries. If the file does not exist, or if lvm.conf includes use_devicesfile=0, then lvm will not use a devices file. When the devices file is in use, the regex filter is not used, and the filter settings in lvm.conf or on the command line are ignored. LVM records devices in the devices file using hardware-specific IDs, such as the WWID, and attempts to use subsystem-specific IDs for virtual device types. These device IDs are also written in the VG metadata. When no hardware or virtual ID is available, lvm falls back using the unstable device name as the device ID. When devnames are used, lvm performs extra scanning to find devices if their devname changes, e.g. after reboot. When proper device IDs are used, an lvm command will not look at devices outside the devices file, but when devnames are used as a fallback, lvm will scan devices outside the devices file to locate PVs on renamed devices. A config setting search_for_devnames can be used to control the scanning for renamed devname entries. Related to the devices file, the new command option --devices <devnames> allows a list of devices to be specified for the command to use, overriding the devices file. The listed devices act as a sort of devices file in terms of limiting which devices lvm will see and use. Devices that are not listed will appear to be missing to the lvm command. Multiple devices files can be kept in /etc/lvm/devices, which allows lvm to be used with different sets of devices, e.g. system devices do not need to be exposed to a specific application, and the application can use lvm on its own set of devices that are not exposed to the system. The option --devicesfile <filename> is used to select the devices file to use with the command. Without the option set, the default system devices file is used. Setting --devicesfile "" causes lvm to not use a devices file. An existing, empty devices file means lvm will see no devices. The new command vgimportdevices adds PVs from a VG to the devices file and updates the VG metadata to include the device IDs. vgimportdevices -a will import all VGs into the system devices file. LVM commands run by dmeventd not use a devices file by default, and will look at all devices on the system. A devices file can be created for dmeventd (/etc/lvm/devices/dmeventd.devices) If this file exists, lvm commands run by dmeventd will use it. Internal implementaion: - device_ids_read - read the devices file . add struct dev_use (du) to cmd->use_devices for each devices file entry - dev_cache_scan - get /dev entries . add struct device (dev) to dev_cache for each device on the system - device_ids_match - match devices file entries to /dev entries . match each du on cmd->use_devices to a dev in dev_cache, using device ID . on match, set du->dev, dev->id, dev->flags MATCHED_USE_ID - label_scan - read lvm headers and metadata from devices . filters are applied, those that do not need data from the device . filter-deviceid skips devs without MATCHED_USE_ID, i.e. skips /dev entries that are not listed in the devices file . read lvm label from dev . filters are applied, those that use data from the device . read lvm metadata from dev . add info/vginfo structs for PVs/VGs (info is "lvmcache") - device_ids_find_renamed_devs - handle devices with unstable devname ID where devname changed . this step only needed when devs do not have proper device IDs, and their dev names change, e.g. after reboot sdb becomes sdc. . detect incorrect match because PVID in the devices file entry does not match the PVID found when the device was read above . undo incorrect match between du and dev above . search system devices for new location of PVID . update devices file with new devnames for PVIDs on renamed devices . label_scan the renamed devs - continue with command processing
2020-06-23 21:25:41 +03:00
if ((device_id = _get_pvsummary_device_id(devl->dev->pvid, &device_id_type))) {
uint16_t idtype = idtype_from_str(device_id_type);
if (idtype) {
idname1 = device_id_system_read(cmd, dev1, idtype);
idname2 = device_id_system_read(cmd, dev2, idtype);
}
if (idname1)
same_id1 = !strcmp(idname1, device_id);
if (idname2)
same_id2 = !strcmp(idname2, device_id);
}
skip indexing devices used by LVs in more commands expands commit d5a06f9a7df5a43b2e2311db62ff8d3011217d74 "pvscan: skip indexing devices used by LVs" The dev cache index is expensive and slow, so limit it to commands that are used to observe the state of lvm. The index is only used to print warnings about incorrect device use by active LVs, e.g. if an LV is using a multipath component device instead of the multipath device. Commands that continue to use the index and print the warnings: fullreport, lvmdiskscan, vgs, lvs, pvs, vgdisplay, lvdisplay, pvdisplay, vgscan, lvscan, pvscan (excluding --cache) A couple other commands were borrowing the DEV_USED_FOR_LV flag to just check if a device was actively in use by LVs. These are converted to the new dev_is_used_by_active_lv().
2021-07-08 00:59:56 +03:00
has_lv1 = dev_is_used_by_active_lv(cmd, dev1, NULL, NULL, NULL, NULL);
has_lv2 = dev_is_used_by_active_lv(cmd, dev2, NULL, NULL, NULL, NULL);
lvmcache: use active LVs and device sizes to choose between duplicates If duplicate devices exist for a PV, and one device's size matches the PV size, but the other doesn't, then prefer the matching device. If one device is used by an active LV, prefer that device.
2016-03-29 21:29:39 +03:00
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
in_subsys1 = dev_subsystem_part_major(dt, dev1);
in_subsys2 = dev_subsystem_part_major(dt, dev2);
is_dm1 = dm_is_dm_major(dev1_major);
is_dm2 = dm_is_dm_major(dev2_major);
has_fs1 = dm_device_has_mounted_fs(dev1_major, dev1_minor);
has_fs2 = dm_device_has_mounted_fs(dev2_major, dev2_minor);
scan: use PV device name hint for choosing duplicate PV Prefer a device if its name matches the PV device name hint.
2019-09-27 19:34:55 +03:00
log_debug_cache("PV %s compare duplicates: %s %u:%u. %s %u:%u. device_hint %s.",
lvmcache: use active LVs and device sizes to choose between duplicates If duplicate devices exist for a PV, and one device's size matches the PV size, but the other doesn't, then prefer the matching device. If one device is used by an active LV, prefer that device.
2016-03-29 21:29:39 +03:00
devl->dev->pvid,
dev_name(dev1), dev1_major, dev1_minor,
scan: use PV device name hint for choosing duplicate PV Prefer a device if its name matches the PV device name hint.
2019-09-27 19:34:55 +03:00
dev_name(dev2), dev2_major, dev2_minor,
device_hint ?: "none");
lvmcache: use active LVs and device sizes to choose between duplicates If duplicate devices exist for a PV, and one device's size matches the PV size, but the other doesn't, then prefer the matching device. If one device is used by an active LV, prefer that device.
2016-03-29 21:29:39 +03:00
device usage based on devices file The LVM devices file lists devices that lvm can use. The default file is /etc/lvm/devices/system.devices, and the lvmdevices(8) command is used to add or remove device entries. If the file does not exist, or if lvm.conf includes use_devicesfile=0, then lvm will not use a devices file. When the devices file is in use, the regex filter is not used, and the filter settings in lvm.conf or on the command line are ignored. LVM records devices in the devices file using hardware-specific IDs, such as the WWID, and attempts to use subsystem-specific IDs for virtual device types. These device IDs are also written in the VG metadata. When no hardware or virtual ID is available, lvm falls back using the unstable device name as the device ID. When devnames are used, lvm performs extra scanning to find devices if their devname changes, e.g. after reboot. When proper device IDs are used, an lvm command will not look at devices outside the devices file, but when devnames are used as a fallback, lvm will scan devices outside the devices file to locate PVs on renamed devices. A config setting search_for_devnames can be used to control the scanning for renamed devname entries. Related to the devices file, the new command option --devices <devnames> allows a list of devices to be specified for the command to use, overriding the devices file. The listed devices act as a sort of devices file in terms of limiting which devices lvm will see and use. Devices that are not listed will appear to be missing to the lvm command. Multiple devices files can be kept in /etc/lvm/devices, which allows lvm to be used with different sets of devices, e.g. system devices do not need to be exposed to a specific application, and the application can use lvm on its own set of devices that are not exposed to the system. The option --devicesfile <filename> is used to select the devices file to use with the command. Without the option set, the default system devices file is used. Setting --devicesfile "" causes lvm to not use a devices file. An existing, empty devices file means lvm will see no devices. The new command vgimportdevices adds PVs from a VG to the devices file and updates the VG metadata to include the device IDs. vgimportdevices -a will import all VGs into the system devices file. LVM commands run by dmeventd not use a devices file by default, and will look at all devices on the system. A devices file can be created for dmeventd (/etc/lvm/devices/dmeventd.devices) If this file exists, lvm commands run by dmeventd will use it. Internal implementaion: - device_ids_read - read the devices file . add struct dev_use (du) to cmd->use_devices for each devices file entry - dev_cache_scan - get /dev entries . add struct device (dev) to dev_cache for each device on the system - device_ids_match - match devices file entries to /dev entries . match each du on cmd->use_devices to a dev in dev_cache, using device ID . on match, set du->dev, dev->id, dev->flags MATCHED_USE_ID - label_scan - read lvm headers and metadata from devices . filters are applied, those that do not need data from the device . filter-deviceid skips devs without MATCHED_USE_ID, i.e. skips /dev entries that are not listed in the devices file . read lvm label from dev . filters are applied, those that use data from the device . read lvm metadata from dev . add info/vginfo structs for PVs/VGs (info is "lvmcache") - device_ids_find_renamed_devs - handle devices with unstable devname ID where devname changed . this step only needed when devs do not have proper device IDs, and their dev names change, e.g. after reboot sdb becomes sdc. . detect incorrect match because PVID in the devices file entry does not match the PVID found when the device was read above . undo incorrect match between du and dev above . search system devices for new location of PVID . update devices file with new devnames for PVIDs on renamed devices . label_scan the renamed devs - continue with command processing
2020-06-23 21:25:41 +03:00
log_debug_cache("PV %s: device_id %s. %s is %s. %s is %s.",
devl->dev->pvid,
device_id ?: ".",
dev_name(dev1), idname1 ?: ".",
dev_name(dev2), idname2 ?: ".");
scan: use PV size for choosing duplicate PV Prefer a device if it matches the size of the PV.
2019-09-27 19:11:57 +03:00
log_debug_cache("PV %s: size %llu. %s is %llu. %s is %llu.",
devl->dev->pvid,
gcc: avoid warning: declaration of xxx shadows a global declaration Fix some gcc complaints again shadowing global declarations
2019-10-21 13:32:11 +03:00
(unsigned long long)pvsummary_size,
scan: use PV size for choosing duplicate PV Prefer a device if it matches the size of the PV.
2019-09-27 19:11:57 +03:00
dev_name(dev1), (unsigned long long)dev1_size,
dev_name(dev2), (unsigned long long)dev2_size);
lvmcache: fix duplicate handling with multiple scans Some commands scan labels to populate lvmcache multiple times, i.e. lvmcache_init, scan labels to fill lvmcache, lvmcache_destroy, then later repeat Each time labels are scanned, duplicates are detected, and preferred devices are chosen. Each time this is done within a single command, we want to choose the same preferred devices. So, check for existing preferences when choosing preferred devices. This also fixes a problem with the list of unused duplicate devs when run in an lvm shell. The devs had been allocated from cmd memory, resulting in invalid list entries between commands.
2016-06-06 23:20:55 +03:00
log_debug_cache("PV %s: %s was prev %s. %s was prev %s.",
devl->dev->pvid,
dev_name(dev1), prev_unchosen1 ? "not chosen" : "<none>",
dev_name(dev2), prev_unchosen2 ? "not chosen" : "<none>");
lvmcache: use active LVs and device sizes to choose between duplicates If duplicate devices exist for a PV, and one device's size matches the PV size, but the other doesn't, then prefer the matching device. If one device is used by an active LV, prefer that device.
2016-03-29 21:29:39 +03:00
log_debug_cache("PV %s: %s %s subsystem. %s %s subsystem.",
devl->dev->pvid,
dev_name(dev1), in_subsys1 ? "is in" : "is not in",
dev_name(dev2), in_subsys2 ? "is in" : "is not in");
log_debug_cache("PV %s: %s %s dm. %s %s dm.",
devl->dev->pvid,
dev_name(dev1), is_dm1 ? "is" : "is not",
dev_name(dev2), is_dm2 ? "is" : "is not");
log_debug_cache("PV %s: %s %s mounted fs. %s %s mounted fs.",
devl->dev->pvid,
dev_name(dev1), has_fs1 ? "has" : "has no",
dev_name(dev2), has_fs2 ? "has" : "has no");
log_debug_cache("PV %s: %s %s LV. %s %s LV.",
devl->dev->pvid,
dev_name(dev1), has_lv1 ? "is used for" : "is not used for",
dev_name(dev2), has_lv2 ? "is used for" : "is not used for");
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
coverity cleanups
2021-06-16 21:22:54 +03:00
free((void *)idname1);
free((void *)idname2);
idname1 = NULL;
idname2 = NULL;
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
change = 0;
lvmcache: fix duplicate handling with multiple scans Some commands scan labels to populate lvmcache multiple times, i.e. lvmcache_init, scan labels to fill lvmcache, lvmcache_destroy, then later repeat Each time labels are scanned, duplicates are detected, and preferred devices are chosen. Each time this is done within a single command, we want to choose the same preferred devices. So, check for existing preferences when choosing preferred devices. This also fixes a problem with the list of unused duplicate devs when run in an lvm shell. The devs had been allocated from cmd memory, resulting in invalid list entries between commands.
2016-06-06 23:20:55 +03:00
if (prev_unchosen1 && !prev_unchosen2) {
/* change to 2 (NB when unchosen is set we unprefer) */
change = 1;
reason = "of previous preference";
} else if (prev_unchosen2 && !prev_unchosen1) {
/* keep 1 (NB when unchosen is set we unprefer) */
reason = "of previous preference";
device usage based on devices file The LVM devices file lists devices that lvm can use. The default file is /etc/lvm/devices/system.devices, and the lvmdevices(8) command is used to add or remove device entries. If the file does not exist, or if lvm.conf includes use_devicesfile=0, then lvm will not use a devices file. When the devices file is in use, the regex filter is not used, and the filter settings in lvm.conf or on the command line are ignored. LVM records devices in the devices file using hardware-specific IDs, such as the WWID, and attempts to use subsystem-specific IDs for virtual device types. These device IDs are also written in the VG metadata. When no hardware or virtual ID is available, lvm falls back using the unstable device name as the device ID. When devnames are used, lvm performs extra scanning to find devices if their devname changes, e.g. after reboot. When proper device IDs are used, an lvm command will not look at devices outside the devices file, but when devnames are used as a fallback, lvm will scan devices outside the devices file to locate PVs on renamed devices. A config setting search_for_devnames can be used to control the scanning for renamed devname entries. Related to the devices file, the new command option --devices <devnames> allows a list of devices to be specified for the command to use, overriding the devices file. The listed devices act as a sort of devices file in terms of limiting which devices lvm will see and use. Devices that are not listed will appear to be missing to the lvm command. Multiple devices files can be kept in /etc/lvm/devices, which allows lvm to be used with different sets of devices, e.g. system devices do not need to be exposed to a specific application, and the application can use lvm on its own set of devices that are not exposed to the system. The option --devicesfile <filename> is used to select the devices file to use with the command. Without the option set, the default system devices file is used. Setting --devicesfile "" causes lvm to not use a devices file. An existing, empty devices file means lvm will see no devices. The new command vgimportdevices adds PVs from a VG to the devices file and updates the VG metadata to include the device IDs. vgimportdevices -a will import all VGs into the system devices file. LVM commands run by dmeventd not use a devices file by default, and will look at all devices on the system. A devices file can be created for dmeventd (/etc/lvm/devices/dmeventd.devices) If this file exists, lvm commands run by dmeventd will use it. Internal implementaion: - device_ids_read - read the devices file . add struct dev_use (du) to cmd->use_devices for each devices file entry - dev_cache_scan - get /dev entries . add struct device (dev) to dev_cache for each device on the system - device_ids_match - match devices file entries to /dev entries . match each du on cmd->use_devices to a dev in dev_cache, using device ID . on match, set du->dev, dev->id, dev->flags MATCHED_USE_ID - label_scan - read lvm headers and metadata from devices . filters are applied, those that do not need data from the device . filter-deviceid skips devs without MATCHED_USE_ID, i.e. skips /dev entries that are not listed in the devices file . read lvm label from dev . filters are applied, those that use data from the device . read lvm metadata from dev . add info/vginfo structs for PVs/VGs (info is "lvmcache") - device_ids_find_renamed_devs - handle devices with unstable devname ID where devname changed . this step only needed when devs do not have proper device IDs, and their dev names change, e.g. after reboot sdb becomes sdc. . detect incorrect match because PVID in the devices file entry does not match the PVID found when the device was read above . undo incorrect match between du and dev above . search system devices for new location of PVID . update devices file with new devnames for PVIDs on renamed devices . label_scan the renamed devs - continue with command processing
2020-06-23 21:25:41 +03:00
} else if (same_id1 && !same_id2) {
/* keep 1 */
reason = "device id";
} else if (same_id2 && !same_id1) {
/* change to 2 */
change = 1;
reason = "device id";
lvmcache: fix duplicate handling with multiple scans Some commands scan labels to populate lvmcache multiple times, i.e. lvmcache_init, scan labels to fill lvmcache, lvmcache_destroy, then later repeat Each time labels are scanned, duplicates are detected, and preferred devices are chosen. Each time this is done within a single command, we want to choose the same preferred devices. So, check for existing preferences when choosing preferred devices. This also fixes a problem with the list of unused duplicate devs when run in an lvm shell. The devs had been allocated from cmd memory, resulting in invalid list entries between commands.
2016-06-06 23:20:55 +03:00
} else if (has_lv1 && !has_lv2) {
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
/* keep 1 */
lvmcache: use active LVs and device sizes to choose between duplicates If duplicate devices exist for a PV, and one device's size matches the PV size, but the other doesn't, then prefer the matching device. If one device is used by an active LV, prefer that device.
2016-03-29 21:29:39 +03:00
reason = "device is used by LV";
} else if (has_lv2 && !has_lv1) {
/* change to 2 */
change = 1;
reason = "device is used by LV";
scan: use PV size for choosing duplicate PV Prefer a device if it matches the size of the PV.
2019-09-27 19:11:57 +03:00
} else if (same_size1 && !same_size2) {
/* keep 1 */
reason = "device size is correct";
} else if (same_size2 && !same_size1) {
/* change to 2 */
change = 1;
reason = "device size is correct";
scan: use PV device name hint for choosing duplicate PV Prefer a device if its name matches the PV device name hint.
2019-09-27 19:34:55 +03:00
} else if (same_name1 && !same_name2) {
/* keep 1 */
reason = "device name matches previous";
} else if (same_name2 && !same_name1) {
/* change to 2 */
change = 1;
reason = "device name matches previous";
lvmcache: use active LVs and device sizes to choose between duplicates If duplicate devices exist for a PV, and one device's size matches the PV size, but the other doesn't, then prefer the matching device. If one device is used by an active LV, prefer that device.
2016-03-29 21:29:39 +03:00
} else if (has_fs1 && !has_fs2) {
/* keep 1 */
reason = "device has fs mounted";
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
} else if (has_fs2 && !has_fs1) {
/* change to 2 */
change = 1;
lvmcache: use active LVs and device sizes to choose between duplicates If duplicate devices exist for a PV, and one device's size matches the PV size, but the other doesn't, then prefer the matching device. If one device is used by an active LV, prefer that device.
2016-03-29 21:29:39 +03:00
reason = "device has fs mounted";
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
} else if (is_dm1 && !is_dm2) {
/* keep 1 */
lvmcache: use active LVs and device sizes to choose between duplicates If duplicate devices exist for a PV, and one device's size matches the PV size, but the other doesn't, then prefer the matching device. If one device is used by an active LV, prefer that device.
2016-03-29 21:29:39 +03:00
reason = "device is in dm subsystem";
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
} else if (is_dm2 && !is_dm1) {
/* change to 2 */
change = 1;
lvmcache: use active LVs and device sizes to choose between duplicates If duplicate devices exist for a PV, and one device's size matches the PV size, but the other doesn't, then prefer the matching device. If one device is used by an active LV, prefer that device.
2016-03-29 21:29:39 +03:00
reason = "device is in dm subsystem";
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
} else if (in_subsys1 && !in_subsys2) {
/* keep 1 */
lvmcache: use active LVs and device sizes to choose between duplicates If duplicate devices exist for a PV, and one device's size matches the PV size, but the other doesn't, then prefer the matching device. If one device is used by an active LV, prefer that device.
2016-03-29 21:29:39 +03:00
reason = "device is in subsystem";
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
} else if (in_subsys2 && !in_subsys1) {
/* change to 2 */
change = 1;
lvmcache: use active LVs and device sizes to choose between duplicates If duplicate devices exist for a PV, and one device's size matches the PV size, but the other doesn't, then prefer the matching device. If one device is used by an active LV, prefer that device.
2016-03-29 21:29:39 +03:00
reason = "device is in subsystem";
} else {
reason = "device was seen first";
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
}
improve duplicate pv handling for md components Eliminate md components at the start so they don't interfere with actual duplicates, and don't need to be removed later. This also allows for choosing no copy of a PVID if they all happen to be md components.
2019-08-01 23:04:10 +03:00
if (change)
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
dev1 = dev2;
scan: move warnings about duplicate devices We have been warning about duplicate devices (and disabling lvmetad) immediately when the dup was detected (during label_scan). Move the warnings (and the disabling) to happen later, after label_scan is finished. This lets us avoid an unwanted warning message about duplicates in the special case were md components are eliminated during the duplicate device resolution.
2018-05-21 22:20:19 +03:00
dev1->duplicate_prefer_reason = reason;
lvmcache: use active LVs and device sizes to choose between duplicates If duplicate devices exist for a PV, and one device's size matches the PV size, but the other doesn't, then prefer the matching device. If one device is used by an active LV, prefer that device.
2016-03-29 21:29:39 +03:00
}
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
improve duplicate pv handling for md components Eliminate md components at the start so they don't interfere with actual duplicates, and don't need to be removed later. This also allows for choosing no copy of a PVID if they all happen to be md components.
2019-08-01 23:04:10 +03:00
/*
* At the end of the loop, dev1 is the device we prefer to
* use. If there's no info struct, it means there's no dev
* currently in lvmcache for this PVID, so just add the
* preferred one (dev1). If dev1 is different from the dev
* currently in lvmcache, then drop the dev in lvmcache and
* add dev1 to lvmcache. If dev1 is the same as the dev
* in lvmcache already, then no changes are needed and the
* altdevs all become unused duplicates.
*/
if (!info) {
log_debug_cache("PV %s with duplicates will use %s.", pvid, dev_name(dev1));
if (!(devl_add = _get_devl_in_device_list(dev1, &altdevs))) {
/* shouldn't happen */
log_error(INTERNAL_ERROR "PV %s with duplicates no alternate list entry for %s", pvid, dev_name(dev1));
dm_list_splice(&new_unused, &altdevs);
goto next;
}
dm_list_move(add_cache_devs, &devl_add->list);
} else if (dev1 != info->dev) {
log_debug_cache("PV %s with duplicates will change from %s to %s.",
pvid, dev_name(info->dev), dev_name(dev1));
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
/*
improve duplicate pv handling for md components Eliminate md components at the start so they don't interfere with actual duplicates, and don't need to be removed later. This also allows for choosing no copy of a PVID if they all happen to be md components.
2019-08-01 23:04:10 +03:00
* Move the preferred device (dev1) from altdevs
* to add_cache_devs. Create a del_cache_devs entry
* for the current lvmcache device to drop.
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
*/
improve duplicate pv handling for md components Eliminate md components at the start so they don't interfere with actual duplicates, and don't need to be removed later. This also allows for choosing no copy of a PVID if they all happen to be md components.
2019-08-01 23:04:10 +03:00
if (!(devl_add = _get_devl_in_device_list(dev1, &altdevs))) {
/* shouldn't happen */
log_error(INTERNAL_ERROR "PV %s with duplicates no alternate list entry for %s", pvid, dev_name(dev1));
dm_list_splice(&new_unused, &altdevs);
goto next;
}
dm_list_move(add_cache_devs, &devl_add->list);
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
improve duplicate pv handling for md components Eliminate md components at the start so they don't interfere with actual duplicates, and don't need to be removed later. This also allows for choosing no copy of a PVID if they all happen to be md components.
2019-08-01 23:04:10 +03:00
if ((devl_del = zalloc(sizeof(*devl_del)))) {
devl_del->dev = info->dev;
dm_list_add(del_cache_devs, &devl_del->list);
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
}
lvmcache: use active LVs and device sizes to choose between duplicates If duplicate devices exist for a PV, and one device's size matches the PV size, but the other doesn't, then prefer the matching device. If one device is used by an active LV, prefer that device.
2016-03-29 21:29:39 +03:00
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
} else {
improve duplicate pv handling for md components Eliminate md components at the start so they don't interfere with actual duplicates, and don't need to be removed later. This also allows for choosing no copy of a PVID if they all happen to be md components.
2019-08-01 23:04:10 +03:00
/*
* Keeping existing dev in lvmcache for this PVID.
*/
log_debug_cache("PV %s with duplicates will continue using %s.",
pvid, dev_name(info->dev));
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
}
/*
improve duplicate pv handling for md components Eliminate md components at the start so they don't interfere with actual duplicates, and don't need to be removed later. This also allows for choosing no copy of a PVID if they all happen to be md components.
2019-08-01 23:04:10 +03:00
* Any altdevs entries not chosen are moved to _unused_duplicates.
lvmcache: renaming functions and variables related to duplicates, no functional changes.
2019-08-01 21:50:04 +03:00
* del_cache_devs being dropped are moved to _unused_duplicates
* after being dropped. So, _unused_duplicates represents all
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
* duplicates not being used in lvmcache.
*/
lvmcache: fix duplicate handling with multiple scans Some commands scan labels to populate lvmcache multiple times, i.e. lvmcache_init, scan labels to fill lvmcache, lvmcache_destroy, then later repeat Each time labels are scanned, duplicates are detected, and preferred devices are chosen. Each time this is done within a single command, we want to choose the same preferred devices. So, check for existing preferences when choosing preferred devices. This also fixes a problem with the list of unused duplicate devs when run in an lvm shell. The devs had been allocated from cmd memory, resulting in invalid list entries between commands.
2016-06-06 23:20:55 +03:00
dm_list_splice(&new_unused, &altdevs);
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
goto next;
}
scan: use new label_scan for lvmcache_label_scan To do label scanning, lvm code calls lvmcache_label_scan(). Change lvmcache_label_scan() to use the new label_scan() based on bcache. Also add lvmcache_label_rescan_vg() which calls the new label_scan_devs() which does label scanning on only the specified devices. This is for a subsequent commit and is not yet used.
2018-02-07 22:14:08 +03:00
/*
* The initial label_scan at the start of the command is done without
* holding VG locks. Then for each VG identified during the label_scan,
* vg_read(vgname) is called while holding the VG lock. The labels
* and metadata on this VG's devices could have changed between the
* initial unlocked label_scan and the current vg_read(). So, we reread
* the labels/metadata for each device in the VG now that we hold the
* lock, and use this for processing the VG.
*
* A label scan is ultimately creating associations between devices
* and VGs so that when vg_read wants to get VG metadata, it knows
scan: skip device rescan in vg_read For reporting commands (pvs,vgs,lvs,pvdisplay,vgdisplay,lvdisplay) we do not need to repeat the label scan of devices in vg_read if they all had matching metadata in the initial label scan. The data read by label scan can just be reused for the vg_read. This cuts the amount of device i/o in half, from two reads of each device to one. We have to be careful to avoid repairing the VG if we've skipped rescanning. (The VG repair code is very poor, and will be redone soon.)
2018-04-19 00:29:42 +03:00
* which devices to read.
*
* It's possible that a VG is being modified during the first label
* scan, causing the scan to see inconsistent metadata on different
* devs in the VG. It's possible that those modifications are
* adding/removing devs from the VG, in which case the device/VG
* associations in lvmcache after the scan are not correct.
* NB. It's even possible the VG was removed completely between
* label scan and here, in which case we'd not find the VG in
* lvmcache after this rescan.
*
* A scan will also create in incorrect/incomplete picture of a VG
* when devices have no metadata areas. The scan does not use
* VG metadata to figure out that a dev with no metadata belongs
* to a particular VG, so a device with no mdas will not be linked
* to that VG after a scan.
scan: use new label_scan for lvmcache_label_scan To do label scanning, lvm code calls lvmcache_label_scan(). Change lvmcache_label_scan() to use the new label_scan() based on bcache. Also add lvmcache_label_rescan_vg() which calls the new label_scan_devs() which does label scanning on only the specified devices. This is for a subsequent commit and is not yet used.
2018-02-07 22:14:08 +03:00
*/
scanning: open devs rw when rescanning for write When vg_read rescans devices with the intention of writing the VG, the label rescan can open the devs RW so they do not need to be closed and reopened RW in dev_write_bytes.
2019-06-12 00:17:24 +03:00
static int _label_rescan_vg(struct cmd_context *cmd, const char *vgname, const char *vgid, int rw)
scan: use new label_scan for lvmcache_label_scan To do label scanning, lvm code calls lvmcache_label_scan(). Change lvmcache_label_scan() to use the new label_scan() based on bcache. Also add lvmcache_label_rescan_vg() which calls the new label_scan_devs() which does label scanning on only the specified devices. This is for a subsequent commit and is not yet used.
2018-02-07 22:14:08 +03:00
{
struct dm_list devs;
scan: add some missing frees some objects had been moved out of mem pools.
2018-05-14 21:38:16 +03:00
struct device_list *devl, *devl2;
clvmd: separate saved_vg from vginfo The clvmd saved_vg data is independent from the normal lvm lvmcache vginfo data, so separate saved_vg from vginfo. Normal lvm doesn't need to use save_vg at all, and in clvmd, lvmcache changes on vginfo can be made without worrying about unwanted effects on saved_vg.
2018-05-03 00:58:49 +03:00
struct lvmcache_vginfo *vginfo;
lvmcache: fix loop freeing infos valgrind was concerned about loop through vginfo->infos, so grab info from dev.
2018-05-14 21:45:55 +03:00
struct lvmcache_info *info;
scan: use new label_scan for lvmcache_label_scan To do label scanning, lvm code calls lvmcache_label_scan(). Change lvmcache_label_scan() to use the new label_scan() based on bcache. Also add lvmcache_label_rescan_vg() which calls the new label_scan_devs() which does label scanning on only the specified devices. This is for a subsequent commit and is not yet used.
2018-02-07 22:14:08 +03:00
dm_list_init(&devs);
if (!(vginfo = lvmcache_vginfo_from_vgname(vgname, vgid)))
return_0;
dm_list_iterate_items(info, &vginfo->infos) {
device_mapper: remove dbg_malloc. I wrote dbg_malloc before we had valgrind. These days there's just no need.
2018-06-08 15:40:53 +03:00
if (!(devl = malloc(sizeof(*devl)))) {
scan: use new label_scan for lvmcache_label_scan To do label scanning, lvm code calls lvmcache_label_scan(). Change lvmcache_label_scan() to use the new label_scan() based on bcache. Also add lvmcache_label_rescan_vg() which calls the new label_scan_devs() which does label scanning on only the specified devices. This is for a subsequent commit and is not yet used.
2018-02-07 22:14:08 +03:00
log_error("device_list element allocation failed");
return 0;
}
devl->dev = info->dev;
dm_list_add(&devs, &devl->list);
}
lvmcache: fix loop freeing infos valgrind was concerned about loop through vginfo->infos, so grab info from dev.
2018-05-14 21:45:55 +03:00
/* Delete info for each dev, deleting the last info will delete vginfo. */
dm_list_iterate_items(devl, &devs)
lvmcache_del_dev(devl->dev);
scan: use new label_scan for lvmcache_label_scan To do label scanning, lvm code calls lvmcache_label_scan(). Change lvmcache_label_scan() to use the new label_scan() based on bcache. Also add lvmcache_label_rescan_vg() which calls the new label_scan_devs() which does label scanning on only the specified devices. This is for a subsequent commit and is not yet used.
2018-02-07 22:14:08 +03:00
scan: skip device rescan in vg_read For reporting commands (pvs,vgs,lvs,pvdisplay,vgdisplay,lvdisplay) we do not need to repeat the label scan of devices in vg_read if they all had matching metadata in the initial label scan. The data read by label scan can just be reused for the vg_read. This cuts the amount of device i/o in half, from two reads of each device to one. We have to be careful to avoid repairing the VG if we've skipped rescanning. (The VG repair code is very poor, and will be redone soon.)
2018-04-19 00:29:42 +03:00
/* Dropping the last info struct is supposed to drop vginfo. */
if ((vginfo = lvmcache_vginfo_from_vgname(vgname, vgid)))
log_warn("VG info not dropped before rescan of %s", vgname);
scanning: open devs rw when rescanning for write When vg_read rescans devices with the intention of writing the VG, the label rescan can open the devs RW so they do not need to be closed and reopened RW in dev_write_bytes.
2019-06-12 00:17:24 +03:00
if (rw)
label_scan_devs_rw(cmd, cmd->filter, &devs);
else
label_scan_devs(cmd, cmd->filter, &devs);
scan: use new label_scan for lvmcache_label_scan To do label scanning, lvm code calls lvmcache_label_scan(). Change lvmcache_label_scan() to use the new label_scan() based on bcache. Also add lvmcache_label_rescan_vg() which calls the new label_scan_devs() which does label scanning on only the specified devices. This is for a subsequent commit and is not yet used.
2018-02-07 22:14:08 +03:00
scan: add some missing frees some objects had been moved out of mem pools.
2018-05-14 21:38:16 +03:00
dm_list_iterate_items_safe(devl, devl2, &devs) {
dm_list_del(&devl->list);
device_mapper: remove dbg_malloc. I wrote dbg_malloc before we had valgrind. These days there's just no need.
2018-06-08 15:40:53 +03:00
free(devl);
scan: add some missing frees some objects had been moved out of mem pools.
2018-05-14 21:38:16 +03:00
}
clvmd: defer freeing saved vgs To avoid the chance of freeing a saved vg while another code path is using it, defer freeing saved vgs until all the lvmcache content is dropped for the vg.
2018-05-01 00:48:53 +03:00
if (!(vginfo = lvmcache_vginfo_from_vgname(vgname, vgid))) {
log_warn("VG info not found after rescan of %s", vgname);
return 0;
}
scan: use new label_scan for lvmcache_label_scan To do label scanning, lvm code calls lvmcache_label_scan(). Change lvmcache_label_scan() to use the new label_scan() based on bcache. Also add lvmcache_label_rescan_vg() which calls the new label_scan_devs() which does label scanning on only the specified devices. This is for a subsequent commit and is not yet used.
2018-02-07 22:14:08 +03:00
return 1;
}
scanning: open devs rw when rescanning for write When vg_read rescans devices with the intention of writing the VG, the label rescan can open the devs RW so they do not need to be closed and reopened RW in dev_write_bytes.
2019-06-12 00:17:24 +03:00
int lvmcache_label_rescan_vg(struct cmd_context *cmd, const char *vgname, const char *vgid)
{
return _label_rescan_vg(cmd, vgname, vgid, 0);
}
int lvmcache_label_rescan_vg_rw(struct cmd_context *cmd, const char *vgname, const char *vgid)
{
return _label_rescan_vg(cmd, vgname, vgid, 1);
}
metadata: open rw fd before closing ro fd lvm opens devices readonly to scan them, but needs to open then readwrite to update the metadata. Previously, the ro fd was closed before the rw fd was opened, leaving a small gap where the dev was not held open, and during which the dev could possibly change which storage it referred to. With the bcache_change_fd() interface, lvm opens a rw fd on a device to be written, tells bcache to change to the new rw fd, and closes the ro fd. . open dev ro . read dev with the ro fd (label_scan) . lock vg (ex for writing) . open dev rw . close ro fd . rescan dev to check if the metadata changed between the scan and the lock . if the metadata did change, reread in full . write the metadata
2020-09-18 22:42:23 +03:00
int lvmcache_label_reopen_vg_rw(struct cmd_context *cmd, const char *vgname, const char *vgid)
{
struct lvmcache_vginfo *vginfo;
struct lvmcache_info *info;
if (!(vginfo = lvmcache_vginfo_from_vgname(vgname, vgid)))
return_0;
dm_list_iterate_items(info, &vginfo->infos) {
if (!label_scan_reopen_rw(info->dev))
return_0;
}
return 1;
}
md component detection changes Move extra md component detection into the label scan phase. It had been in set_pv_devices which was deep within the vg_read phase, which wasn't a good place (better to detect that earlier.) Now that pv metadata info is available in the scan phase, the pv details (size and device_hint) can be used for extra md checking. Use the device_hint from the pv metadata to trigger a full md component check if the device_hint begins with /dev/md. Stop triggering full md component checks based on missing udev info for a dev. Changes to tests to reflect that the code is now detecting md components in some test case that it wasn't before.
2021-02-06 01:16:03 +03:00
/*
* During label_scan, the md component filter is applied to each device after
* the device header has been read. This often just checks the start of the
* device for an md header, and if the device has an md header at the end, the
* md component filter wouldn't detect it. In some cases, the full md filter
* is enabled during label_scan, in which case the md component filter will
* check both the start and end of the device for md superblocks.
*
* In this function, after label_scan is done, we may decide that a full md
* component check should be applied to a device if it hasn't been yet. This
* is based on some clues or uncertainty that arose during label_scan.
*
* label_scan saved metadata info about pvs in lvmcache pvsummaries. That
* pvsummary metadata includes the pv size. So now, after label_scan is done,
* we can compare the pv size with the size of the device the pv was read from.
* If the pv and dev sizes do not match, it can sometimes be normal, but other
* times it can be a clue that label_scan mistakenly read the pv from an md
* component device instead of from the md device itself. So for unmatching
* sizes, we do a full md component check on the device.
*/
void lvmcache_extra_md_component_checks(struct cmd_context *cmd)
{
struct lvmcache_vginfo *vginfo, *vginfo2;
struct lvmcache_info *info, *info2;
struct device *dev;
const char *device_hint;
uint64_t devsize, pvsize;
fix for md component detection changes And some fine tuning of when the checks are applied in "start" mode.
2021-02-08 20:23:42 +03:00
int do_check_size, do_check_name;
int md_check_start;
md component detection changes Move extra md component detection into the label scan phase. It had been in set_pv_devices which was deep within the vg_read phase, which wasn't a good place (better to detect that earlier.) Now that pv metadata info is available in the scan phase, the pv details (size and device_hint) can be used for extra md checking. Use the device_hint from the pv metadata to trigger a full md component check if the device_hint begins with /dev/md. Stop triggering full md component checks based on missing udev info for a dev. Changes to tests to reflect that the code is now detecting md components in some test case that it wasn't before.
2021-02-06 01:16:03 +03:00
/*
* use_full_md_check: if set then no more needs to be done here,
* all devs have already been fully checked as md components.
*
* md_component_checks "full": use_full_md_check was set, and caused
* filter-md to already do a full check, no more is needed.
*
* md_component_checks "start": skip end of device md component checks,
* the start of device has already been checked by filter-md.
*
* md_component_checks "auto": do full checks only when lvm finds some
* clue or reasons to believe it might be useful, which is what this
* function is looking for.
*/
if (!cmd->md_component_detection || cmd->use_full_md_check ||
fix for md component detection changes And some fine tuning of when the checks are applied in "start" mode.
2021-02-08 20:23:42 +03:00
!strcmp(cmd->md_component_checks, "none"))
md component detection changes Move extra md component detection into the label scan phase. It had been in set_pv_devices which was deep within the vg_read phase, which wasn't a good place (better to detect that earlier.) Now that pv metadata info is available in the scan phase, the pv details (size and device_hint) can be used for extra md checking. Use the device_hint from the pv metadata to trigger a full md component check if the device_hint begins with /dev/md. Stop triggering full md component checks based on missing udev info for a dev. Changes to tests to reflect that the code is now detecting md components in some test case that it wasn't before.
2021-02-06 01:16:03 +03:00
return;
fix for md component detection changes And some fine tuning of when the checks are applied in "start" mode.
2021-02-08 20:23:42 +03:00
md_check_start = !strcmp(cmd->md_component_checks, "start");
md component detection changes Move extra md component detection into the label scan phase. It had been in set_pv_devices which was deep within the vg_read phase, which wasn't a good place (better to detect that earlier.) Now that pv metadata info is available in the scan phase, the pv details (size and device_hint) can be used for extra md checking. Use the device_hint from the pv metadata to trigger a full md component check if the device_hint begins with /dev/md. Stop triggering full md component checks based on missing udev info for a dev. Changes to tests to reflect that the code is now detecting md components in some test case that it wasn't before.
2021-02-06 01:16:03 +03:00
/*
* We want to avoid extra scanning for end-of-device md superblocks
* whenever possible, since it can add up to a lot of extra io if we're
* not careful to do it only when there's a good reason to believe a
* dev is an md component.
*
* If the pv/dev size mismatches are commonly occuring for
* non-md-components then we'll want to stop using that as a trigger
* for the full md check.
*/
dm_list_iterate_items_safe(vginfo, vginfo2, &_vginfos) {
dm_list_iterate_items_safe(info, info2, &vginfo->infos) {
dev = info->dev;
device_hint = _get_pvsummary_device_hint(dev->pvid);
pvsize = _get_pvsummary_size(dev->pvid);
devsize = dev->size;
fix for md component detection changes And some fine tuning of when the checks are applied in "start" mode.
2021-02-08 20:23:42 +03:00
do_check_size = 0;
do_check_name = 0;
md component detection changes Move extra md component detection into the label scan phase. It had been in set_pv_devices which was deep within the vg_read phase, which wasn't a good place (better to detect that earlier.) Now that pv metadata info is available in the scan phase, the pv details (size and device_hint) can be used for extra md checking. Use the device_hint from the pv metadata to trigger a full md component check if the device_hint begins with /dev/md. Stop triggering full md component checks based on missing udev info for a dev. Changes to tests to reflect that the code is now detecting md components in some test case that it wasn't before.
2021-02-06 01:16:03 +03:00
if (!devsize && !dev_get_size(dev, &devsize))
log_debug("No size for %s.", dev_name(dev));
/*
* PV larger than dev not common; dev larger than PV
* can be common, but not as often as PV larger.
*/
if (pvsize && devsize && (pvsize != devsize))
fix for md component detection changes And some fine tuning of when the checks are applied in "start" mode.
2021-02-08 20:23:42 +03:00
do_check_size = 1;
if (device_hint && !strncmp(device_hint, "/dev/md", 7))
do_check_name = 1;
if (!do_check_size && !do_check_name)
continue;
md component detection changes Move extra md component detection into the label scan phase. It had been in set_pv_devices which was deep within the vg_read phase, which wasn't a good place (better to detect that earlier.) Now that pv metadata info is available in the scan phase, the pv details (size and device_hint) can be used for extra md checking. Use the device_hint from the pv metadata to trigger a full md component check if the device_hint begins with /dev/md. Stop triggering full md component checks based on missing udev info for a dev. Changes to tests to reflect that the code is now detecting md components in some test case that it wasn't before.
2021-02-06 01:16:03 +03:00
fix for md component detection changes And some fine tuning of when the checks are applied in "start" mode.
2021-02-08 20:23:42 +03:00
/*
* If only the size is different (which can be fairly
* common for non-md-component devs) and the user has
* set "start" to disable full md checks, then skip it.
* If the size is different, *and* the device name hint
* looks like an md device, then it seems very likely
* to be an md component, so do a full check on it even
* if the user has set "start".
*
* In "auto" mode, do a full check if either the size
* or the name indicates a possible md component.
*/
if (do_check_size && !do_check_name && md_check_start) {
log_debug("extra md component check skip %llu %llu device_hint %s dev %s",
md component detection changes Move extra md component detection into the label scan phase. It had been in set_pv_devices which was deep within the vg_read phase, which wasn't a good place (better to detect that earlier.) Now that pv metadata info is available in the scan phase, the pv details (size and device_hint) can be used for extra md checking. Use the device_hint from the pv metadata to trigger a full md component check if the device_hint begins with /dev/md. Stop triggering full md component checks based on missing udev info for a dev. Changes to tests to reflect that the code is now detecting md components in some test case that it wasn't before.
2021-02-06 01:16:03 +03:00
(unsigned long long)pvsize, (unsigned long long)devsize,
device_hint ?: "none", dev_name(dev));
fix for md component detection changes And some fine tuning of when the checks are applied in "start" mode.
2021-02-08 20:23:42 +03:00
continue;
}
md component detection changes Move extra md component detection into the label scan phase. It had been in set_pv_devices which was deep within the vg_read phase, which wasn't a good place (better to detect that earlier.) Now that pv metadata info is available in the scan phase, the pv details (size and device_hint) can be used for extra md checking. Use the device_hint from the pv metadata to trigger a full md component check if the device_hint begins with /dev/md. Stop triggering full md component checks based on missing udev info for a dev. Changes to tests to reflect that the code is now detecting md components in some test case that it wasn't before.
2021-02-06 01:16:03 +03:00
fix for md component detection changes And some fine tuning of when the checks are applied in "start" mode.
2021-02-08 20:23:42 +03:00
log_debug("extra md component check %llu %llu device_hint %s dev %s",
(unsigned long long)pvsize, (unsigned long long)devsize,
device_hint ?: "none", dev_name(dev));
devices: rework libudev usage related to config settings: obtain_device_info_from_udev (controls if lvm gets a list of devices from readdir /dev or from libudev) external_device_info_source (controls if lvm asks libudev for device information) . Make the obtain_device_list_from_udev setting affect only the choice of readdir /dev vs libudev. The setting no longer controls if udev is used for device type checks. . Change obtain_device_list_from_udev default to 0. This helps avoid boot timeouts due to slow libudev queries, avoids reported failures from udev_enumerate_scan_devices, and avoids delays from "device not initialized in udev database" errors. Even without errors, for a system booting with 1024 PVs, lvm2-pvscan times improve from about 100 sec to 15 sec, and the pvscan command from about 64 sec to about 4 sec. . For external_device_info_source="none", remove all libudev device info queries, and use only lvm native device info. . For external_device_info_source="udev", first check lvm native device info, then check libudev info. . Remove sleep/retry loop when attempting libudev queries for device info. udev info will simply be skipped if it's not immediately available. . Only set up a libdev connection if it will be used by obtain_device_list_from_udev/external_device_info_source. . For native multipath component detection, use /etc/multipath/wwids. If a device has a wwid matching an entry in the wwids file, then it's considered a multipath component. This is necessary to natively detect multipath components when the mpath device is not set up.
2021-06-09 01:12:09 +03:00
if (dev_is_md_component(cmd, dev, NULL, 1)) {
fix for md component detection changes And some fine tuning of when the checks are applied in "start" mode.
2021-02-08 20:23:42 +03:00
log_debug("dropping PV from md component %s", dev_name(dev));
dev->flags &= ~DEV_SCAN_FOUND_LABEL;
/* lvmcache_del will also delete vginfo if info was last one */
lvmcache_del(info);
lvmcache_del_dev_from_duplicates(dev);
cmd->filter->wipe(cmd, cmd->filter, dev, NULL);
md component detection changes Move extra md component detection into the label scan phase. It had been in set_pv_devices which was deep within the vg_read phase, which wasn't a good place (better to detect that earlier.) Now that pv metadata info is available in the scan phase, the pv details (size and device_hint) can be used for extra md checking. Use the device_hint from the pv metadata to trigger a full md component check if the device_hint begins with /dev/md. Stop triggering full md component checks based on missing udev info for a dev. Changes to tests to reflect that the code is now detecting md components in some test case that it wasn't before.
2021-02-06 01:16:03 +03:00
}
}
}
}
lvmcache: simplify Recent changes allow some major simplification of the way lvmcache works and is used. lvmcache_label_scan is now called in a controlled fashion at the start of commands, and not via various unpredictable side effects. Remove various calls to it from other places. lvmcache_label_scan should not be called from anywhere during a command, because it produces an incorrect representation of PVs with no MDAs, and misclassifies them as orphans. This has been a long standing problem. The invalid flag and rescanning based on that is no longer used and removed. The 'force' variation is no longer needed and removed.
2018-04-09 21:40:49 +03:00
/*
* Uses label_scan to populate lvmcache with 'vginfo' struct for each VG
* and associated 'info' structs for those VGs. Only VG summary information
* is used to assemble the vginfo/info during the scan, so the resulting
* representation of VG/PV state is incomplete and even incorrect.
* Specifically, PVs with no MDAs are considered orphans and placed in the
* orphan vginfo by lvmcache_label_scan. This is corrected during the
* processing phase as each vg_read() uses VG metadata for each VG to correct
* the lvmcache state, i.e. it moves no-MDA PVs from the orphan vginfo onto
* the correct vginfo. Once vg_read() is finished for all VGs, all of the
* incorrectly placed PVs should have been moved from the orphan vginfo
* onto their correct vginfo's, and the orphan vginfo should (in theory)
* represent only real orphan PVs. (Note: if lvmcache_label_scan is run
* after vg_read udpates to lvmcache state, then the lvmcache will be
* incorrect again, so do not run lvmcache_label_scan during the
* processing phase.)
*
* TODO: in this label scan phase, don't stash no-MDA PVs into the
* orphan VG. We know that's a fiction, and it can have harmful/damaging
* results. Instead, put them into a temporary list where they can be
* pulled from later when vg_read uses metadata to resolve which VG
* they actually belong to.
*/
vgrename: use process_each_vg Use process_each_vg() to lock and read the old VG, and then call the main vgrename code. When real VG names are used (not a UUID in place of the old name), the command still pre-locks the new name (when strcmp wants it locked first), before calling process_each_vg on the old name. In the case where the old name is replaced with a UUID, process_each_vg now translates that UUID into the real VG name, which it locks and reads. In this case, we cannot do pre-locking to maintain lock ordering because the old name is unknown. So, in this case the strcmp based lock ordering is suppressed and the old name is always locked first. This opens a remote chance for lock ordering conflict between racing vgrenames between two names where one or both commands use the UUID.
2015-12-01 23:09:01 +03:00
int lvmcache_label_scan(struct cmd_context *cmd)
A new cache.
2002-11-18 16:53:58 +03:00
{
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
struct dm_list del_cache_devs;
struct dm_list add_cache_devs;
device usage based on devices file The LVM devices file lists devices that lvm can use. The default file is /etc/lvm/devices/system.devices, and the lvmdevices(8) command is used to add or remove device entries. If the file does not exist, or if lvm.conf includes use_devicesfile=0, then lvm will not use a devices file. When the devices file is in use, the regex filter is not used, and the filter settings in lvm.conf or on the command line are ignored. LVM records devices in the devices file using hardware-specific IDs, such as the WWID, and attempts to use subsystem-specific IDs for virtual device types. These device IDs are also written in the VG metadata. When no hardware or virtual ID is available, lvm falls back using the unstable device name as the device ID. When devnames are used, lvm performs extra scanning to find devices if their devname changes, e.g. after reboot. When proper device IDs are used, an lvm command will not look at devices outside the devices file, but when devnames are used as a fallback, lvm will scan devices outside the devices file to locate PVs on renamed devices. A config setting search_for_devnames can be used to control the scanning for renamed devname entries. Related to the devices file, the new command option --devices <devnames> allows a list of devices to be specified for the command to use, overriding the devices file. The listed devices act as a sort of devices file in terms of limiting which devices lvm will see and use. Devices that are not listed will appear to be missing to the lvm command. Multiple devices files can be kept in /etc/lvm/devices, which allows lvm to be used with different sets of devices, e.g. system devices do not need to be exposed to a specific application, and the application can use lvm on its own set of devices that are not exposed to the system. The option --devicesfile <filename> is used to select the devices file to use with the command. Without the option set, the default system devices file is used. Setting --devicesfile "" causes lvm to not use a devices file. An existing, empty devices file means lvm will see no devices. The new command vgimportdevices adds PVs from a VG to the devices file and updates the VG metadata to include the device IDs. vgimportdevices -a will import all VGs into the system devices file. LVM commands run by dmeventd not use a devices file by default, and will look at all devices on the system. A devices file can be created for dmeventd (/etc/lvm/devices/dmeventd.devices) If this file exists, lvm commands run by dmeventd will use it. Internal implementaion: - device_ids_read - read the devices file . add struct dev_use (du) to cmd->use_devices for each devices file entry - dev_cache_scan - get /dev entries . add struct device (dev) to dev_cache for each device on the system - device_ids_match - match devices file entries to /dev entries . match each du on cmd->use_devices to a dev in dev_cache, using device ID . on match, set du->dev, dev->id, dev->flags MATCHED_USE_ID - label_scan - read lvm headers and metadata from devices . filters are applied, those that do not need data from the device . filter-deviceid skips devs without MATCHED_USE_ID, i.e. skips /dev entries that are not listed in the devices file . read lvm label from dev . filters are applied, those that use data from the device . read lvm metadata from dev . add info/vginfo structs for PVs/VGs (info is "lvmcache") - device_ids_find_renamed_devs - handle devices with unstable devname ID where devname changed . this step only needed when devs do not have proper device IDs, and their dev names change, e.g. after reboot sdb becomes sdc. . detect incorrect match because PVID in the devices file entry does not match the PVID found when the device was read above . undo incorrect match between du and dev above . search system devices for new location of PVID . update devices file with new devnames for PVIDs on renamed devices . label_scan the renamed devs - continue with command processing
2020-06-23 21:25:41 +03:00
struct dm_list renamed_devs;
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
struct lvmcache_info *info;
struct device_list *devl;
A new cache.
2002-11-18 16:53:58 +03:00
device usage based on devices file The LVM devices file lists devices that lvm can use. The default file is /etc/lvm/devices/system.devices, and the lvmdevices(8) command is used to add or remove device entries. If the file does not exist, or if lvm.conf includes use_devicesfile=0, then lvm will not use a devices file. When the devices file is in use, the regex filter is not used, and the filter settings in lvm.conf or on the command line are ignored. LVM records devices in the devices file using hardware-specific IDs, such as the WWID, and attempts to use subsystem-specific IDs for virtual device types. These device IDs are also written in the VG metadata. When no hardware or virtual ID is available, lvm falls back using the unstable device name as the device ID. When devnames are used, lvm performs extra scanning to find devices if their devname changes, e.g. after reboot. When proper device IDs are used, an lvm command will not look at devices outside the devices file, but when devnames are used as a fallback, lvm will scan devices outside the devices file to locate PVs on renamed devices. A config setting search_for_devnames can be used to control the scanning for renamed devname entries. Related to the devices file, the new command option --devices <devnames> allows a list of devices to be specified for the command to use, overriding the devices file. The listed devices act as a sort of devices file in terms of limiting which devices lvm will see and use. Devices that are not listed will appear to be missing to the lvm command. Multiple devices files can be kept in /etc/lvm/devices, which allows lvm to be used with different sets of devices, e.g. system devices do not need to be exposed to a specific application, and the application can use lvm on its own set of devices that are not exposed to the system. The option --devicesfile <filename> is used to select the devices file to use with the command. Without the option set, the default system devices file is used. Setting --devicesfile "" causes lvm to not use a devices file. An existing, empty devices file means lvm will see no devices. The new command vgimportdevices adds PVs from a VG to the devices file and updates the VG metadata to include the device IDs. vgimportdevices -a will import all VGs into the system devices file. LVM commands run by dmeventd not use a devices file by default, and will look at all devices on the system. A devices file can be created for dmeventd (/etc/lvm/devices/dmeventd.devices) If this file exists, lvm commands run by dmeventd will use it. Internal implementaion: - device_ids_read - read the devices file . add struct dev_use (du) to cmd->use_devices for each devices file entry - dev_cache_scan - get /dev entries . add struct device (dev) to dev_cache for each device on the system - device_ids_match - match devices file entries to /dev entries . match each du on cmd->use_devices to a dev in dev_cache, using device ID . on match, set du->dev, dev->id, dev->flags MATCHED_USE_ID - label_scan - read lvm headers and metadata from devices . filters are applied, those that do not need data from the device . filter-deviceid skips devs without MATCHED_USE_ID, i.e. skips /dev entries that are not listed in the devices file . read lvm label from dev . filters are applied, those that use data from the device . read lvm metadata from dev . add info/vginfo structs for PVs/VGs (info is "lvmcache") - device_ids_find_renamed_devs - handle devices with unstable devname ID where devname changed . this step only needed when devs do not have proper device IDs, and their dev names change, e.g. after reboot sdb becomes sdc. . detect incorrect match because PVID in the devices file entry does not match the PVID found when the device was read above . undo incorrect match between du and dev above . search system devices for new location of PVID . update devices file with new devnames for PVIDs on renamed devices . label_scan the renamed devs - continue with command processing
2020-06-23 21:25:41 +03:00
dm_list_init(&renamed_devs);
md component detection changes Move extra md component detection into the label scan phase. It had been in set_pv_devices which was deep within the vg_read phase, which wasn't a good place (better to detect that earlier.) Now that pv metadata info is available in the scan phase, the pv details (size and device_hint) can be used for extra md checking. Use the device_hint from the pv metadata to trigger a full md component check if the device_hint begins with /dev/md. Stop triggering full md component checks based on missing udev info for a dev. Changes to tests to reflect that the code is now detecting md components in some test case that it wasn't before.
2021-02-06 01:16:03 +03:00
log_debug_cache("lvmcache label scan begin");
scan: drop bcache between lvm shell commands A running lvm shell keeps all lvm devices open unless the bcache is dropped.
2018-04-06 21:05:17 +03:00
lvmcache: fix duplicate handling with multiple scans Some commands scan labels to populate lvmcache multiple times, i.e. lvmcache_init, scan labels to fill lvmcache, lvmcache_destroy, then later repeat Each time labels are scanned, duplicates are detected, and preferred devices are chosen. Each time this is done within a single command, we want to choose the same preferred devices. So, check for existing preferences when choosing preferred devices. This also fixes a problem with the list of unused duplicate devs when run in an lvm shell. The devs had been allocated from cmd memory, resulting in invalid list entries between commands.
2016-06-06 23:20:55 +03:00
/*
improve duplicate pv handling for md components Eliminate md components at the start so they don't interfere with actual duplicates, and don't need to be removed later. This also allows for choosing no copy of a PVID if they all happen to be md components.
2019-08-01 23:04:10 +03:00
* Duplicates found during this label scan are added to _initial_duplicates.
lvmcache: fix duplicate handling with multiple scans Some commands scan labels to populate lvmcache multiple times, i.e. lvmcache_init, scan labels to fill lvmcache, lvmcache_destroy, then later repeat Each time labels are scanned, duplicates are detected, and preferred devices are chosen. Each time this is done within a single command, we want to choose the same preferred devices. So, check for existing preferences when choosing preferred devices. This also fixes a problem with the list of unused duplicate devs when run in an lvm shell. The devs had been allocated from cmd memory, resulting in invalid list entries between commands.
2016-06-06 23:20:55 +03:00
*/
lvmcache: renaming functions and variables related to duplicates, no functional changes.
2019-08-01 21:50:04 +03:00
_destroy_device_list(&_initial_duplicates);
improve duplicate pv handling for md components Eliminate md components at the start so they don't interfere with actual duplicates, and don't need to be removed later. This also allows for choosing no copy of a PVID if they all happen to be md components.
2019-08-01 23:04:10 +03:00
_destroy_device_list(&_unused_duplicates);
lvmcache: fix duplicate handling with multiple scans Some commands scan labels to populate lvmcache multiple times, i.e. lvmcache_init, scan labels to fill lvmcache, lvmcache_destroy, then later repeat Each time labels are scanned, duplicates are detected, and preferred devices are chosen. Each time this is done within a single command, we want to choose the same preferred devices. So, check for existing preferences when choosing preferred devices. This also fixes a problem with the list of unused duplicate devs when run in an lvm shell. The devs had been allocated from cmd memory, resulting in invalid list entries between commands.
2016-06-06 23:20:55 +03:00
scan: use new label_scan for lvmcache_label_scan To do label scanning, lvm code calls lvmcache_label_scan(). Change lvmcache_label_scan() to use the new label_scan() based on bcache. Also add lvmcache_label_rescan_vg() which calls the new label_scan_devs() which does label scanning on only the specified devices. This is for a subsequent commit and is not yet used.
2018-02-07 22:14:08 +03:00
/*
* Do the actual scanning. This populates lvmcache
* with infos/vginfos based on reading headers from
* each device, and a vg summary from each mda.
*/
label_scan(cmd);
process_each_pv: do full scan earlier to find new devices Before commit c1f246fedfc349c25749da501e68a7f70bd122b0, _get_all_devices() did a full device scan before get_vgnameids() was called. The full scan in _get_all_devices() is from calling dev_iter_create(f, 1). The '1' arg forces a full scan. By doing a full scan in _get_all_devices(), new devices were added to dev-cache before get_vgnameids() began scanning labels. So, labels would be read from new devices. (e.g. by the first 'pvs' command after the new device appeared.) After that commit, _get_all_devices() was called after get_vgnameids() was finished scanning labels. So, new devices would be missed while scanning labels. When _get_all_devices() saw the new devices (after labels were scanned), those devices were added to the .cache file. This meant that the second 'pvs' command would see the devices because they would be in .cache. Now, the full device scan is factored out of _get_all_devices() and called by itself at the start of the command so that new devices will be known before get_vgnameids() scans labels.
2015-12-11 23:02:36 +03:00
device usage based on devices file The LVM devices file lists devices that lvm can use. The default file is /etc/lvm/devices/system.devices, and the lvmdevices(8) command is used to add or remove device entries. If the file does not exist, or if lvm.conf includes use_devicesfile=0, then lvm will not use a devices file. When the devices file is in use, the regex filter is not used, and the filter settings in lvm.conf or on the command line are ignored. LVM records devices in the devices file using hardware-specific IDs, such as the WWID, and attempts to use subsystem-specific IDs for virtual device types. These device IDs are also written in the VG metadata. When no hardware or virtual ID is available, lvm falls back using the unstable device name as the device ID. When devnames are used, lvm performs extra scanning to find devices if their devname changes, e.g. after reboot. When proper device IDs are used, an lvm command will not look at devices outside the devices file, but when devnames are used as a fallback, lvm will scan devices outside the devices file to locate PVs on renamed devices. A config setting search_for_devnames can be used to control the scanning for renamed devname entries. Related to the devices file, the new command option --devices <devnames> allows a list of devices to be specified for the command to use, overriding the devices file. The listed devices act as a sort of devices file in terms of limiting which devices lvm will see and use. Devices that are not listed will appear to be missing to the lvm command. Multiple devices files can be kept in /etc/lvm/devices, which allows lvm to be used with different sets of devices, e.g. system devices do not need to be exposed to a specific application, and the application can use lvm on its own set of devices that are not exposed to the system. The option --devicesfile <filename> is used to select the devices file to use with the command. Without the option set, the default system devices file is used. Setting --devicesfile "" causes lvm to not use a devices file. An existing, empty devices file means lvm will see no devices. The new command vgimportdevices adds PVs from a VG to the devices file and updates the VG metadata to include the device IDs. vgimportdevices -a will import all VGs into the system devices file. LVM commands run by dmeventd not use a devices file by default, and will look at all devices on the system. A devices file can be created for dmeventd (/etc/lvm/devices/dmeventd.devices) If this file exists, lvm commands run by dmeventd will use it. Internal implementaion: - device_ids_read - read the devices file . add struct dev_use (du) to cmd->use_devices for each devices file entry - dev_cache_scan - get /dev entries . add struct device (dev) to dev_cache for each device on the system - device_ids_match - match devices file entries to /dev entries . match each du on cmd->use_devices to a dev in dev_cache, using device ID . on match, set du->dev, dev->id, dev->flags MATCHED_USE_ID - label_scan - read lvm headers and metadata from devices . filters are applied, those that do not need data from the device . filter-deviceid skips devs without MATCHED_USE_ID, i.e. skips /dev entries that are not listed in the devices file . read lvm label from dev . filters are applied, those that use data from the device . read lvm metadata from dev . add info/vginfo structs for PVs/VGs (info is "lvmcache") - device_ids_find_renamed_devs - handle devices with unstable devname ID where devname changed . this step only needed when devs do not have proper device IDs, and their dev names change, e.g. after reboot sdb becomes sdc. . detect incorrect match because PVID in the devices file entry does not match the PVID found when the device was read above . undo incorrect match between du and dev above . search system devices for new location of PVID . update devices file with new devnames for PVIDs on renamed devices . label_scan the renamed devs - continue with command processing
2020-06-23 21:25:41 +03:00
/*
* When devnames are used as device ids (which is dispreferred),
* changing/unstable devnames can lead to entries in the devices file
* not being matched to a dev even if the PV is present on the system.
* Or, a devices file entry may have been matched to the wrong device
* (with the previous name) that does not have the PVID specified in
* the entry. This function detects that problem, scans labels on all
* devs on the system to find the missing PVIDs, and corrects the
* devices file. We then need to run label scan on these correct
* devices.
*/
device_ids_find_renamed_devs(cmd, &renamed_devs, NULL, 0);
if (!dm_list_empty(&renamed_devs))
label_scan_devs(cmd, cmd->filter, &renamed_devs);
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
/*
lvmcache: renaming functions and variables related to duplicates, no functional changes.
2019-08-01 21:50:04 +03:00
* _choose_duplicates() returns:
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
*
* . del_cache_devs: a list of devs currently in lvmcache that should
* be removed from lvmcache because they will be replaced with
* alternative devs for the same PV.
*
* . add_cache_devs: a list of devs that are preferred over devs in
* lvmcache for the same PV. These devices should be rescanned to
* populate lvmcache from them.
*
* First remove lvmcache info for the devs to be dropped, then rescan
* the devs that are preferred to add them to lvmcache.
*
* Keep a complete list of all devs that are unused by moving the
lvmcache: renaming functions and variables related to duplicates, no functional changes.
2019-08-01 21:50:04 +03:00
* del_cache_devs onto _unused_duplicates.
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
*/
lvmcache: renaming functions and variables related to duplicates, no functional changes.
2019-08-01 21:50:04 +03:00
if (!dm_list_empty(&_initial_duplicates)) {
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
dm_list_init(&del_cache_devs);
dm_list_init(&add_cache_devs);
scan: drop bcache between lvm shell commands A running lvm shell keeps all lvm devices open unless the bcache is dropped.
2018-04-06 21:05:17 +03:00
log_debug_cache("Resolving duplicate devices");
lvmcache: renaming functions and variables related to duplicates, no functional changes.
2019-08-01 21:50:04 +03:00
_choose_duplicates(cmd, &del_cache_devs, &add_cache_devs);
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
dm_list_iterate_items(devl, &del_cache_devs) {
improve duplicate pv handling for md components Eliminate md components at the start so they don't interfere with actual duplicates, and don't need to be removed later. This also allows for choosing no copy of a PVID if they all happen to be md components.
2019-08-01 23:04:10 +03:00
log_debug_cache("Dropping unchosen duplicate %s", dev_name(devl->dev));
lvmcache: add optional dev arg to lvmcache_info_from_pvid A number of places are working on a specific dev when they call lvmcache_info_from_pvid() to look up an info struct based on a pvid. In those cases, pass the dev being used to lvmcache_info_from_pvid(). When a dev is specified, lvmcache_info_from_pvid() will verify that the cached info it's using matches the dev being processed before returning the info. Calling code will not mistakenly get info for the wrong dev when duplicate devs exist. This confusion was happening when scanning labels when duplicate devs existed. label_read for the first dev would add an info struct to lvmcache for that dev/pvid. label_read for the second dev would see the pvid in lvmcache from first dev, and mistakenly conclude that the label_read from the second dev can be skipped because it's already been done. By verifying that the dev for the cached pvid matches the dev being read, this mismatch is avoided and the label is actually read from the second duplicate.
2016-06-06 22:04:17 +03:00
if ((info = lvmcache_info_from_pvid(devl->dev->pvid, NULL, 0)))
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
lvmcache_del(info);
}
dm_list_iterate_items(devl, &add_cache_devs) {
improve duplicate pv handling for md components Eliminate md components at the start so they don't interfere with actual duplicates, and don't need to be removed later. This also allows for choosing no copy of a PVID if they all happen to be md components.
2019-08-01 23:04:10 +03:00
log_debug_cache("Adding chosen duplicate %s", dev_name(devl->dev));
lvmcache: rename label_read label_scan_dev for consistent naming with other similar functions
2020-10-15 20:56:36 +03:00
label_scan_dev(devl->dev);
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
}
lvmcache: renaming functions and variables related to duplicates, no functional changes.
2019-08-01 21:50:04 +03:00
dm_list_splice(&_unused_duplicates, &del_cache_devs);
scan: ignore duplicates that are md component devs md devices using an older superblock version have superblocks at the end of the md device. For commands that skip reading the end of devices during filtering, the md component devs will be scanned, and will appear as duplicate PVs to the original md device. Remove these md components from the list of unused duplicate devices, so they are treated as if they had been ignored during filtering. This avoids the restrictions that are placed on using PVs with duplicates.
2018-05-11 23:52:22 +03:00
improve duplicate pv handling for md components Eliminate md components at the start so they don't interfere with actual duplicates, and don't need to be removed later. This also allows for choosing no copy of a PVID if they all happen to be md components.
2019-08-01 23:04:10 +03:00
/* Warn about unused duplicates that the user might want to resolve. */
lvmcache: renaming functions and variables related to duplicates, no functional changes.
2019-08-01 21:50:04 +03:00
_warn_unused_duplicates(cmd);
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
}
md component detection changes Move extra md component detection into the label scan phase. It had been in set_pv_devices which was deep within the vg_read phase, which wasn't a good place (better to detect that earlier.) Now that pv metadata info is available in the scan phase, the pv details (size and device_hint) can be used for extra md checking. Use the device_hint from the pv metadata to trigger a full md component check if the device_hint begins with /dev/md. Stop triggering full md component checks based on missing udev info for a dev. Changes to tests to reflect that the code is now detecting md components in some test case that it wasn't before.
2021-02-06 01:16:03 +03:00
log_debug_cache("lvmcache label scan done");
return 1;
A new cache.
2002-11-18 16:53:58 +03:00
}
lvmcache: remove wrapper around lvmcache_get_vgnameids This was left over from when there was an lvmetad version of the function.
2019-06-11 22:09:13 +03:00
int lvmcache_get_vgnameids(struct cmd_context *cmd,
struct dm_list *vgnameids,
const char *only_this_vgname,
int include_internal)
toollib: avoid repeated lvmetad vg_lookup In process_each_{vg,lv,pv} when no vgname args are given, the first step is to get a list of all vgid/vgname on the system. This is exactly what lvmetad returns from a vg_list request. The current code is doing a vg_lookup on each VG after the vg_list and populating lvmcache with the info for each VG. These preliminary vg_lookup's are unnecessary, because they will be done again when the processing functions call vg_read. This patch eliminates the initial round of vg_lookup's, which can roughly cut in half the number of lvmetad requests and save a lot of extra work.
2015-05-06 00:24:50 +03:00
{
struct vgnameid_list *vgnl;
struct lvmcache_vginfo *vginfo;
lvmcache: remove wrapper around lvmcache_get_vgnameids This was left over from when there was an lvmetad version of the function.
2019-06-11 22:09:13 +03:00
if (only_this_vgname) {
if (!(vgnl = dm_pool_alloc(cmd->mem, sizeof(*vgnl)))) {
log_error("vgnameid_list allocation failed.");
return 0;
}
vgnl->vg_name = dm_pool_strdup(cmd->mem, only_this_vgname);
vgnl->vgid = NULL;
dm_list_add(vgnameids, &vgnl->list);
return 1;
}
toollib: avoid repeated lvmetad vg_lookup In process_each_{vg,lv,pv} when no vgname args are given, the first step is to get a list of all vgid/vgname on the system. This is exactly what lvmetad returns from a vg_list request. The current code is doing a vg_lookup on each VG after the vg_list and populating lvmcache with the info for each VG. These preliminary vg_lookup's are unnecessary, because they will be done again when the processing functions call vg_read. This patch eliminates the initial round of vg_lookup's, which can roughly cut in half the number of lvmetad requests and save a lot of extra work.
2015-05-06 00:24:50 +03:00
dm_list_iterate_items(vginfo, &_vginfos) {
if (!include_internal && is_orphan_vg(vginfo->vgname))
continue;
if (!(vgnl = dm_pool_alloc(cmd->mem, sizeof(*vgnl)))) {
log_error("vgnameid_list allocation failed.");
return 0;
}
vgnl->vgid = dm_pool_strdup(cmd->mem, vginfo->vgid);
vgnl->vg_name = dm_pool_strdup(cmd->mem, vginfo->vgname);
if (!vgnl->vgid || !vgnl->vg_name) {
log_error("vgnameid_list member allocation failed.");
return 0;
}
dm_list_add(vgnameids, &vgnl->list);
}
return 1;
}
scan: use new label_scan for lvmcache_label_scan To do label scanning, lvm code calls lvmcache_label_scan(). Change lvmcache_label_scan() to use the new label_scan() based on bcache. Also add lvmcache_label_rescan_vg() which calls the new label_scan_devs() which does label scanning on only the specified devices. This is for a subsequent commit and is not yet used.
2018-02-07 22:14:08 +03:00
static struct device *_device_from_pvid(const struct id *pvid, uint64_t *label_sector)
Defer writing PV labels to vg_write. Store label_sector only in struct physical_volume.
2011-06-01 23:29:31 +04:00
{
scan: use new label_scan for lvmcache_label_scan To do label scanning, lvm code calls lvmcache_label_scan(). Change lvmcache_label_scan() to use the new label_scan() based on bcache. Also add lvmcache_label_rescan_vg() which calls the new label_scan_devs() which does label scanning on only the specified devices. This is for a subsequent commit and is not yet used.
2018-02-07 22:14:08 +03:00
struct lvmcache_info *info;
A new cache.
2002-11-18 16:53:58 +03:00
scan: use new label_scan for lvmcache_label_scan To do label scanning, lvm code calls lvmcache_label_scan(). Change lvmcache_label_scan() to use the new label_scan() based on bcache. Also add lvmcache_label_rescan_vg() which calls the new label_scan_devs() which does label scanning on only the specified devices. This is for a subsequent commit and is not yet used.
2018-02-07 22:14:08 +03:00
if ((info = lvmcache_info_from_pvid((const char *) pvid, NULL, 0))) {
if (info->label && label_sector)
*label_sector = info->label->sector;
return info->dev;
}
A new cache.
2002-11-18 16:53:58 +03:00
scan: use new label_scan for lvmcache_label_scan To do label scanning, lvm code calls lvmcache_label_scan(). Change lvmcache_label_scan() to use the new label_scan() based on bcache. Also add lvmcache_label_rescan_vg() which calls the new label_scan_devs() which does label scanning on only the specified devices. This is for a subsequent commit and is not yet used.
2018-02-07 22:14:08 +03:00
return NULL;
}
Another sync point - numerous fixes & clean ups.
2003-07-05 02:34:56 +04:00
scan: use new label_scan for lvmcache_label_scan To do label scanning, lvm code calls lvmcache_label_scan(). Change lvmcache_label_scan() to use the new label_scan() based on bcache. Also add lvmcache_label_rescan_vg() which calls the new label_scan_devs() which does label scanning on only the specified devices. This is for a subsequent commit and is not yet used.
2018-02-07 22:14:08 +03:00
struct device *lvmcache_device_from_pvid(struct cmd_context *cmd, const struct id *pvid, uint64_t *label_sector)
{
struct device *dev;
A new cache.
2002-11-18 16:53:58 +03:00
Defer writing PV labels to vg_write. Store label_sector only in struct physical_volume.
2011-06-01 23:29:31 +04:00
dev = _device_from_pvid(pvid, label_sector);
if (dev)
return dev;
A new cache.
2002-11-18 16:53:58 +03:00
scan: use new label_scan for lvmcache_label_scan To do label scanning, lvm code calls lvmcache_label_scan(). Change lvmcache_label_scan() to use the new label_scan() based on bcache. Also add lvmcache_label_rescan_vg() which calls the new label_scan_devs() which does label scanning on only the specified devices. This is for a subsequent commit and is not yet used.
2018-02-07 22:14:08 +03:00
log_debug_devs("No device with uuid %s.", (const char *)pvid);
A new cache.
2002-11-18 16:53:58 +03:00
return NULL;
}
lvmcache: renaming functions and variables related to duplicates, no functional changes.
2019-08-01 21:50:04 +03:00
int lvmcache_pvid_in_unused_duplicates(const char *pvid)
vgcreate, pvcreate, vgextend: don't use a device with duplicates If duplicate orphan PVs exist, don't allow one of them to be used for vgcreate/pvcreate/vgextend.
2016-06-06 23:39:51 +03:00
{
struct device_list *devl;
lvmcache: renaming functions and variables related to duplicates, no functional changes.
2019-08-01 21:50:04 +03:00
dm_list_iterate_items(devl, &_unused_duplicates) {
vgcreate, pvcreate, vgextend: don't use a device with duplicates If duplicate orphan PVs exist, don't allow one of them to be used for vgcreate/pvcreate/vgextend.
2016-06-06 23:39:51 +03:00
if (!strncmp(devl->dev->pvid, pvid, ID_LEN))
return 1;
}
return 0;
}
Add pvid_from_devname() lvmcache function. Add supporting function for mappings from devname -> pvid -> vgname.
2010-05-19 15:52:07 +04:00
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
static void _free_vginfo(struct lvmcache_vginfo *vginfo)
Refactor some vginfo manipulation code.
2008-05-19 23:49:56 +04:00
{
device_mapper: remove dbg_malloc. I wrote dbg_malloc before we had valgrind. These days there's just no need.
2018-06-08 15:40:53 +03:00
free(vginfo->vgname);
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
free(vginfo->system_id);
device_mapper: remove dbg_malloc. I wrote dbg_malloc before we had valgrind. These days there's just no need.
2018-06-08 15:40:53 +03:00
free(vginfo->creation_host);
cleanup: free already checks for NULL
2021-02-27 16:14:25 +03:00
free(vginfo->lock_type);
device_mapper: remove dbg_malloc. I wrote dbg_malloc before we had valgrind. These days there's just no need.
2018-06-08 15:40:53 +03:00
free(vginfo);
Refactor some vginfo manipulation code.
2008-05-19 23:49:56 +04:00
}
Fix vgreduce to use vg_split_mdas to check sufficient mdas remain. Add (empty) orphan VGs to lvmcache during initialisation. Fix orphan VG name used for format_pool.
2008-04-08 16:49:21 +04:00
/*
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
* Remove vginfo from standard lists/hashes.
Fix vgreduce to use vg_split_mdas to check sufficient mdas remain. Add (empty) orphan VGs to lvmcache during initialisation. Fix orphan VG name used for format_pool.
2008-04-08 16:49:21 +04:00
*/
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
static void _drop_vginfo(struct lvmcache_info *info, struct lvmcache_vginfo *vginfo)
A new cache.
2002-11-18 16:53:58 +03:00
{
Refactor some vginfo manipulation code.
2008-05-19 23:49:56 +04:00
if (info)
_vginfo_detach_info(info);
If two or more VGs are found with the same name, use one that is not exported.
2006-04-12 21:54:11 +04:00
Refactor some vginfo manipulation code.
2008-05-19 23:49:56 +04:00
/* vginfo still referenced? */
if (!vginfo || is_orphan_vg(vginfo->vgname) ||
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
!dm_list_empty(&vginfo->infos))
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
return;
A new cache.
2002-11-18 16:53:58 +03:00
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
if (dm_hash_lookup(_vgname_hash, vginfo->vgname) == vginfo)
dm_hash_remove(_vgname_hash, vginfo->vgname);
If two or more VGs are found with the same name, use one that is not exported.
2006-04-12 21:54:11 +04:00
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
dm_hash_remove(_vgid_hash, vginfo->vgid);
dm_list_del(&vginfo->list); /* _vginfos list */
_free_vginfo(vginfo);
A new cache.
2002-11-18 16:53:58 +03:00
}
Another sync point - numerous fixes & clean ups.
2003-07-05 02:34:56 +04:00
void lvmcache_del(struct lvmcache_info *info)
A new cache.
2002-11-18 16:53:58 +03:00
{
if (info->dev->pvid[0] && _pvid_hash)
Use hash, bitset, malloc, pool from libdevmapper.
2005-10-17 03:03:59 +04:00
dm_hash_remove(_pvid_hash, info->dev->pvid);
A new cache.
2002-11-18 16:53:58 +03:00
Fix vgreduce to use vg_split_mdas to check sufficient mdas remain. Add (empty) orphan VGs to lvmcache during initialisation. Fix orphan VG name used for format_pool.
2008-04-08 16:49:21 +04:00
_drop_vginfo(info, info->vginfo);
A new cache.
2002-11-18 16:53:58 +03:00
info->label->labeller->ops->destroy_label(info->label->labeller,
pvremove: Update lvmcache => avoid spurious error messages.
2014-06-09 00:57:04 +04:00
info->label);
scan: add some missing frees some objects had been moved out of mem pools.
2018-05-14 21:38:16 +03:00
label_destroy(info->label);
device_mapper: remove dbg_malloc. I wrote dbg_malloc before we had valgrind. These days there's just no need.
2018-06-08 15:40:53 +03:00
free(info);
pvremove: Update lvmcache => avoid spurious error messages.
2014-06-09 00:57:04 +04:00
}
A new cache.
2002-11-18 16:53:58 +03:00
lvmcache: add shorter way to delete dev info Don't make the caller look up the info first.
2018-03-01 19:20:34 +03:00
void lvmcache_del_dev(struct device *dev)
{
struct lvmcache_info *info;
if ((info = lvmcache_info_from_pvid((const char *)dev->pvid, dev, 0)))
lvmcache_del(info);
}
Fix vgreduce to use vg_split_mdas to check sufficient mdas remain. Add (empty) orphan VGs to lvmcache during initialisation. Fix orphan VG name used for format_pool.
2008-04-08 16:49:21 +04:00
/*
* vginfo must be info->vginfo unless info is NULL (orphans)
*/
static int _lvmcache_update_vgid(struct lvmcache_info *info,
struct lvmcache_vginfo *vginfo,
const char *vgid)
A new cache.
2002-11-18 16:53:58 +03:00
{
Fix vgreduce to use vg_split_mdas to check sufficient mdas remain. Add (empty) orphan VGs to lvmcache during initialisation. Fix orphan VG name used for format_pool.
2008-04-08 16:49:21 +04:00
if (!vgid || !vginfo ||
!strncmp(vginfo->vgid, vgid, ID_LEN))
A new cache.
2002-11-18 16:53:58 +03:00
return 1;
Fix vgreduce to use vg_split_mdas to check sufficient mdas remain. Add (empty) orphan VGs to lvmcache during initialisation. Fix orphan VG name used for format_pool.
2008-04-08 16:49:21 +04:00
if (vginfo && *vginfo->vgid)
dm_hash_remove(_vgid_hash, vginfo->vgid);
Capture vgid in more places.
2006-04-11 02:09:00 +04:00
if (!vgid) {
Some fixmes 'len' calculation is unused ? Unreachable code could be removed or moved upward ?
2012-02-08 16:57:15 +04:00
/* FIXME: unreachable code path */
logging: classify log_debug messages Place most log_debug() messages into a class.
2013-01-08 02:30:29 +04:00
log_debug_cache("lvmcache: %s: clearing VGID", info ? dev_name(info->dev) : vginfo->vgname);
A new cache.
2002-11-18 16:53:58 +03:00
return 1;
Capture vgid in more places.
2006-04-11 02:09:00 +04:00
}
A new cache.
2002-11-18 16:53:58 +03:00
cleanup: more usage of dm_strncpy Use existing wrapper function arournd strncpy + buf[] = 0;
2018-03-02 18:25:37 +03:00
(void) dm_strncpy(vginfo->vgid, vgid, sizeof(vginfo->vgid));
Fix vgreduce to use vg_split_mdas to check sufficient mdas remain. Add (empty) orphan VGs to lvmcache during initialisation. Fix orphan VG name used for format_pool.
2008-04-08 16:49:21 +04:00
if (!dm_hash_insert(_vgid_hash, vginfo->vgid, vginfo)) {
Another sync point - numerous fixes & clean ups.
2003-07-05 02:34:56 +04:00
log_error("_lvmcache_update: vgid hash insertion failed: %s",
Fix vgreduce to use vg_split_mdas to check sufficient mdas remain. Add (empty) orphan VGs to lvmcache during initialisation. Fix orphan VG name used for format_pool.
2008-04-08 16:49:21 +04:00
vginfo->vgid);
A new cache.
2002-11-18 16:53:58 +03:00
return 0;
}
Fix vgreduce to use vg_split_mdas to check sufficient mdas remain. Add (empty) orphan VGs to lvmcache during initialisation. Fix orphan VG name used for format_pool.
2008-04-08 16:49:21 +04:00
if (!is_orphan_vg(vginfo->vgname))
debug: unify some tracing messages Introduce FMTVGID - although it might be possibly better to ensure vgid is always \0 ended string. Unify some lvmcache reported messages.
2016-04-12 14:06:16 +03:00
log_debug_cache("lvmcache %s: VG %s: set VGID to " FMTVGID ".",
logging: classify log_debug messages Place most log_debug() messages into a class.
2013-01-08 02:30:29 +04:00
(info) ? dev_name(info->dev) : "",
vginfo->vgname, vginfo->vgid);
Capture vgid in more places.
2006-04-11 02:09:00 +04:00
A new cache.
2002-11-18 16:53:58 +03:00
return 1;
}
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
static int _lvmcache_update_vgname(struct cmd_context *cmd,
struct lvmcache_info *info,
const char *vgname, const char *vgid,
const char *system_id,
const struct format_type *fmt)
If two or more VGs are found with the same name, use one that is not exported.
2006-04-12 21:54:11 +04:00
{
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
char vgid_str[64] __attribute__((aligned(8)));
char other_str[64] __attribute__((aligned(8)));
struct lvmcache_vginfo *vginfo;
struct lvmcache_vginfo *other;
int vginfo_is_allowed;
int other_is_allowed;
Fix vgexport/vgimport to set/reset PV exported flag so pv_attr is correct. Add vgid to struct physical_volume and pass with vg_name to some functions.
2006-04-13 01:23:04 +04:00
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
if (!vgname || (info && info->vginfo && !strcmp(info->vginfo->vgname, vgname)))
return 1;
Fix vgexport/vgimport to set/reset PV exported flag so pv_attr is correct. Add vgid to struct physical_volume and pass with vg_name to some functions.
2006-04-13 01:23:04 +04:00
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
if (!id_write_format((const struct id *)vgid, vgid_str, sizeof(vgid_str)))
stack;
add device hints to reduce scanning Save the list of PVs in /run/lvm/hints. These hints are used to reduce scanning in a number of commands to only the PVs on the system, or only the PVs in a requested VG (rather than all devices on the system.)
2018-12-07 23:35:22 +03:00
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
/*
* Add vginfo for orphan VG
*/
if (!info) {
if (!(vginfo = zalloc(sizeof(*vginfo)))) {
log_error("lvmcache adding vg list alloc failed %s", vgname);
return 0;
When choosing between identically-named VGs, also consider creation_host.
2006-04-13 21:32:24 +04:00
}
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
if (!(vginfo->vgname = strdup(vgname))) {
free(vginfo);
log_error("lvmcache adding vg name alloc failed %s", vgname);
return 0;
When choosing between identically-named VGs, also consider creation_host.
2006-04-13 21:32:24 +04:00
}
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
dm_list_init(&vginfo->infos);
dm_list_init(&vginfo->outdated_infos);
dm_list_init(&vginfo->pvsummaries);
vginfo->fmt = fmt;
If two or more VGs are found with the same name, use one that is not exported.
2006-04-12 21:54:11 +04:00
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
if (!dm_hash_insert(_vgname_hash, vgname, vginfo)) {
free(vginfo->vgname);
free(vginfo);
return_0;
}
If two or more VGs are found with the same name, use one that is not exported.
2006-04-12 21:54:11 +04:00
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
if (!_lvmcache_update_vgid(NULL, vginfo, vgid)) {
free(vginfo->vgname);
free(vginfo);
return_0;
}
A new cache.
2002-11-18 16:53:58 +03:00
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
/* Ensure orphans appear last on list_iterate */
dm_list_add(&_vginfos, &vginfo->list);
A new cache.
2002-11-18 16:53:58 +03:00
return 1;
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
}
A new cache.
2002-11-18 16:53:58 +03:00
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
_drop_vginfo(info, info->vginfo);
A new cache.
2002-11-18 16:53:58 +03:00
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
if (!(vginfo = lvmcache_vginfo_from_vgid(vgid))) {
lvmcache: simplify Recent changes allow some major simplification of the way lvmcache works and is used. lvmcache_label_scan is now called in a controlled fashion at the start of commands, and not via various unpredictable side effects. Remove various calls to it from other places. lvmcache_label_scan should not be called from anywhere during a command, because it produces an incorrect representation of PVs with no MDAs, and misclassifies them as orphans. This has been a long standing problem. The invalid flag and rescanning based on that is no longer used and removed. The 'force' variation is no longer needed and removed.
2018-04-09 21:40:49 +03:00
/*
* Create a vginfo struct for this VG and put the vginfo
* into the hash table.
*/
vgrename accepts vgid and exported VG.
2006-04-14 01:08:29 +04:00
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
log_debug_cache("lvmcache adding vginfo for %s %s", vgname, vgid_str);
device_mapper: remove dbg_malloc. I wrote dbg_malloc before we had valgrind. These days there's just no need.
2018-06-08 15:40:53 +03:00
if (!(vginfo = zalloc(sizeof(*vginfo)))) {
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
log_error("lvmcache adding vg list alloc failed %s", vgname);
A new cache.
2002-11-18 16:53:58 +03:00
return 0;
}
device_mapper: remove dbg_malloc. I wrote dbg_malloc before we had valgrind. These days there's just no need.
2018-06-08 15:40:53 +03:00
if (!(vginfo->vgname = strdup(vgname))) {
free(vginfo);
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
log_error("lvmcache adding vg name alloc failed %s", vgname);
A new cache.
2002-11-18 16:53:58 +03:00
return 0;
}
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
dm_list_init(&vginfo->infos);
ability to keep track of outdated pvs in lvmcache Outdated PVs hold metadata for VG from which they have been removed. Add the ability to keep track of these in lvmcache. This will be used for more advanced repair in a subsequent commit.
2019-02-05 21:55:51 +03:00
dm_list_init(&vginfo->outdated_infos);
scan: add PV summary info to lvmcache Expand the lvmcache info that is saved by the scan to include PV info from the metadata.
2019-09-26 19:27:38 +03:00
dm_list_init(&vginfo->pvsummaries);
Avoid spurious duplicate VG messages referring to VGs that are gone. (untested)
2008-05-29 02:27:47 +04:00
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
if ((other = dm_hash_lookup(_vgname_hash, vgname))) {
log_debug_cache("lvmcache adding vginfo found duplicate VG name %s", vgname);
Avoid spurious duplicate VG messages referring to VGs that are gone. (untested)
2008-05-29 02:27:47 +04:00
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
/*
* A different VG (different uuid) can exist with the
* same name. In this case, the two VGs will have
* separate vginfo structs, but one will be in the
* vgname_hash. If both vginfos are local/accessible,
* then _found_duplicate_vgnames is set which will
* disable any further use of the vgname_hash.
*/
if (!memcmp(other->vgid, vgid, ID_LEN)) {
/* shouldn't happen since we looked up by vgid above */
log_error(INTERNAL_ERROR "lvmcache_update_vgname %s %s %s %s",
vgname, vgid_str, other->vgname, other->vgid);
free(vginfo->vgname);
free(vginfo);
return 0;
}
vginfo_is_allowed = is_system_id_allowed(cmd, system_id);
other_is_allowed = is_system_id_allowed(cmd, other->system_id);
if (vginfo_is_allowed && other_is_allowed) {
if (!id_write_format((const struct id *)other->vgid, other_str, sizeof(other_str)))
stack;
vginfo->has_duplicate_local_vgname = 1;
other->has_duplicate_local_vgname = 1;
_found_duplicate_vgnames = 1;
log_warn("WARNING: VG name %s is used by VGs %s and %s.",
vgname, vgid_str, other_str);
log_warn("Fix duplicate VG names with vgrename uuid, a device filter, or system IDs.");
}
if (!vginfo_is_allowed && !other_is_allowed) {
vginfo->has_duplicate_foreign_vgname = 1;
other->has_duplicate_foreign_vgname = 1;
}
if (!other_is_allowed && vginfo_is_allowed) {
/* the accessible vginfo must be in vgnames_hash */
dm_hash_remove(_vgname_hash, vgname);
if (!dm_hash_insert(_vgname_hash, vgname, vginfo)) {
log_error("lvmcache adding vginfo to name hash failed %s", vgname);
return 0;
}
}
} else {
if (!dm_hash_insert(_vgname_hash, vgname, vginfo)) {
log_error("lvmcache adding vg to name hash failed %s", vgname);
free(vginfo->vgname);
free(vginfo);
return 0;
}
A new cache.
2002-11-18 16:53:58 +03:00
}
lvmcache: simplify Recent changes allow some major simplification of the way lvmcache works and is used. lvmcache_label_scan is now called in a controlled fashion at the start of commands, and not via various unpredictable side effects. Remove various calls to it from other places. lvmcache_label_scan should not be called from anywhere during a command, because it produces an incorrect representation of PVs with no MDAs, and misclassifies them as orphans. This has been a long standing problem. The invalid flag and rescanning based on that is no longer used and removed. The 'force' variation is no longer needed and removed.
2018-04-09 21:40:49 +03:00
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
dm_list_add_h(&_vginfos, &vginfo->list);
A new cache.
2002-11-18 16:53:58 +03:00
}
Fix vgreduce to use vg_split_mdas to check sufficient mdas remain. Add (empty) orphan VGs to lvmcache during initialisation. Fix orphan VG name used for format_pool.
2008-04-08 16:49:21 +04:00
vginfo->fmt = fmt;
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
info->vginfo = vginfo;
dm_list_add(&vginfo->infos, &info->list);
Fix vgreduce to use vg_split_mdas to check sufficient mdas remain. Add (empty) orphan VGs to lvmcache during initialisation. Fix orphan VG name used for format_pool.
2008-04-08 16:49:21 +04:00
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
log_debug_cache("lvmcache %s: now in VG %s %s", dev_name(info->dev), vgname, vgid_str);
Improve detection of external changes affecting internal cache.
2005-03-22 01:40:35 +03:00
A new cache.
2002-11-18 16:53:58 +03:00
return 1;
}
When choosing between identically-named VGs, also consider creation_host.
2006-04-13 21:32:24 +04:00
static int _lvmcache_update_vgstatus(struct lvmcache_info *info, uint32_t vgstatus,
lvmcache: include system_id in vginfo cache Save system_id just like creation_host and lock_type strings in vginfo cache.
2015-11-30 20:32:17 +03:00
const char *creation_host, const char *lock_type,
const char *system_id)
When scanning, also record whether or not VG is exported.
2006-04-11 21:42:15 +04:00
{
if (!info || !info->vginfo)
return 1;
if ((info->vginfo->status & EXPORTED_VG) != (vgstatus & EXPORTED_VG))
debug: unify some tracing messages Introduce FMTVGID - although it might be possibly better to ensure vgid is always \0 ended string. Unify some lvmcache reported messages.
2016-04-12 14:06:16 +03:00
log_debug_cache("lvmcache %s: VG %s %s exported.",
logging: classify log_debug messages Place most log_debug() messages into a class.
2013-01-08 02:30:29 +04:00
dev_name(info->dev), info->vginfo->vgname,
vgstatus & EXPORTED_VG ? "now" : "no longer");
When scanning, also record whether or not VG is exported.
2006-04-11 21:42:15 +04:00
info->vginfo->status = vgstatus;
When choosing between identically-named VGs, also consider creation_host.
2006-04-13 21:32:24 +04:00
if (!creation_host)
lvmcache: add lock_type to VG summary and info structs vgsummary information contains provisional VG information that is obtained without holding the VG lock. This info can be used to lock the VG, and then read it with vg_read(). After the VG is read properly, the vgsummary info should be verified. Add the VG lock_type to the vgsummary. It needs to be known before the VG can be locked and read.
2015-07-24 23:20:37 +03:00
goto set_lock_type;
When choosing between identically-named VGs, also consider creation_host.
2006-04-13 21:32:24 +04:00
if (info->vginfo->creation_host && !strcmp(creation_host,
info->vginfo->creation_host))
lvmcache: add lock_type to VG summary and info structs vgsummary information contains provisional VG information that is obtained without holding the VG lock. This info can be used to lock the VG, and then read it with vg_read(). After the VG is read properly, the vgsummary info should be verified. Add the VG lock_type to the vgsummary. It needs to be known before the VG can be locked and read.
2015-07-24 23:20:37 +03:00
goto set_lock_type;
When choosing between identically-named VGs, also consider creation_host.
2006-04-13 21:32:24 +04:00
device_mapper: remove dbg_malloc. I wrote dbg_malloc before we had valgrind. These days there's just no need.
2018-06-08 15:40:53 +03:00
free(info->vginfo->creation_host);
When choosing between identically-named VGs, also consider creation_host.
2006-04-13 21:32:24 +04:00
device_mapper: remove dbg_malloc. I wrote dbg_malloc before we had valgrind. These days there's just no need.
2018-06-08 15:40:53 +03:00
if (!(info->vginfo->creation_host = strdup(creation_host))) {
debug: unify some tracing messages Introduce FMTVGID - although it might be possibly better to ensure vgid is always \0 ended string. Unify some lvmcache reported messages.
2016-04-12 14:06:16 +03:00
log_error("cache creation host alloc failed for %s.",
When choosing between identically-named VGs, also consider creation_host.
2006-04-13 21:32:24 +04:00
creation_host);
return 0;
}
debug: unify some tracing messages Introduce FMTVGID - although it might be possibly better to ensure vgid is always \0 ended string. Unify some lvmcache reported messages.
2016-04-12 14:06:16 +03:00
log_debug_cache("lvmcache %s: VG %s: set creation host to %s.",
logging: classify log_debug messages Place most log_debug() messages into a class.
2013-01-08 02:30:29 +04:00
dev_name(info->dev), info->vginfo->vgname, creation_host);
When choosing between identically-named VGs, also consider creation_host.
2006-04-13 21:32:24 +04:00
lvmcache: add lock_type to VG summary and info structs vgsummary information contains provisional VG information that is obtained without holding the VG lock. This info can be used to lock the VG, and then read it with vg_read(). After the VG is read properly, the vgsummary info should be verified. Add the VG lock_type to the vgsummary. It needs to be known before the VG can be locked and read.
2015-07-24 23:20:37 +03:00
set_lock_type:
if (!lock_type)
lvmcache: include system_id in vginfo cache Save system_id just like creation_host and lock_type strings in vginfo cache.
2015-11-30 20:32:17 +03:00
goto set_system_id;
lvmcache: add lock_type to VG summary and info structs vgsummary information contains provisional VG information that is obtained without holding the VG lock. This info can be used to lock the VG, and then read it with vg_read(). After the VG is read properly, the vgsummary info should be verified. Add the VG lock_type to the vgsummary. It needs to be known before the VG can be locked and read.
2015-07-24 23:20:37 +03:00
if (info->vginfo->lock_type && !strcmp(lock_type, info->vginfo->lock_type))
lvmcache: include system_id in vginfo cache Save system_id just like creation_host and lock_type strings in vginfo cache.
2015-11-30 20:32:17 +03:00
goto set_system_id;
lvmcache: add lock_type to VG summary and info structs vgsummary information contains provisional VG information that is obtained without holding the VG lock. This info can be used to lock the VG, and then read it with vg_read(). After the VG is read properly, the vgsummary info should be verified. Add the VG lock_type to the vgsummary. It needs to be known before the VG can be locked and read.
2015-07-24 23:20:37 +03:00
device_mapper: remove dbg_malloc. I wrote dbg_malloc before we had valgrind. These days there's just no need.
2018-06-08 15:40:53 +03:00
free(info->vginfo->lock_type);
lvmcache: add lock_type to VG summary and info structs vgsummary information contains provisional VG information that is obtained without holding the VG lock. This info can be used to lock the VG, and then read it with vg_read(). After the VG is read properly, the vgsummary info should be verified. Add the VG lock_type to the vgsummary. It needs to be known before the VG can be locked and read.
2015-07-24 23:20:37 +03:00
device_mapper: remove dbg_malloc. I wrote dbg_malloc before we had valgrind. These days there's just no need.
2018-06-08 15:40:53 +03:00
if (!(info->vginfo->lock_type = strdup(lock_type))) {
lvmcache: include system_id in vginfo cache Save system_id just like creation_host and lock_type strings in vginfo cache.
2015-11-30 20:32:17 +03:00
log_error("cache lock_type alloc failed for %s", lock_type);
return 0;
}
debug: unify some tracing messages Introduce FMTVGID - although it might be possibly better to ensure vgid is always \0 ended string. Unify some lvmcache reported messages.
2016-04-12 14:06:16 +03:00
log_debug_cache("lvmcache %s: VG %s: set lock_type to %s.",
lvmcache: include system_id in vginfo cache Save system_id just like creation_host and lock_type strings in vginfo cache.
2015-11-30 20:32:17 +03:00
dev_name(info->dev), info->vginfo->vgname, lock_type);
set_system_id:
if (!system_id)
goto out;
if (info->vginfo->system_id && !strcmp(system_id, info->vginfo->system_id))
goto out;
device_mapper: remove dbg_malloc. I wrote dbg_malloc before we had valgrind. These days there's just no need.
2018-06-08 15:40:53 +03:00
free(info->vginfo->system_id);
lvmcache: include system_id in vginfo cache Save system_id just like creation_host and lock_type strings in vginfo cache.
2015-11-30 20:32:17 +03:00
device_mapper: remove dbg_malloc. I wrote dbg_malloc before we had valgrind. These days there's just no need.
2018-06-08 15:40:53 +03:00
if (!(info->vginfo->system_id = strdup(system_id))) {
lvmcache: include system_id in vginfo cache Save system_id just like creation_host and lock_type strings in vginfo cache.
2015-11-30 20:32:17 +03:00
log_error("cache system_id alloc failed for %s", system_id);
lvmcache: add lock_type to VG summary and info structs vgsummary information contains provisional VG information that is obtained without holding the VG lock. This info can be used to lock the VG, and then read it with vg_read(). After the VG is read properly, the vgsummary info should be verified. Add the VG lock_type to the vgsummary. It needs to be known before the VG can be locked and read.
2015-07-24 23:20:37 +03:00
return 0;
}
debug: unify some tracing messages Introduce FMTVGID - although it might be possibly better to ensure vgid is always \0 ended string. Unify some lvmcache reported messages.
2016-04-12 14:06:16 +03:00
log_debug_cache("lvmcache %s: VG %s: set system_id to %s.",
lvmcache: include system_id in vginfo cache Save system_id just like creation_host and lock_type strings in vginfo cache.
2015-11-30 20:32:17 +03:00
dev_name(info->dev), info->vginfo->vgname, system_id);
lvmcache: add lock_type to VG summary and info structs vgsummary information contains provisional VG information that is obtained without holding the VG lock. This info can be used to lock the VG, and then read it with vg_read(). After the VG is read properly, the vgsummary info should be verified. Add the VG lock_type to the vgsummary. It needs to be known before the VG can be locked and read.
2015-07-24 23:20:37 +03:00
out:
When scanning, also record whether or not VG is exported.
2006-04-11 21:42:15 +04:00
return 1;
}
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
int lvmcache_add_orphan_vginfo(struct cmd_context *cmd, const char *vgname, struct format_type *fmt)
Fix vgreduce to use vg_split_mdas to check sufficient mdas remain. Add (empty) orphan VGs to lvmcache during initialisation. Fix orphan VG name used for format_pool.
2008-04-08 16:49:21 +04:00
{
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
return _lvmcache_update_vgname(cmd, NULL, vgname, vgname, "", fmt);
Fix vgreduce to use vg_split_mdas to check sufficient mdas remain. Add (empty) orphan VGs to lvmcache during initialisation. Fix orphan VG name used for format_pool.
2008-04-08 16:49:21 +04:00
}
scan: add PV summary info to lvmcache Expand the lvmcache info that is saved by the scan to include PV info from the metadata.
2019-09-26 19:27:38 +03:00
static void _lvmcache_update_pvsummaries(struct lvmcache_vginfo *vginfo, struct lvmcache_vgsummary *vgsummary)
{
struct pv_list *pvl, *safe;
dm_list_init(&vginfo->pvsummaries);
dm_list_iterate_items_safe(pvl, safe, &vgsummary->pvsummaries) {
dm_list_del(&pvl->list);
dm_list_add(&vginfo->pvsummaries, &pvl->list);
}
}
scan: skip device rescan in vg_read For reporting commands (pvs,vgs,lvs,pvdisplay,vgdisplay,lvdisplay) we do not need to repeat the label scan of devices in vg_read if they all had matching metadata in the initial label scan. The data read by label scan can just be reused for the vg_read. This cuts the amount of device i/o in half, from two reads of each device to one. We have to be careful to avoid repairing the VG if we've skipped rescanning. (The VG repair code is very poor, and will be redone soon.)
2018-04-19 00:29:42 +03:00
/*
keep track of which mdas have old metadata in lvmcache This will be used for more advanced repair in a subsequent commit.
2019-02-05 22:09:56 +03:00
* Returning 0 causes the caller to remove the info struct for this
* device from lvmcache, which will make it look like a missing device.
scan: skip device rescan in vg_read For reporting commands (pvs,vgs,lvs,pvdisplay,vgdisplay,lvdisplay) we do not need to repeat the label scan of devices in vg_read if they all had matching metadata in the initial label scan. The data read by label scan can just be reused for the vg_read. This cuts the amount of device i/o in half, from two reads of each device to one. We have to be careful to avoid repairing the VG if we've skipped rescanning. (The VG repair code is very poor, and will be redone soon.)
2018-04-19 00:29:42 +03:00
*/
pass cmd struct through more functions no functional change
2020-01-28 19:33:15 +03:00
int lvmcache_update_vgname_and_id(struct cmd_context *cmd, struct lvmcache_info *info, struct lvmcache_vgsummary *vgsummary)
Use lvmcache_update_vgname_and_id throughout.
2006-04-11 20:00:26 +04:00
{
cache: Store metadata size and checksum. Refactor the recent metadata-reading optimisation patches. Remove the recently-added cache fields from struct labeller and struct format_instance. Instead, introduce struct lvmcache_vgsummary to wrap the VG information that lvmcache holds and add the metadata size and checksum to it. Allow this VG summary information to be looked up by metadata size + checksum. Adjust the debug log messages to make it clear when this shortcut has been successful. (This changes the optimisation slightly, and might be extendable further.) Add struct cached_vg_fmtdata to format-specific vg_read calls to preserve state alongside the VG across separate calls and indicate if the details supplied match, avoiding the need to read and process the VG metadata again.
2015-03-19 02:43:02 +03:00
const char *vgname = vgsummary->vgname;
const char *vgid = (char *)&vgsummary->vgid;
scan: skip device rescan in vg_read For reporting commands (pvs,vgs,lvs,pvdisplay,vgdisplay,lvdisplay) we do not need to repeat the label scan of devices in vg_read if they all had matching metadata in the initial label scan. The data read by label scan can just be reused for the vg_read. This cuts the amount of device i/o in half, from two reads of each device to one. We have to be careful to avoid repairing the VG if we've skipped rescanning. (The VG repair code is very poor, and will be redone soon.)
2018-04-19 00:29:42 +03:00
struct lvmcache_vginfo *vginfo;
cache: Store metadata size and checksum. Refactor the recent metadata-reading optimisation patches. Remove the recently-added cache fields from struct labeller and struct format_instance. Instead, introduce struct lvmcache_vgsummary to wrap the VG information that lvmcache holds and add the metadata size and checksum to it. Allow this VG summary information to be looked up by metadata size + checksum. Adjust the debug log messages to make it clear when this shortcut has been successful. (This changes the optimisation slightly, and might be extendable further.) Add struct cached_vg_fmtdata to format-specific vg_read calls to preserve state alongside the VG across separate calls and indicate if the details supplied match, avoiding the need to read and process the VG metadata again.
2015-03-19 02:43:02 +03:00
split orphan VG by format type
2008-02-06 18:47:28 +03:00
if (!vgname && !info->vginfo) {
#define an INTERNAL_ERROR macro and use it throughout LVM.
2009-12-16 22:22:11 +03:00
log_error(INTERNAL_ERROR "NULL vgname handed to cache");
split orphan VG by format type
2008-02-06 18:47:28 +03:00
/* FIXME Remove this */
vgname = info->fmt->orphan_vg_name;
vgid = vgname;
}
Fix vgreduce to use vg_split_mdas to check sufficient mdas remain. Add (empty) orphan VGs to lvmcache during initialisation. Fix orphan VG name used for format_pool.
2008-04-08 16:49:21 +04:00
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
/* FIXME: remove this, it shouldn't be needed */
Fix tracking of validity of PVs with no mdas in lvmcache.
2008-06-11 15:02:05 +04:00
/* If PV without mdas is already in a real VG, don't make it orphan */
Use mdas_empty_or_ignored() in place of checks for empty mda list. With the addition of ignored mdas, we replace all checks for an empty mda list with a new function to look for either an empty mda list or ignored mdas. Signed-off-by: Dave Wysochanski <dwysocha@redhat.com>
2010-06-29 00:34:58 +04:00
if (is_orphan_vg(vgname) && info->vginfo &&
mdas_empty_or_ignored(&info->mdas) &&
Critical section New strategy for memory locking to decrease the number of call to to un/lock memory when processing critical lvm functions. Introducing functions for critical section. Inside the critical section - memory is always locked. When leaving the critical section, the memory stays locked until memlock_unlock() is called - this happens with sync_local_dev_names() and sync_dev_names() function call. memlock_reset() is needed to reset locking numbers after fork (polldaemon). The patch itself is mostly rename: memlock_inc -> critical_section_inc memlock_dec -> critical_section_dec memlock -> critical_section Daemons (clmvd, dmevent) are using memlock_daemon_inc&dec (mlockall()) thus they will never release or relock memory they've already locked memory. Macros sync_local_dev_names() and sync_dev_names() are functions. It's better for debugging - and also we do not need to add memlock.h to locking.h header (for memlock_unlock() prototyp).
2011-02-18 17:16:11 +03:00
!is_orphan_vg(info->vginfo->vgname) && critical_section())
Fix tracking of validity of PVs with no mdas in lvmcache.
2008-06-11 15:02:05 +04:00
return 1;
scan: skip device rescan in vg_read For reporting commands (pvs,vgs,lvs,pvdisplay,vgdisplay,lvdisplay) we do not need to repeat the label scan of devices in vg_read if they all had matching metadata in the initial label scan. The data read by label scan can just be reused for the vg_read. This cuts the amount of device i/o in half, from two reads of each device to one. We have to be careful to avoid repairing the VG if we've skipped rescanning. (The VG repair code is very poor, and will be redone soon.)
2018-04-19 00:29:42 +03:00
/*
* Creates a new vginfo struct for this vgname/vgid if none exists,
* and attaches the info struct for the dev to the vginfo.
* Puts the vginfo into the vgname hash table.
*/
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
if (!_lvmcache_update_vgname(cmd, info, vgname, vgid, vgsummary->system_id, info->fmt)) {
keep track of which mdas have old metadata in lvmcache This will be used for more advanced repair in a subsequent commit.
2019-02-05 22:09:56 +03:00
/* shouldn't happen, internal error */
scan: skip device rescan in vg_read For reporting commands (pvs,vgs,lvs,pvdisplay,vgdisplay,lvdisplay) we do not need to repeat the label scan of devices in vg_read if they all had matching metadata in the initial label scan. The data read by label scan can just be reused for the vg_read. This cuts the amount of device i/o in half, from two reads of each device to one. We have to be careful to avoid repairing the VG if we've skipped rescanning. (The VG repair code is very poor, and will be redone soon.)
2018-04-19 00:29:42 +03:00
log_error("Failed to update VG %s info in lvmcache.", vgname);
return 0;
}
/*
* Puts the vginfo into the vgid hash table.
*/
if (!_lvmcache_update_vgid(info, info->vginfo, vgid)) {
keep track of which mdas have old metadata in lvmcache This will be used for more advanced repair in a subsequent commit.
2019-02-05 22:09:56 +03:00
/* shouldn't happen, internal error */
scan: skip device rescan in vg_read For reporting commands (pvs,vgs,lvs,pvdisplay,vgdisplay,lvdisplay) we do not need to repeat the label scan of devices in vg_read if they all had matching metadata in the initial label scan. The data read by label scan can just be reused for the vg_read. This cuts the amount of device i/o in half, from two reads of each device to one. We have to be careful to avoid repairing the VG if we've skipped rescanning. (The VG repair code is very poor, and will be redone soon.)
2018-04-19 00:29:42 +03:00
log_error("Failed to update VG %s info in lvmcache.", vgname);
return 0;
}
/*
* FIXME: identify which case this is and why this is needed, then
* change that so it doesn't use this function and we can remove
* this special case.
* (I think this distinguishes the scan path, where these things
* are set from the vg_read path where lvmcache_update_vg() is
* called which calls this function without seqno/mda_size/mda_checksum.)
*/
if (!vgsummary->seqno && !vgsummary->mda_size && !vgsummary->mda_checksum)
return 1;
keep track of which mdas have old metadata in lvmcache This will be used for more advanced repair in a subsequent commit.
2019-02-05 22:09:56 +03:00
/*
* Keep track of which devs/mdas have old versions of the metadata.
* The values we keep in vginfo are from the metadata with the largest
* seqno. One dev may have more recent metadata than another dev, and
* one mda may have more recent metadata than the other mda on the same
* device.
*
* When a device holds old metadata, the info struct for the device
* remains in lvmcache, so the device is not treated as missing.
* Also the mda struct containing the old metadata is kept on
* info->mdas. This means that vg_read will read metadata from
* the mda again (and probably see the same old metadata). It
* also means that vg_write will use the mda to write new metadata
* into the mda that currently has the old metadata.
*/
if (vgsummary->mda_num == 1)
info->mda1_seqno = vgsummary->seqno;
else if (vgsummary->mda_num == 2)
info->mda2_seqno = vgsummary->seqno;
if (!info->summary_seqno)
info->summary_seqno = vgsummary->seqno;
else {
if (info->summary_seqno == vgsummary->seqno) {
/* This mda has the same metadata as the prev mda on this dev. */
return 1;
} else if (info->summary_seqno > vgsummary->seqno) {
/* This mda has older metadata than the prev mda on this dev. */
info->summary_seqno_mismatch = true;
} else if (info->summary_seqno < vgsummary->seqno) {
/* This mda has newer metadata than the prev mda on this dev. */
info->summary_seqno_mismatch = true;
info->summary_seqno = vgsummary->seqno;
}
}
/* this shouldn't happen */
scan: skip device rescan in vg_read For reporting commands (pvs,vgs,lvs,pvdisplay,vgdisplay,lvdisplay) we do not need to repeat the label scan of devices in vg_read if they all had matching metadata in the initial label scan. The data read by label scan can just be reused for the vg_read. This cuts the amount of device i/o in half, from two reads of each device to one. We have to be careful to avoid repairing the VG if we've skipped rescanning. (The VG repair code is very poor, and will be redone soon.)
2018-04-19 00:29:42 +03:00
if (!(vginfo = info->vginfo))
return 1;
if (!vginfo->seqno) {
vginfo->seqno = vgsummary->seqno;
keep track of which mdas have old metadata in lvmcache This will be used for more advanced repair in a subsequent commit.
2019-02-05 22:09:56 +03:00
vginfo->mda_checksum = vgsummary->mda_checksum;
vginfo->mda_size = vgsummary->mda_size;
scan: skip device rescan in vg_read For reporting commands (pvs,vgs,lvs,pvdisplay,vgdisplay,lvdisplay) we do not need to repeat the label scan of devices in vg_read if they all had matching metadata in the initial label scan. The data read by label scan can just be reused for the vg_read. This cuts the amount of device i/o in half, from two reads of each device to one. We have to be careful to avoid repairing the VG if we've skipped rescanning. (The VG repair code is very poor, and will be redone soon.)
2018-04-19 00:29:42 +03:00
keep track of which mdas have old metadata in lvmcache This will be used for more advanced repair in a subsequent commit.
2019-02-05 22:09:56 +03:00
log_debug_cache("lvmcache %s mda%d VG %s set seqno %u checksum %x mda_size %zu",
dev_name(info->dev), vgsummary->mda_num, vgname,
vgsummary->seqno, vgsummary->mda_checksum, vgsummary->mda_size);
goto update_vginfo;
} else if (vgsummary->seqno < vginfo->seqno) {
vginfo->scan_summary_mismatch = true;
scan: skip device rescan in vg_read For reporting commands (pvs,vgs,lvs,pvdisplay,vgdisplay,lvdisplay) we do not need to repeat the label scan of devices in vg_read if they all had matching metadata in the initial label scan. The data read by label scan can just be reused for the vg_read. This cuts the amount of device i/o in half, from two reads of each device to one. We have to be careful to avoid repairing the VG if we've skipped rescanning. (The VG repair code is very poor, and will be redone soon.)
2018-04-19 00:29:42 +03:00
keep track of which mdas have old metadata in lvmcache This will be used for more advanced repair in a subsequent commit.
2019-02-05 22:09:56 +03:00
log_debug_cache("lvmcache %s mda%d VG %s older seqno %u checksum %x mda_size %zu",
dev_name(info->dev), vgsummary->mda_num, vgname,
vgsummary->seqno, vgsummary->mda_checksum, vgsummary->mda_size);
scan: skip device rescan in vg_read For reporting commands (pvs,vgs,lvs,pvdisplay,vgdisplay,lvdisplay) we do not need to repeat the label scan of devices in vg_read if they all had matching metadata in the initial label scan. The data read by label scan can just be reused for the vg_read. This cuts the amount of device i/o in half, from two reads of each device to one. We have to be careful to avoid repairing the VG if we've skipped rescanning. (The VG repair code is very poor, and will be redone soon.)
2018-04-19 00:29:42 +03:00
return 1;
keep track of which mdas have old metadata in lvmcache This will be used for more advanced repair in a subsequent commit.
2019-02-05 22:09:56 +03:00
} else if (vgsummary->seqno > vginfo->seqno) {
vginfo->scan_summary_mismatch = true;
/* Replace vginfo values with values from newer metadata. */
vginfo->seqno = vgsummary->seqno;
scan: skip device rescan in vg_read For reporting commands (pvs,vgs,lvs,pvdisplay,vgdisplay,lvdisplay) we do not need to repeat the label scan of devices in vg_read if they all had matching metadata in the initial label scan. The data read by label scan can just be reused for the vg_read. This cuts the amount of device i/o in half, from two reads of each device to one. We have to be careful to avoid repairing the VG if we've skipped rescanning. (The VG repair code is very poor, and will be redone soon.)
2018-04-19 00:29:42 +03:00
vginfo->mda_checksum = vgsummary->mda_checksum;
vginfo->mda_size = vgsummary->mda_size;
keep track of which mdas have old metadata in lvmcache This will be used for more advanced repair in a subsequent commit.
2019-02-05 22:09:56 +03:00
log_debug_cache("lvmcache %s mda%d VG %s newer seqno %u checksum %x mda_size %zu",
dev_name(info->dev), vgsummary->mda_num, vgname,
vgsummary->seqno, vgsummary->mda_checksum, vgsummary->mda_size);
goto update_vginfo;
} else {
/*
* Same seqno as previous metadata we saw for this VG.
* If the metadata somehow has a different checksum or size,
* even though it has the same seqno, something has gone wrong.
* FIXME: test this case: VG has two PVs, first goes missing,
* second updated to seqno 4, first comes back and second goes
* missing, first updated to seqno 4, second comes back, now
* both are present with same seqno but different checksums.
tests: add case for metadata checksum differences Cover the case where two copies of metadata have the same seqno but different checksums. Also elaborate on an existing fixme in the code for this case, since we should be doing something better for this case. This had been uncovering an issue with reopening fds in readwrite mode.
2020-09-28 21:21:44 +03:00
* FIXME: we should check if the majority of mda copies have one
* checksum and if so use that copy of metadata, but if there's
* not a majority, don't allow the VG to be modified/activated.
keep track of which mdas have old metadata in lvmcache This will be used for more advanced repair in a subsequent commit.
2019-02-05 22:09:56 +03:00
*/
if ((vginfo->mda_size != vgsummary->mda_size) || (vginfo->mda_checksum != vgsummary->mda_checksum)) {
log_warn("WARNING: scan of VG %s from %s mda%d found mda_checksum %x mda_size %zu vs %x %zu",
vgname, dev_name(info->dev), vgsummary->mda_num,
vgsummary->mda_checksum, vgsummary->mda_size,
vginfo->mda_checksum, vginfo->mda_size);
vginfo->scan_summary_mismatch = true;
vgck: let updatemetadata repair mismatched metadata Let vgck --updatemetadata repair cases where different mdas hold indepedently valid but unmatching copies of the metadata, i.e. different text metadata checksums or text metadata sizes.
2019-10-08 22:44:24 +03:00
vgsummary->mismatch = 1;
keep track of which mdas have old metadata in lvmcache This will be used for more advanced repair in a subsequent commit.
2019-02-05 22:09:56 +03:00
return 0;
}
/*
* The seqno and checksum matches what was previously seen;
* the summary values have already been saved in vginfo.
*/
scan: skip device rescan in vg_read For reporting commands (pvs,vgs,lvs,pvdisplay,vgdisplay,lvdisplay) we do not need to repeat the label scan of devices in vg_read if they all had matching metadata in the initial label scan. The data read by label scan can just be reused for the vg_read. This cuts the amount of device i/o in half, from two reads of each device to one. We have to be careful to avoid repairing the VG if we've skipped rescanning. (The VG repair code is very poor, and will be redone soon.)
2018-04-19 00:29:42 +03:00
return 1;
}
keep track of which mdas have old metadata in lvmcache This will be used for more advanced repair in a subsequent commit.
2019-02-05 22:09:56 +03:00
update_vginfo:
scan: skip device rescan in vg_read For reporting commands (pvs,vgs,lvs,pvdisplay,vgdisplay,lvdisplay) we do not need to repeat the label scan of devices in vg_read if they all had matching metadata in the initial label scan. The data read by label scan can just be reused for the vg_read. This cuts the amount of device i/o in half, from two reads of each device to one. We have to be careful to avoid repairing the VG if we've skipped rescanning. (The VG repair code is very poor, and will be redone soon.)
2018-04-19 00:29:42 +03:00
if (!_lvmcache_update_vgstatus(info, vgsummary->vgstatus, vgsummary->creation_host,
vgsummary->lock_type, vgsummary->system_id)) {
keep track of which mdas have old metadata in lvmcache This will be used for more advanced repair in a subsequent commit.
2019-02-05 22:09:56 +03:00
/*
* This shouldn't happen, it's an internal errror, and we can leave
* the info in place without saving the summary values in vginfo.
*/
scan: skip device rescan in vg_read For reporting commands (pvs,vgs,lvs,pvdisplay,vgdisplay,lvdisplay) we do not need to repeat the label scan of devices in vg_read if they all had matching metadata in the initial label scan. The data read by label scan can just be reused for the vg_read. This cuts the amount of device i/o in half, from two reads of each device to one. We have to be careful to avoid repairing the VG if we've skipped rescanning. (The VG repair code is very poor, and will be redone soon.)
2018-04-19 00:29:42 +03:00
log_error("Failed to update VG %s info in lvmcache.", vgname);
}
Use lvmcache_update_vgname_and_id throughout.
2006-04-11 20:00:26 +04:00
scan: add PV summary info to lvmcache Expand the lvmcache info that is saved by the scan to include PV info from the metadata.
2019-09-26 19:27:38 +03:00
_lvmcache_update_pvsummaries(vginfo, vgsummary);
Use lvmcache_update_vgname_and_id throughout.
2006-04-11 20:00:26 +04:00
return 1;
}
create separate lvmcache update functions for read and write The vg read and vg write cases need to update lvmcache differently, so create separate functions for them. The read case now handles checking for outdated mdas and moves them aside into a new list to be repaired in a subsequent commit.
2019-02-06 21:10:13 +03:00
/*
* FIXME: quit trying to mirror changes that a command is making into lvmcache.
*
* First, it's complicated and hard to ensure it's done correctly in every case
* (it would be much easier and safer to just toss out what's in lvmcache and
* reread the info to recreate it from scratch instead of trying to make sure
* every possible discrete state change is correct.)
*
* Second, it's unnecessary if commands just use the vg they are modifying
* rather than also trying to get info from lvmcache. The lvmcache state
* should be populated by label_scan, used to perform vg_read's, and then
* ignored (or dropped so it can't be used).
*
* lvmcache info is already used very little after a command begins its
* operation. The code that's supposed to keep the lvmcache in sync with
* changes being made to disk could be half wrong and we wouldn't know it.
* That creates a landmine for someone who might try to use a bit of it that
* isn't being updated correctly.
*/
int lvmcache_update_vg_from_write(struct volume_group *vg)
A new cache.
2002-11-18 16:53:58 +03:00
{
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
struct pv_list *pvl;
Another sync point - numerous fixes & clean ups.
2003-07-05 02:34:56 +04:00
struct lvmcache_info *info;
Use __attribute__ consistently throughout.
2010-07-09 19:34:40 +04:00
char pvid_s[ID_LEN + 1] __attribute__((aligned(8)));
cache: Store metadata size and checksum. Refactor the recent metadata-reading optimisation patches. Remove the recently-added cache fields from struct labeller and struct format_instance. Instead, introduce struct lvmcache_vgsummary to wrap the VG information that lvmcache holds and add the metadata size and checksum to it. Allow this VG summary information to be looked up by metadata size + checksum. Adjust the debug log messages to make it clear when this shortcut has been successful. (This changes the optimisation slightly, and might be extendable further.) Add struct cached_vg_fmtdata to format-specific vg_read calls to preserve state alongside the VG across separate calls and indicate if the details supplied match, avoiding the need to read and process the VG metadata again.
2015-03-19 02:43:02 +03:00
struct lvmcache_vgsummary vgsummary = {
.vgname = vg->name,
lvmcache: add lock_type to VG summary and info structs vgsummary information contains provisional VG information that is obtained without holding the VG lock. This info can be used to lock the VG, and then read it with vg_read(). After the VG is read properly, the vgsummary info should be verified. Add the VG lock_type to the vgsummary. It needs to be known before the VG can be locked and read.
2015-07-24 23:20:37 +03:00
.vgid = vg->id,
cleanup: matching declaration order Cosmetic
2020-08-29 22:37:39 +03:00
.vgstatus = vg->status,
lvmcache: include system_id in vginfo cache Save system_id just like creation_host and lock_type strings in vginfo cache.
2015-11-30 20:32:17 +03:00
.system_id = vg->system_id,
lvmcache: add lock_type to VG summary and info structs vgsummary information contains provisional VG information that is obtained without holding the VG lock. This info can be used to lock the VG, and then read it with vg_read(). After the VG is read properly, the vgsummary info should be verified. Add the VG lock_type to the vgsummary. It needs to be known before the VG can be locked and read.
2015-07-24 23:20:37 +03:00
.lock_type = vg->lock_type
cache: Store metadata size and checksum. Refactor the recent metadata-reading optimisation patches. Remove the recently-added cache fields from struct labeller and struct format_instance. Instead, introduce struct lvmcache_vgsummary to wrap the VG information that lvmcache holds and add the metadata size and checksum to it. Allow this VG summary information to be looked up by metadata size + checksum. Adjust the debug log messages to make it clear when this shortcut has been successful. (This changes the optimisation slightly, and might be extendable further.) Add struct cached_vg_fmtdata to format-specific vg_read calls to preserve state alongside the VG across separate calls and indicate if the details supplied match, avoiding the need to read and process the VG metadata again.
2015-03-19 02:43:02 +03:00
};
A new cache.
2002-11-18 16:53:58 +03:00
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
dm_list_iterate_items(pvl, &vg->pvs) {
cleanup: more usage of dm_strncpy Use existing wrapper function arournd strncpy + buf[] = 0;
2018-03-02 18:25:37 +03:00
(void) dm_strncpy(pvid_s, (char *) &pvl->pv->id, sizeof(pvid_s));
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
/* FIXME Could pvl->pv->dev->pvid ever be different? */
lvmcache: add optional dev arg to lvmcache_info_from_pvid A number of places are working on a specific dev when they call lvmcache_info_from_pvid() to look up an info struct based on a pvid. In those cases, pass the dev being used to lvmcache_info_from_pvid(). When a dev is specified, lvmcache_info_from_pvid() will verify that the cached info it's using matches the dev being processed before returning the info. Calling code will not mistakenly get info for the wrong dev when duplicate devs exist. This confusion was happening when scanning labels when duplicate devs existed. label_read for the first dev would add an info struct to lvmcache for that dev/pvid. label_read for the second dev would see the pvid in lvmcache from first dev, and mistakenly conclude that the label_read from the second dev can be skipped because it's already been done. By verifying that the dev for the cached pvid matches the dev being read, this mismatch is avoided and the label is actually read from the second duplicate.
2016-06-06 22:04:17 +03:00
if ((info = lvmcache_info_from_pvid(pvid_s, pvl->pv->dev, 0)) &&
pass cmd struct through more functions no functional change
2020-01-28 19:33:15 +03:00
!lvmcache_update_vgname_and_id(vg->cmd, info, &vgsummary))
Use lvmcache_update_vgname_and_id throughout.
2006-04-11 20:00:26 +04:00
return_0;
A new cache.
2002-11-18 16:53:58 +03:00
}
return 1;
}
create separate lvmcache update functions for read and write The vg read and vg write cases need to update lvmcache differently, so create separate functions for them. The read case now handles checking for outdated mdas and moves them aside into a new list to be repaired in a subsequent commit.
2019-02-06 21:10:13 +03:00
/*
* The lvmcache representation of a VG after label_scan can be incorrect
* because the label_scan does not use the full VG metadata to construct
* vginfo/info. PVs that don't hold VG metadata weren't attached to the vginfo
* during label scan, and PVs with outdated metadata (claiming to be in the VG,
* but not listed in the latest metadata) were attached to the vginfo, but
* shouldn't be. After vg_read() gets the full metdata in the form of a 'vg',
* this function is called to fix up the lvmcache representation of the VG
* using the 'vg'.
*/
int lvmcache_update_vg_from_read(struct volume_group *vg, unsigned precommitted)
{
struct pv_list *pvl;
struct lvmcache_vginfo *vginfo;
struct lvmcache_info *info, *info2;
struct metadata_area *mda;
char pvid_s[ID_LEN + 1] __attribute__((aligned(8)));
struct lvmcache_vgsummary vgsummary = {
.vgname = vg->name,
.vgid = vg->id,
cleanup: matching declaration order Cosmetic
2020-08-29 22:37:39 +03:00
.vgstatus = vg->status,
create separate lvmcache update functions for read and write The vg read and vg write cases need to update lvmcache differently, so create separate functions for them. The read case now handles checking for outdated mdas and moves them aside into a new list to be repaired in a subsequent commit.
2019-02-06 21:10:13 +03:00
.system_id = vg->system_id,
.lock_type = vg->lock_type
};
if (!(vginfo = lvmcache_vginfo_from_vgname(vg->name, (const char *)&vg->id))) {
log_error(INTERNAL_ERROR "lvmcache_update_vg %s no vginfo", vg->name);
return 0;
}
/*
* The label scan doesn't know when a PV with old metadata has been
* removed from the VG. Now with the vg we can tell, so remove the
* info for a PV that has been removed from the VG with
* vgreduce --removemissing.
*/
dm_list_iterate_items_safe(info, info2, &vginfo->infos) {
int found = 0;
dm_list_iterate_items(pvl, &vg->pvs) {
if (pvl->pv->dev != info->dev)
continue;
found = 1;
break;
}
if (found)
continue;
log_warn("WARNING: outdated PV %s seqno %u has been removed in current VG %s seqno %u.",
dev_name(info->dev), info->summary_seqno, vg->name, vginfo->seqno);
improve info about vgck updatemetadata Add man page info about this option, and add log messages pointing to this option.
2020-06-03 20:38:27 +03:00
if (!_outdated_warning++)
log_warn("See vgck --updatemetadata to clear outdated metadata.");
create separate lvmcache update functions for read and write The vg read and vg write cases need to update lvmcache differently, so create separate functions for them. The read case now handles checking for outdated mdas and moves them aside into a new list to be repaired in a subsequent commit.
2019-02-06 21:10:13 +03:00
_drop_vginfo(info, vginfo); /* remove from vginfo->infos */
dm_list_add(&vginfo->outdated_infos, &info->list);
}
dm_list_iterate_items(pvl, &vg->pvs) {
(void) dm_strncpy(pvid_s, (char *) &pvl->pv->id, sizeof(pvid_s));
if (!(info = lvmcache_info_from_pvid(pvid_s, pvl->pv->dev, 0))) {
log_debug_cache("lvmcache_update_vg %s no info for %s %s",
vg->name,
(char *) &pvl->pv->id,
pvl->pv->dev ? dev_name(pvl->pv->dev) : "missing");
continue;
}
log_debug_cache("lvmcache_update_vg %s for info %s",
vg->name, dev_name(info->dev));
/*
* FIXME: use a different function that just attaches info's that
* had no metadata onto the correct vginfo.
*
* info's for PVs without metadata were not connected to the
* vginfo by label_scan, so do it here.
*/
pass cmd struct through more functions no functional change
2020-01-28 19:33:15 +03:00
if (!lvmcache_update_vgname_and_id(vg->cmd, info, &vgsummary)) {
create separate lvmcache update functions for read and write The vg read and vg write cases need to update lvmcache differently, so create separate functions for them. The read case now handles checking for outdated mdas and moves them aside into a new list to be repaired in a subsequent commit.
2019-02-06 21:10:13 +03:00
log_debug_cache("lvmcache_update_vg %s failed to update info for %s",
vg->name, dev_name(info->dev));
}
/*
* Ignored mdas were not copied from info->mdas to
* fid->metadata_areas... when create_text_instance (at the
* start of vg_read) called lvmcache_fid_add_mdas_vg because at
* that point the info's were not connected to the vginfo
* (since label_scan didn't know this without metadata.)
*/
dm_list_iterate_items(mda, &info->mdas) {
if (!mda_is_ignored(mda))
continue;
log_debug("lvmcache_update_vg %s copy ignored mdas for %s", vg->name, dev_name(info->dev));
if (!lvmcache_fid_add_mdas_pv(info, vg->fid)) {
log_debug_cache("lvmcache_update_vg %s failed to update mdas for %s",
vg->name, dev_name(info->dev));
}
break;
}
}
return 1;
}
devices: improve handling of duplicate PVs Example: /dev/loop0 and /dev/loop1 are duplicates, created by copying one backing file to the other. 'identity /dev/loopX' creates an identity mapping for loopX named idmloopX, which adds a duplicate for the named device. The duplicate selection code for lvmetad is incomplete, and lvmetad is disabled for this example. [~]# losetup -f loopfile0 [~]# pvs PV VG Fmt Attr PSize PFree /dev/loop0 foo lvm2 a-- 308.00m 296.00m [~]# losetup -f loopfile1 [~]# pvs Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/loop1 not /dev/loop0 Using duplicate PV /dev/loop1 which is more recent, replacing /dev/loop0 PV VG Fmt Attr PSize PFree /dev/loop1 foo lvm2 a-- 308.00m 308.00m [~]# ./identity /dev/loop0 [~]# pvs Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/loop1 not /dev/loop0 Using duplicate PV /dev/loop1 without holders, replacing /dev/loop0 Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/mapper/idmloop0 not /dev/loop1 Using duplicate PV /dev/mapper/idmloop0 from subsystem DM, replacing /dev/loop1 PV VG Fmt Attr PSize PFree /dev/mapper/idmloop0 foo lvm2 a-- 308.00m 296.00m [~]# ./identity /dev/loop1 [~]# pvs WARNING: duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV is being used from both devices /dev/loop0 and /dev/loop1 Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/loop1 not /dev/loop0 Using duplicate PV /dev/loop1 which is more recent, replacing /dev/loop0 Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/mapper/idmloop0 not /dev/loop1 Using duplicate PV /dev/mapper/idmloop0 from subsystem DM, replacing /dev/loop1 Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/mapper/idmloop1 not /dev/mapper/idmloop0 Using duplicate PV /dev/mapper/idmloop1 which is more recent, replacing /dev/mapper/idmloop0 PV VG Fmt Attr PSize PFree /dev/mapper/idmloop1 foo lvm2 a-- 308.00m 308.00m
2015-04-24 22:58:58 +03:00
/*
* We can see multiple different devices with the
* same pvid, i.e. duplicates.
*
* There may be different reasons for seeing two
* devices with the same pvid:
* - multipath showing two paths to the same thing
* - one device copied to another, e.g. with dd,
* also referred to as cloned devices.
* - a "subsystem" taking a device and creating
* another device of its own that represents the
* underlying device it is using, e.g. using dm
* to create an identity mapping of a PV.
*
* Given duplicate devices, we have to choose one
* of them to be the "preferred" dev, i.e. the one
* that will be referenced in lvmcache, by pv->dev.
* We can keep the existing dev, that's currently
* used in lvmcache, or we can replace the existing
* dev with the new duplicate.
*
* Regardless of which device is preferred, we need
* to print messages explaining which devices were
* found so that a user can sort out for themselves
* what has happened if the preferred device is not
* the one they are interested in.
*
* If a user wants to use the non-preferred device,
* they will need to filter out the device that
* lvm is preferring.
*
* The dev_subsystem calls check if the major number
* of the dev is part of a subsystem like DM/MD/DRBD.
* A dev that's part of a subsystem is preferred over a
* duplicate of that dev that is not part of a
* subsystem.
*
* FIXME: there may be other reasons to prefer one
* device over another:
*
* . are there other use/open counts we could check
* beyond the holders?
*
* . check if either is bad/usable and prefer
* the good one?
*
* . prefer the one with smaller minor number?
* Might avoid disturbing things due to a new
* transient duplicate?
*/
change args for text label read function Have the caller pass the label_sector to the read function so the read function can set the sector field in the label struct, instead of having the read function return a pointer to the label for the caller to set the sector field. Also have the read function return a flag indicating to the caller that the scanned device was identified as a duplicate pv.
2019-02-05 22:40:34 +03:00
static struct lvmcache_info * _create_info(struct labeller *labeller, struct device *dev, uint64_t label_sector)
A new cache.
2002-11-18 16:53:58 +03:00
{
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
struct lvmcache_info *info;
A new cache.
2002-11-18 16:53:58 +03:00
struct label *label;
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
if (!(label = label_create(labeller)))
return_NULL;
device_mapper: remove dbg_malloc. I wrote dbg_malloc before we had valgrind. These days there's just no need.
2018-06-08 15:40:53 +03:00
if (!(info = zalloc(sizeof(*info)))) {
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
log_error("lvmcache_info allocation failed");
label_destroy(label);
A new cache.
2002-11-18 16:53:58 +03:00
return NULL;
}
change args for text label read function Have the caller pass the label_sector to the read function so the read function can set the sector field in the label struct, instead of having the read function return a pointer to the label for the caller to set the sector field. Also have the read function return a flag indicating to the caller that the scanned device was identified as a duplicate pv.
2019-02-05 22:40:34 +03:00
label->dev = dev;
label->sector = label_sector;
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
info->dev = dev;
info->fmt = labeller->fmt;
label->info = info;
info->label = label;
dm_list_init(&info->list);
lvmcache_del_mdas(info);
lvmcache_del_das(info);
lvmcache_del_bas(info);
return info;
}
pass cmd struct through more functions no functional change
2020-01-28 19:33:15 +03:00
struct lvmcache_info *lvmcache_add(struct cmd_context *cmd, struct labeller *labeller,
change args for text label read function Have the caller pass the label_sector to the read function so the read function can set the sector field in the label struct, instead of having the read function return a pointer to the label for the caller to set the sector field. Also have the read function return a flag indicating to the caller that the scanned device was identified as a duplicate pv.
2019-02-05 22:40:34 +03:00
const char *pvid, struct device *dev, uint64_t label_sector,
const char *vgname, const char *vgid, uint32_t vgstatus,
int *is_duplicate)
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
{
char pvid_s[ID_LEN + 1] __attribute__((aligned(8)));
char uuid[64] __attribute__((aligned(8)));
struct lvmcache_vgsummary vgsummary = { 0 };
struct lvmcache_info *info;
struct lvmcache_info *info_lookup;
struct device_list *devl;
int created = 0;
cleanup: more usage of dm_strncpy Use existing wrapper function arournd strncpy + buf[] = 0;
2018-03-02 18:25:37 +03:00
(void) dm_strncpy(pvid_s, pvid, sizeof(pvid_s));
coverity: missing check for id_write_format return value
2016-05-31 10:56:10 +03:00
if (!id_write_format((const struct id *)&pvid_s, uuid, sizeof(uuid)))
stack;
A new cache.
2002-11-18 16:53:58 +03:00
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
/*
* Find existing info struct in _pvid_hash or create a new one.
lvmcache: add optional dev arg to lvmcache_info_from_pvid A number of places are working on a specific dev when they call lvmcache_info_from_pvid() to look up an info struct based on a pvid. In those cases, pass the dev being used to lvmcache_info_from_pvid(). When a dev is specified, lvmcache_info_from_pvid() will verify that the cached info it's using matches the dev being processed before returning the info. Calling code will not mistakenly get info for the wrong dev when duplicate devs exist. This confusion was happening when scanning labels when duplicate devs existed. label_read for the first dev would add an info struct to lvmcache for that dev/pvid. label_read for the second dev would see the pvid in lvmcache from first dev, and mistakenly conclude that the label_read from the second dev can be skipped because it's already been done. By verifying that the dev for the cached pvid matches the dev being read, this mismatch is avoided and the label is actually read from the second duplicate.
2016-06-06 22:04:17 +03:00
*
* Don't pass the known "dev" as an arg here. The mismatching
* devs for the duplicate case is checked below.
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
*/
A new cache.
2002-11-18 16:53:58 +03:00
lvmcache: add optional dev arg to lvmcache_info_from_pvid A number of places are working on a specific dev when they call lvmcache_info_from_pvid() to look up an info struct based on a pvid. In those cases, pass the dev being used to lvmcache_info_from_pvid(). When a dev is specified, lvmcache_info_from_pvid() will verify that the cached info it's using matches the dev being processed before returning the info. Calling code will not mistakenly get info for the wrong dev when duplicate devs exist. This confusion was happening when scanning labels when duplicate devs existed. label_read for the first dev would add an info struct to lvmcache for that dev/pvid. label_read for the second dev would see the pvid in lvmcache from first dev, and mistakenly conclude that the label_read from the second dev can be skipped because it's already been done. By verifying that the dev for the cached pvid matches the dev being read, this mismatch is avoided and the label is actually read from the second duplicate.
2016-06-06 22:04:17 +03:00
info = lvmcache_info_from_pvid(pvid_s, NULL, 0);
The lvmetad client-side integration. Only active when use_lvmetad = 1 is set in lvm.conf *and* lvmetad is running.
2012-02-23 17:11:07 +04:00
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
if (!info)
lvmcache: add optional dev arg to lvmcache_info_from_pvid A number of places are working on a specific dev when they call lvmcache_info_from_pvid() to look up an info struct based on a pvid. In those cases, pass the dev being used to lvmcache_info_from_pvid(). When a dev is specified, lvmcache_info_from_pvid() will verify that the cached info it's using matches the dev being processed before returning the info. Calling code will not mistakenly get info for the wrong dev when duplicate devs exist. This confusion was happening when scanning labels when duplicate devs existed. label_read for the first dev would add an info struct to lvmcache for that dev/pvid. label_read for the second dev would see the pvid in lvmcache from first dev, and mistakenly conclude that the label_read from the second dev can be skipped because it's already been done. By verifying that the dev for the cached pvid matches the dev being read, this mismatch is avoided and the label is actually read from the second duplicate.
2016-06-06 22:04:17 +03:00
info = lvmcache_info_from_pvid(dev->pvid, NULL, 0);
devices: improve handling of duplicate PVs Example: /dev/loop0 and /dev/loop1 are duplicates, created by copying one backing file to the other. 'identity /dev/loopX' creates an identity mapping for loopX named idmloopX, which adds a duplicate for the named device. The duplicate selection code for lvmetad is incomplete, and lvmetad is disabled for this example. [~]# losetup -f loopfile0 [~]# pvs PV VG Fmt Attr PSize PFree /dev/loop0 foo lvm2 a-- 308.00m 296.00m [~]# losetup -f loopfile1 [~]# pvs Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/loop1 not /dev/loop0 Using duplicate PV /dev/loop1 which is more recent, replacing /dev/loop0 PV VG Fmt Attr PSize PFree /dev/loop1 foo lvm2 a-- 308.00m 308.00m [~]# ./identity /dev/loop0 [~]# pvs Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/loop1 not /dev/loop0 Using duplicate PV /dev/loop1 without holders, replacing /dev/loop0 Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/mapper/idmloop0 not /dev/loop1 Using duplicate PV /dev/mapper/idmloop0 from subsystem DM, replacing /dev/loop1 PV VG Fmt Attr PSize PFree /dev/mapper/idmloop0 foo lvm2 a-- 308.00m 296.00m [~]# ./identity /dev/loop1 [~]# pvs WARNING: duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV is being used from both devices /dev/loop0 and /dev/loop1 Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/loop1 not /dev/loop0 Using duplicate PV /dev/loop1 which is more recent, replacing /dev/loop0 Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/mapper/idmloop0 not /dev/loop1 Using duplicate PV /dev/mapper/idmloop0 from subsystem DM, replacing /dev/loop1 Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/mapper/idmloop1 not /dev/mapper/idmloop0 Using duplicate PV /dev/mapper/idmloop1 which is more recent, replacing /dev/mapper/idmloop0 PV VG Fmt Attr PSize PFree /dev/mapper/idmloop1 foo lvm2 a-- 308.00m 308.00m
2015-04-24 22:58:58 +03:00
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
if (!info) {
change args for text label read function Have the caller pass the label_sector to the read function so the read function can set the sector field in the label struct, instead of having the read function return a pointer to the label for the caller to set the sector field. Also have the read function return a flag indicating to the caller that the scanned device was identified as a duplicate pv.
2019-02-05 22:40:34 +03:00
info = _create_info(labeller, dev, label_sector);
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
created = 1;
}
devices: improve handling of duplicate PVs Example: /dev/loop0 and /dev/loop1 are duplicates, created by copying one backing file to the other. 'identity /dev/loopX' creates an identity mapping for loopX named idmloopX, which adds a duplicate for the named device. The duplicate selection code for lvmetad is incomplete, and lvmetad is disabled for this example. [~]# losetup -f loopfile0 [~]# pvs PV VG Fmt Attr PSize PFree /dev/loop0 foo lvm2 a-- 308.00m 296.00m [~]# losetup -f loopfile1 [~]# pvs Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/loop1 not /dev/loop0 Using duplicate PV /dev/loop1 which is more recent, replacing /dev/loop0 PV VG Fmt Attr PSize PFree /dev/loop1 foo lvm2 a-- 308.00m 308.00m [~]# ./identity /dev/loop0 [~]# pvs Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/loop1 not /dev/loop0 Using duplicate PV /dev/loop1 without holders, replacing /dev/loop0 Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/mapper/idmloop0 not /dev/loop1 Using duplicate PV /dev/mapper/idmloop0 from subsystem DM, replacing /dev/loop1 PV VG Fmt Attr PSize PFree /dev/mapper/idmloop0 foo lvm2 a-- 308.00m 296.00m [~]# ./identity /dev/loop1 [~]# pvs WARNING: duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV is being used from both devices /dev/loop0 and /dev/loop1 Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/loop1 not /dev/loop0 Using duplicate PV /dev/loop1 which is more recent, replacing /dev/loop0 Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/mapper/idmloop0 not /dev/loop1 Using duplicate PV /dev/mapper/idmloop0 from subsystem DM, replacing /dev/loop1 Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/mapper/idmloop1 not /dev/mapper/idmloop0 Using duplicate PV /dev/mapper/idmloop1 which is more recent, replacing /dev/mapper/idmloop0 PV VG Fmt Attr PSize PFree /dev/mapper/idmloop1 foo lvm2 a-- 308.00m 308.00m
2015-04-24 22:58:58 +03:00
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
if (!info)
return_NULL;
/*
* If an existing info struct was found, check if any values are new.
*/
if (!created) {
if (info->dev != dev) {
improve duplicate pv handling for md components Eliminate md components at the start so they don't interfere with actual duplicates, and don't need to be removed later. This also allows for choosing no copy of a PVID if they all happen to be md components.
2019-08-01 23:04:10 +03:00
log_debug_cache("Saving initial duplicate device %s previously seen on %s with PVID %s.",
dev_name(dev), dev_name(info->dev), uuid);
devices: improve handling of duplicate PVs Example: /dev/loop0 and /dev/loop1 are duplicates, created by copying one backing file to the other. 'identity /dev/loopX' creates an identity mapping for loopX named idmloopX, which adds a duplicate for the named device. The duplicate selection code for lvmetad is incomplete, and lvmetad is disabled for this example. [~]# losetup -f loopfile0 [~]# pvs PV VG Fmt Attr PSize PFree /dev/loop0 foo lvm2 a-- 308.00m 296.00m [~]# losetup -f loopfile1 [~]# pvs Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/loop1 not /dev/loop0 Using duplicate PV /dev/loop1 which is more recent, replacing /dev/loop0 PV VG Fmt Attr PSize PFree /dev/loop1 foo lvm2 a-- 308.00m 308.00m [~]# ./identity /dev/loop0 [~]# pvs Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/loop1 not /dev/loop0 Using duplicate PV /dev/loop1 without holders, replacing /dev/loop0 Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/mapper/idmloop0 not /dev/loop1 Using duplicate PV /dev/mapper/idmloop0 from subsystem DM, replacing /dev/loop1 PV VG Fmt Attr PSize PFree /dev/mapper/idmloop0 foo lvm2 a-- 308.00m 296.00m [~]# ./identity /dev/loop1 [~]# pvs WARNING: duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV is being used from both devices /dev/loop0 and /dev/loop1 Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/loop1 not /dev/loop0 Using duplicate PV /dev/loop1 which is more recent, replacing /dev/loop0 Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/mapper/idmloop0 not /dev/loop1 Using duplicate PV /dev/mapper/idmloop0 from subsystem DM, replacing /dev/loop1 Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/mapper/idmloop1 not /dev/mapper/idmloop0 Using duplicate PV /dev/mapper/idmloop1 which is more recent, replacing /dev/mapper/idmloop0 PV VG Fmt Attr PSize PFree /dev/mapper/idmloop1 foo lvm2 a-- 308.00m 308.00m
2015-04-24 22:58:58 +03:00
strncpy(dev->pvid, pvid_s, sizeof(dev->pvid));
improve duplicate pv handling for md components Eliminate md components at the start so they don't interfere with actual duplicates, and don't need to be removed later. This also allows for choosing no copy of a PVID if they all happen to be md components.
2019-08-01 23:04:10 +03:00
/* shouldn't happen */
if (dev_in_device_list(dev, &_initial_duplicates))
log_debug_cache("Initial duplicate already in list %s", dev_name(dev));
cov: fix memleak for duplicate device For dev_in_device_list() != 0 allocated 'devl' was actually leaking - so instead allocate 'devl' only when !dev_in_device_list() and indent code around.
2019-11-14 19:08:20 +03:00
else {
/*
* Keep the existing PV/dev in lvmcache, and save the
* new duplicate in the list of duplicates. After
* scanning is complete, compare the duplicate devs
* with those in lvmcache to check if one of the
* duplicates is preferred and if so switch lvmcache to
* use it.
*/
if (!(devl = zalloc(sizeof(*devl))))
return_NULL;
devl->dev = dev;
improve duplicate pv handling for md components Eliminate md components at the start so they don't interfere with actual duplicates, and don't need to be removed later. This also allows for choosing no copy of a PVID if they all happen to be md components.
2019-08-01 23:04:10 +03:00
dm_list_add(&_initial_duplicates, &devl->list);
cov: fix memleak for duplicate device For dev_in_device_list() != 0 allocated 'devl' was actually leaking - so instead allocate 'devl' only when !dev_in_device_list() and indent code around.
2019-11-14 19:08:20 +03:00
}
improve duplicate pv handling for md components Eliminate md components at the start so they don't interfere with actual duplicates, and don't need to be removed later. This also allows for choosing no copy of a PVID if they all happen to be md components.
2019-08-01 23:04:10 +03:00
change args for text label read function Have the caller pass the label_sector to the read function so the read function can set the sector field in the label struct, instead of having the read function return a pointer to the label for the caller to set the sector field. Also have the read function return a flag indicating to the caller that the scanned device was identified as a duplicate pv.
2019-02-05 22:40:34 +03:00
if (is_duplicate)
*is_duplicate = 1;
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
return NULL;
Detect duplicate PV uuids - select the one on an md device if appropriate.
2003-01-07 00:10:43 +03:00
}
devices: improve handling of duplicate PVs Example: /dev/loop0 and /dev/loop1 are duplicates, created by copying one backing file to the other. 'identity /dev/loopX' creates an identity mapping for loopX named idmloopX, which adds a duplicate for the named device. The duplicate selection code for lvmetad is incomplete, and lvmetad is disabled for this example. [~]# losetup -f loopfile0 [~]# pvs PV VG Fmt Attr PSize PFree /dev/loop0 foo lvm2 a-- 308.00m 296.00m [~]# losetup -f loopfile1 [~]# pvs Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/loop1 not /dev/loop0 Using duplicate PV /dev/loop1 which is more recent, replacing /dev/loop0 PV VG Fmt Attr PSize PFree /dev/loop1 foo lvm2 a-- 308.00m 308.00m [~]# ./identity /dev/loop0 [~]# pvs Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/loop1 not /dev/loop0 Using duplicate PV /dev/loop1 without holders, replacing /dev/loop0 Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/mapper/idmloop0 not /dev/loop1 Using duplicate PV /dev/mapper/idmloop0 from subsystem DM, replacing /dev/loop1 PV VG Fmt Attr PSize PFree /dev/mapper/idmloop0 foo lvm2 a-- 308.00m 296.00m [~]# ./identity /dev/loop1 [~]# pvs WARNING: duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV is being used from both devices /dev/loop0 and /dev/loop1 Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/loop1 not /dev/loop0 Using duplicate PV /dev/loop1 which is more recent, replacing /dev/loop0 Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/mapper/idmloop0 not /dev/loop1 Using duplicate PV /dev/mapper/idmloop0 from subsystem DM, replacing /dev/loop1 Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/mapper/idmloop1 not /dev/mapper/idmloop0 Using duplicate PV /dev/mapper/idmloop1 which is more recent, replacing /dev/mapper/idmloop0 PV VG Fmt Attr PSize PFree /dev/mapper/idmloop1 foo lvm2 a-- 308.00m 308.00m
2015-04-24 22:58:58 +03:00
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
if (info->dev->pvid[0] && pvid[0] && strcmp(pvid_s, info->dev->pvid)) {
/* This happens when running pvcreate on an existing PV. */
improve duplicate pv handling for md components Eliminate md components at the start so they don't interfere with actual duplicates, and don't need to be removed later. This also allows for choosing no copy of a PVID if they all happen to be md components.
2019-08-01 23:04:10 +03:00
log_debug_cache("Changing pvid on dev %s from %s to %s",
dev_name(info->dev), info->dev->pvid, pvid_s);
devices: improve handling of duplicate PVs Example: /dev/loop0 and /dev/loop1 are duplicates, created by copying one backing file to the other. 'identity /dev/loopX' creates an identity mapping for loopX named idmloopX, which adds a duplicate for the named device. The duplicate selection code for lvmetad is incomplete, and lvmetad is disabled for this example. [~]# losetup -f loopfile0 [~]# pvs PV VG Fmt Attr PSize PFree /dev/loop0 foo lvm2 a-- 308.00m 296.00m [~]# losetup -f loopfile1 [~]# pvs Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/loop1 not /dev/loop0 Using duplicate PV /dev/loop1 which is more recent, replacing /dev/loop0 PV VG Fmt Attr PSize PFree /dev/loop1 foo lvm2 a-- 308.00m 308.00m [~]# ./identity /dev/loop0 [~]# pvs Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/loop1 not /dev/loop0 Using duplicate PV /dev/loop1 without holders, replacing /dev/loop0 Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/mapper/idmloop0 not /dev/loop1 Using duplicate PV /dev/mapper/idmloop0 from subsystem DM, replacing /dev/loop1 PV VG Fmt Attr PSize PFree /dev/mapper/idmloop0 foo lvm2 a-- 308.00m 296.00m [~]# ./identity /dev/loop1 [~]# pvs WARNING: duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV is being used from both devices /dev/loop0 and /dev/loop1 Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/loop1 not /dev/loop0 Using duplicate PV /dev/loop1 which is more recent, replacing /dev/loop0 Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/mapper/idmloop0 not /dev/loop1 Using duplicate PV /dev/mapper/idmloop0 from subsystem DM, replacing /dev/loop1 Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/mapper/idmloop1 not /dev/mapper/idmloop0 Using duplicate PV /dev/mapper/idmloop1 which is more recent, replacing /dev/mapper/idmloop0 PV VG Fmt Attr PSize PFree /dev/mapper/idmloop1 foo lvm2 a-- 308.00m 308.00m
2015-04-24 22:58:58 +03:00
}
A new cache.
2002-11-18 16:53:58 +03:00
if (info->label->labeller != labeller) {
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
log_verbose("Changing labeller on dev %s from %s to %s",
dev_name(info->dev),
info->label->labeller->fmt->name,
labeller->fmt->name);
A new cache.
2002-11-18 16:53:58 +03:00
label_destroy(info->label);
Use stack return macros throughout.
2008-01-30 16:19:47 +03:00
if (!(info->label = label_create(labeller)))
return_NULL;
A new cache.
2002-11-18 16:53:58 +03:00
info->label->info = info;
}
}
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
/*
* Add or update the _pvid_hash mapping, pvid to info.
*/
info_lookup = dm_hash_lookup(_pvid_hash, pvid_s);
if ((info_lookup == info) && !strcmp(info->dev->pvid, pvid_s))
goto update_vginfo;
if (info->dev->pvid[0])
dm_hash_remove(_pvid_hash, info->dev->pvid);
strncpy(info->dev->pvid, pvid_s, sizeof(info->dev->pvid));
if (!dm_hash_insert(_pvid_hash, pvid_s, info)) {
log_error("Adding pvid to hash failed %s", pvid_s);
A new cache.
2002-11-18 16:53:58 +03:00
return NULL;
}
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
update_vginfo:
vgsummary.vgstatus = vgstatus;
vgsummary.vgname = vgname;
if (vgid)
strncpy((char *)&vgsummary.vgid, vgid, sizeof(vgsummary.vgid));
pass cmd struct through more functions no functional change
2020-01-28 19:33:15 +03:00
if (!lvmcache_update_vgname_and_id(cmd, info, &vgsummary)) {
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
if (created) {
Use hash, bitset, malloc, pool from libdevmapper.
2005-10-17 03:03:59 +04:00
dm_hash_remove(_pvid_hash, pvid_s);
A new cache.
2002-11-18 16:53:58 +03:00
strcpy(info->dev->pvid, "");
device_mapper: remove dbg_malloc. I wrote dbg_malloc before we had valgrind. These days there's just no need.
2018-06-08 15:40:53 +03:00
free(info->label);
free(info);
A new cache.
2002-11-18 16:53:58 +03:00
}
return NULL;
}
return info;
}
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
static void _lvmcache_destroy_info(struct lvmcache_info *info)
A new cache.
2002-11-18 16:53:58 +03:00
{
Refactor some vginfo manipulation code.
2008-05-19 23:49:56 +04:00
_vginfo_detach_info(info);
cleanup: simplier string reset
2013-07-19 17:32:49 +04:00
info->dev->pvid[0] = 0;
A new cache.
2002-11-18 16:53:58 +03:00
label_destroy(info->label);
device_mapper: remove dbg_malloc. I wrote dbg_malloc before we had valgrind. These days there's just no need.
2018-06-08 15:40:53 +03:00
free(info);
A new cache.
2002-11-18 16:53:58 +03:00
}
lvmcache: handle reinit without error Since commit f12ee43f2eaba5d38b1925a5a34b1746c1d66985 call destroy, it start to check all VGs are unlocked. However when we become_daemon, we simply reset locking (since lock is still kept by parent process). So implement a simple 'reset' flag.
2014-03-22 01:26:39 +04:00
void lvmcache_destroy(struct cmd_context *cmd, int retain_orphans, int reset)
A new cache.
2002-11-18 16:53:58 +03:00
{
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
struct lvmcache_vginfo *vginfo, *vginfo2;
log_debug_cache("Destroy lvmcache content");
Improve detection of external changes affecting internal cache.
2005-03-22 01:40:35 +03:00
A new cache.
2002-11-18 16:53:58 +03:00
if (_vgid_hash) {
Use hash, bitset, malloc, pool from libdevmapper.
2005-10-17 03:03:59 +04:00
dm_hash_destroy(_vgid_hash);
A new cache.
2002-11-18 16:53:58 +03:00
_vgid_hash = NULL;
}
if (_pvid_hash) {
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
dm_hash_iter(_pvid_hash, (dm_hash_iterate_fn) _lvmcache_destroy_info);
Use hash, bitset, malloc, pool from libdevmapper.
2005-10-17 03:03:59 +04:00
dm_hash_destroy(_pvid_hash);
A new cache.
2002-11-18 16:53:58 +03:00
_pvid_hash = NULL;
}
if (_vgname_hash) {
Use hash, bitset, malloc, pool from libdevmapper.
2005-10-17 03:03:59 +04:00
dm_hash_destroy(_vgname_hash);
A new cache.
2002-11-18 16:53:58 +03:00
_vgname_hash = NULL;
}
Another sync point - numerous fixes & clean ups.
2003-07-05 02:34:56 +04:00
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
dm_list_iterate_items_safe(vginfo, vginfo2, &_vginfos) {
dm_list_del(&vginfo->list);
_free_vginfo(vginfo);
}
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
if (!dm_list_empty(&_vginfos))
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
log_error(INTERNAL_ERROR "vginfos list should be empty");
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
dm_list_init(&_vginfos);
Fix vgreduce to use vg_split_mdas to check sufficient mdas remain. Add (empty) orphan VGs to lvmcache during initialisation. Fix orphan VG name used for format_pool.
2008-04-08 16:49:21 +04:00
lvmcache: fix duplicate handling with multiple scans Some commands scan labels to populate lvmcache multiple times, i.e. lvmcache_init, scan labels to fill lvmcache, lvmcache_destroy, then later repeat Each time labels are scanned, duplicates are detected, and preferred devices are chosen. Each time this is done within a single command, we want to choose the same preferred devices. So, check for existing preferences when choosing preferred devices. This also fixes a problem with the list of unused duplicate devs when run in an lvm shell. The devs had been allocated from cmd memory, resulting in invalid list entries between commands.
2016-06-06 23:20:55 +03:00
/*
lvmcache: renaming functions and variables related to duplicates, no functional changes.
2019-08-01 21:50:04 +03:00
* Move the current _unused_duplicates to _prev_unused_duplicate_devs
* before destroying _unused_duplicates.
lvmcache: fix duplicate handling with multiple scans Some commands scan labels to populate lvmcache multiple times, i.e. lvmcache_init, scan labels to fill lvmcache, lvmcache_destroy, then later repeat Each time labels are scanned, duplicates are detected, and preferred devices are chosen. Each time this is done within a single command, we want to choose the same preferred devices. So, check for existing preferences when choosing preferred devices. This also fixes a problem with the list of unused duplicate devs when run in an lvm shell. The devs had been allocated from cmd memory, resulting in invalid list entries between commands.
2016-06-06 23:20:55 +03:00
*
* One command can init/populate/destroy lvmcache multiple times. Each
* time it will encounter duplicates and choose the preferrred devs.
* We want the same preferred devices to be chosen each time, so save
* the unpreferred devs here so that _choose_preferred_devs can use
* this to make the same choice each time.
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
*
* FIXME: I don't think is is needed any more.
lvmcache: fix duplicate handling with multiple scans Some commands scan labels to populate lvmcache multiple times, i.e. lvmcache_init, scan labels to fill lvmcache, lvmcache_destroy, then later repeat Each time labels are scanned, duplicates are detected, and preferred devices are chosen. Each time this is done within a single command, we want to choose the same preferred devices. So, check for existing preferences when choosing preferred devices. This also fixes a problem with the list of unused duplicate devs when run in an lvm shell. The devs had been allocated from cmd memory, resulting in invalid list entries between commands.
2016-06-06 23:20:55 +03:00
*/
lvmcache: renaming functions and variables related to duplicates, no functional changes.
2019-08-01 21:50:04 +03:00
_destroy_device_list(&_prev_unused_duplicate_devs);
dm_list_splice(&_prev_unused_duplicate_devs, &_unused_duplicates);
_destroy_device_list(&_unused_duplicates);
_destroy_device_list(&_initial_duplicates); /* should be empty anyway */
lvmcache: fix duplicate handling with multiple scans Some commands scan labels to populate lvmcache multiple times, i.e. lvmcache_init, scan labels to fill lvmcache, lvmcache_destroy, then later repeat Each time labels are scanned, duplicates are detected, and preferred devices are chosen. Each time this is done within a single command, we want to choose the same preferred devices. So, check for existing preferences when choosing preferred devices. This also fixes a problem with the list of unused duplicate devs when run in an lvm shell. The devs had been allocated from cmd memory, resulting in invalid list entries between commands.
2016-06-06 23:20:55 +03:00
clvmd: separate saved_vg from vginfo The clvmd saved_vg data is independent from the normal lvm lvmcache vginfo data, so separate saved_vg from vginfo. Normal lvm doesn't need to use save_vg at all, and in clvmd, lvmcache changes on vginfo can be made without worrying about unwanted effects on saved_vg.
2018-05-03 00:58:49 +03:00
if (retain_orphans) {
struct format_type *fmt;
debug: missing backtrace
2018-11-03 00:19:26 +03:00
if (!lvmcache_init(cmd))
stack;
clvmd: separate saved_vg from vginfo The clvmd saved_vg data is independent from the normal lvm lvmcache vginfo data, so separate saved_vg from vginfo. Normal lvm doesn't need to use save_vg at all, and in clvmd, lvmcache changes on vginfo can be made without worrying about unwanted effects on saved_vg.
2018-05-03 00:58:49 +03:00
dm_list_iterate_items(fmt, &cmd->formats) {
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
if (!lvmcache_add_orphan_vginfo(cmd, fmt->orphan_vg_name, fmt))
clvmd: separate saved_vg from vginfo The clvmd saved_vg data is independent from the normal lvm lvmcache vginfo data, so separate saved_vg from vginfo. Normal lvm doesn't need to use save_vg at all, and in clvmd, lvmcache changes on vginfo can be made without worrying about unwanted effects on saved_vg.
2018-05-03 00:58:49 +03:00
stack;
}
}
A new cache.
2002-11-18 16:53:58 +03:00
}
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
int lvmcache_fid_add_mdas(struct lvmcache_info *info, struct format_instance *fid,
const char *id, int id_len)
{
return fid_add_mdas(fid, &info->mdas, id, id_len);
}
int lvmcache_fid_add_mdas_pv(struct lvmcache_info *info, struct format_instance *fid)
{
return lvmcache_fid_add_mdas(info, fid, info->dev->pvid, ID_LEN);
}
improve reading and repairing vg metadata The fact that vg repair is implemented as a part of vg read has led to a messy and complicated implementation of vg_read, and limited and uncontrolled repair capability. This splits read and repair apart. Summary ------- - take all kinds of various repairs out of vg_read - vg_read no longer writes anything - vg_read now simply reads and returns vg metadata - vg_read ignores bad or old copies of metadata - vg_read proceeds with a single good copy of metadata - improve error checks and handling when reading - keep track of bad (corrupt) copies of metadata in lvmcache - keep track of old (seqno) copies of metadata in lvmcache - keep track of outdated PVs in lvmcache - vg_write will do basic repairs - new command vgck --updatemetdata will do all repairs Details ------- - In scan, do not delete dev from lvmcache if reading/processing fails; the dev is still present, and removing it makes it look like the dev is not there. Records are now kept about the problems with each PV so they be fixed/repaired in the appropriate places. - In scan, record a bad mda on failure, and delete the mda from mda in use list so it will not be used by vg_read or vg_write, only by repair. - In scan, succeed if any good mda on a device is found, instead of failing if any is bad. The bad/old copies of metadata should not interfere with normal usage while good copies can be used. - In scan, add a record of old mdas in lvmcache for later, do not repair them while reading, and do not let them prevent us from finding and using a good copy of metadata from elsewhere. One result is that "inconsistent metadata" is no longer a read error, but instead a record in lvmcache that can be addressed separate from the read. - Treat a dev with no good mdas like a dev with no mdas, which is an existing case we already handle. - Don't use a fake vg "handle" for returning an error from vg_read, or the vg_read_error function for getting that error number; just return null if the vg cannot be read or used, and an error_flags arg with flags set for the specific kind of error (which can be used later for determining the kind of repair.) - Saving an original copy of the vg metadata, for purposes of reverting a write, is now done explicitly in vg_read instead of being hidden in the vg_make_handle function. - When a vg is not accessible due to "access restrictions" but is otherwise fine, return the vg through the new error_vg arg so that process_each_pv can skip the PVs in the VG while processing. (This is a temporary accomodation for the way process_each_pv tracks which devs have been looked at, and can be dropped later when process_each_pv implementation dev tracking is changed.) - vg_read does not try to fix or recover a vg, but now just reads the metadata, checks access restrictions and returns it. (Checking access restrictions might be better done outside of vg_read, but this is a later improvement.) - _vg_read now simply makes one attempt to read metadata from each mda, and uses the most recent copy to return to the caller in the form of a 'vg' struct. (bad mdas were excluded during the scan and are not retried) (old mdas were not excluded during scan and are retried here) - vg_read uses _vg_read to get the latest copy of metadata from mdas, and then makes various checks against it to produce warnings, and to check if VG access is allowed (access restrictions include: writable, foreign, shared, clustered, missing pvs). - Things that were previously silently/automatically written by vg_read that are now done by vg_write, based on the records made in lvmcache during the scan and read: . clearing the missing flag . updating old copies of metadata . clearing outdated pvs . updating pv header flags - Bad/corrupt metadata are now repaired; they were not before. Test changes ------------ - A read command no longer writes the VG to repair it, so add a write command to do a repair. (inconsistent-metadata, unlost-pv) - When a missing PV is removed from a VG, and then the device is enabled again, vgck --updatemetadata is needed to clear the outdated PV before it can be used again, where it wasn't before. (lvconvert-repair-policy, lvconvert-repair-raid, lvconvert-repair, mirror-vgreduce-removemissing, pv-ext-flags, unlost-pv) Reading bad/old metadata ------------------------ - "bad metadata": the mda_header or metadata text has invalid fields or can't be parsed by lvm. This is a form of corruption that would not be caused by known failure scenarios. A checksum error is typically included among the errors reported. - "old metadata": a valid copy of the metadata that has a smaller seqno than other copies of the metadata. This can happen if the device failed, or io failed, or lvm failed while commiting new metadata to all the metadata areas. Old metadata on a PV that has been removed from the VG is the "outdated" case below. When a VG has some PVs with bad/old metadata, lvm can simply ignore the bad/old copies, and use a good copy. This is why there are multiple copies of the metadata -- so it's available even when some of the copies cannot be used. The bad/old copies do not have to be repaired before the VG can be used (the repair can happen later.) A PV with no good copies of the metadata simply falls back to being treated like a PV with no mdas; a common and harmless configuration. When bad/old metadata exists, lvm warns the user about it, and suggests repairing it using a new metadata repair command. Bad metadata in particular is something that users will want to investigate and repair themselves, since it should not happen and may indicate some other problem that needs to be fixed. PVs with bad/old metadata are not the same as missing devices. Missing devices will block various kinds of VG modification or activation, but bad/old metadata will not. Previously, lvm would attempt to repair bad/old metadata whenever it was read. This was unnecessary since lvm does not require every copy of the metadata to be used. It would also hide potential problems that should be investigated by the user. It was also dangerous in cases where the VG was on shared storage. The user is now allowed to investigate potential problems and decide how and when to repair them. Repairing bad/old metadata -------------------------- When label scan sees bad metadata in an mda, that mda is removed from the lvmcache info->mdas list. This means that vg_read will skip it, and not attempt to read/process it again. If it was the only in-use mda on a PV, that PV is treated like a PV with no mdas. It also means that vg_write will also skip the bad mda, and not attempt to write new metadata to it. The only way to repair bad metadata is with the metadata repair command. When label scan sees old metadata in an mda, that mda is kept in the lvmcache info->mdas list. This means that vg_read will read/process it again, and likely see the same mismatch with the other copies of the metadata. Like the label_scan, the vg_read will simply ignore the old copy of the metadata and use the latest copy. If the command is modifying the vg (e.g. lvcreate), then vg_write, which writes new metadata to every mda on info->mdas, will write the new metadata to the mda that had the old version. If successful, this will resolve the old metadata problem (without needing to run a metadata repair command.) Outdated PVs ------------ An outdated PV is a PV that has an old copy of VG metadata that shows it is a member of the VG, but the latest copy of the VG metadata does not include this PV. This happens if the PV is disconnected, vgreduce --removemissing is run to remove the PV from the VG, then the PV is reconnected. In this case, the outdated PV needs have its outdated metadata removed and the PV used flag needs to be cleared. This repair will be done by the subsequent repair command. It is also done if vgremove is run on the VG. MISSING PVs ----------- When a device is missing, most commands will refuse to modify the VG. This is the simple case. More complicated is when a command is allowed to modify the VG while it is missing a device. When a VG is written while a device is missing for one of it's PVs, the VG metadata is written to disk with the MISSING flag on the PV with the missing device. When the VG is next used, it is treated as if the PV with the MISSING flag still has a missing device, even if that device has reappeared. If all LVs that were using a PV with the MISSING flag are removed or repaired so that the MISSING PV is no longer used, then the next time the VG metadata is written, the MISSING flag will be dropped. Alternative methods of clearing the MISSING flag are: vgreduce --removemissing will remove PVs with missing devices, or PVs with the MISSING flag where the device has reappeared. vgextend --restoremissing will clear the MISSING flag on PVs where the device has reappeared, allowing the VG to be used normally. This must be done with caution since the reappeared device may have old data that is inconsistent with data on other PVs. Bad mda repair -------------- The new command: vgck --updatemetadata VG first uses vg_write to repair old metadata, and other basic issues mentioned above (old metadata, outdated PVs, pv_header flags, MISSING_PV flags). It will also go further and repair bad metadata: . text metadata that has a bad checksum . text metadata that is not parsable . corrupt mda_header checksum and version fields (To keep a clean diff, #if 0 is added around functions that are replaced by new code. These commented functions are removed by the following commit.)
2019-05-24 20:04:37 +03:00
/*
* This is the linkage where information is passed from
* the label_scan to vg_read.
*
* Called by create_text_instance in vg_read to copy the
* mda's found during label_scan and saved in info->mdas,
* to fid->metadata_areas_in_use which is used by vg_read.
*/
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
int lvmcache_fid_add_mdas_vg(struct lvmcache_vginfo *vginfo, struct format_instance *fid)
{
struct lvmcache_info *info;
dm_list_iterate_items(info, &vginfo->infos) {
if (!lvmcache_fid_add_mdas_pv(info, fid))
return_0;
}
return 1;
}
int lvmcache_populate_pv_fields(struct lvmcache_info *info,
label_scan: remove extra label scan and read for orphan PVs When process_each_pv() calls vg_read() on the orphan VG, the internal implementation was doing an unnecessary lvmcache_label_scan() and two unnecessary label_read() calls on each orphan. Some of those unnecessary label scans/reads would sometimes be skipped due to caching, but the code was always doing at least one unnecessary read on each orphan. The common format_text case was also unecessarily calling into the format-specific pv_read() function which actually did nothing. By analyzing each case in which vg_read() was being called on the orphan VG, we can say that all of the label scans/reads in vg_read_orphans are unnecessary: 1. reporting commands: the information saved in lvmcache by the original label scan can be reported. There is no advantage to repeating the label scan on the orphans a second time before reporting it. 2. pvcreate/vgcreate/vgextend: these all share a common implementation in pvcreate_each_device(). That function already rescans labels after acquiring the orphan VG lock, which ensures that the command is using valid lvmcache information.
2017-11-06 21:09:52 +03:00
struct volume_group *vg,
struct physical_volume *pv)
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
{
struct data_area_list *da;
label_scan: remove extra label scan and read for orphan PVs When process_each_pv() calls vg_read() on the orphan VG, the internal implementation was doing an unnecessary lvmcache_label_scan() and two unnecessary label_read() calls on each orphan. Some of those unnecessary label scans/reads would sometimes be skipped due to caching, but the code was always doing at least one unnecessary read on each orphan. The common format_text case was also unecessarily calling into the format-specific pv_read() function which actually did nothing. By analyzing each case in which vg_read() was being called on the orphan VG, we can say that all of the label scans/reads in vg_read_orphans are unnecessary: 1. reporting commands: the information saved in lvmcache by the original label scan can be reported. There is no advantage to repeating the label scan on the orphans a second time before reporting it. 2. pvcreate/vgcreate/vgextend: these all share a common implementation in pvcreate_each_device(). That function already rescans labels after acquiring the orphan VG lock, which ensures that the command is using valid lvmcache information.
2017-11-06 21:09:52 +03:00
if (!info->label) {
log_error("No cached label for orphan PV %s", pv_dev_name(pv));
return 0;
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
}
label_scan: remove extra label scan and read for orphan PVs When process_each_pv() calls vg_read() on the orphan VG, the internal implementation was doing an unnecessary lvmcache_label_scan() and two unnecessary label_read() calls on each orphan. Some of those unnecessary label scans/reads would sometimes be skipped due to caching, but the code was always doing at least one unnecessary read on each orphan. The common format_text case was also unecessarily calling into the format-specific pv_read() function which actually did nothing. By analyzing each case in which vg_read() was being called on the orphan VG, we can say that all of the label scans/reads in vg_read_orphans are unnecessary: 1. reporting commands: the information saved in lvmcache by the original label scan can be reported. There is no advantage to repeating the label scan on the orphans a second time before reporting it. 2. pvcreate/vgcreate/vgextend: these all share a common implementation in pvcreate_each_device(). That function already rescans labels after acquiring the orphan VG lock, which ensures that the command is using valid lvmcache information.
2017-11-06 21:09:52 +03:00
pv->label_sector = info->label->sector;
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
pv->dev = info->dev;
pv->fmt = info->fmt;
pv->size = info->device_size >> SECTOR_SHIFT;
pv->vg_name = FMT_TEXT_ORPHAN_VG_NAME;
memcpy(&pv->id, &info->dev->pvid, sizeof(pv->id));
label_scan: remove extra label scan and read for orphan PVs When process_each_pv() calls vg_read() on the orphan VG, the internal implementation was doing an unnecessary lvmcache_label_scan() and two unnecessary label_read() calls on each orphan. Some of those unnecessary label scans/reads would sometimes be skipped due to caching, but the code was always doing at least one unnecessary read on each orphan. The common format_text case was also unecessarily calling into the format-specific pv_read() function which actually did nothing. By analyzing each case in which vg_read() was being called on the orphan VG, we can say that all of the label scans/reads in vg_read_orphans are unnecessary: 1. reporting commands: the information saved in lvmcache by the original label scan can be reported. There is no advantage to repeating the label scan on the orphans a second time before reporting it. 2. pvcreate/vgcreate/vgextend: these all share a common implementation in pvcreate_each_device(). That function already rescans labels after acquiring the orphan VG lock, which ensures that the command is using valid lvmcache information.
2017-11-06 21:09:52 +03:00
if (!pv->size) {
log_error("PV %s size is zero.", dev_name(info->dev));
return 0;
}
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
/* Currently only support exactly one data area */
if (dm_list_size(&info->das) != 1) {
log_error("Must be exactly one data area (found %d) on PV %s",
dm_list_size(&info->das), dev_name(info->dev));
return 0;
}
refactor: rename embedding area -> bootloader area
2013-05-28 14:37:22 +04:00
/* Currently only support one bootloader area at most */
if (dm_list_size(&info->bas) > 1) {
log_error("Must be at most one bootloader area (found %d) on PV %s",
dm_list_size(&info->bas), dev_name(info->dev));
pv_header_extension: add support for reading PV header extension (flags & Embedding Area) New tools with PV header extension support will read the extension if it exists and it's not an error if it does not exist (so old PVs will still work seamlessly with new tools). Old tools without PV header extension support will just ignore any extension. As for the Embedding Area location information (its start and size), there are actually two places where this is stored: - PV header extension - VG metadata The VG metadata contains a copy of what's written in the PV header extension about the Embedding Area location (NULL value is not copied): physical_volumes { pv0 { id = "AkSSRf-difg-fCCZ-NjAN-qP49-1zzg-S0Fd4T" device = "/dev/sda" # Hint only status = ["ALLOCATABLE"] flags = [] dev_size = 262144 # 128 Megabytes pe_start = 67584 pe_count = 23 # 92 Megabytes ea_start = 2048 ea_size = 65536 # 32 Megabytes } } The new metadata fields are "ea_start" and "ea_size". This is mostly useful when restoring the PV by using existing metadata backups (e.g. pvcreate --restorefile ...). New tools does not require these two fields to exist in VG metadata, they're not compulsory. Therefore, reading old VG metadata which doesn't contain any Embedding Area information will not end up with any kind of error but only a debug message that the ea_start and ea_size values were not found. Old tools just ignore these extra fields in VG metadata.
2013-02-14 19:04:35 +04:00
return 0;
}
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
dm_list_iterate_items(da, &info->das)
pv->pe_start = da->disk_locn.offset >> SECTOR_SHIFT;
refactor: rename embedding area -> bootloader area
2013-05-28 14:37:22 +04:00
dm_list_iterate_items(da, &info->bas) {
pv->ba_start = da->disk_locn.offset >> SECTOR_SHIFT;
pv->ba_size = da->disk_locn.size >> SECTOR_SHIFT;
pv_header_extension: add support for reading PV header extension (flags & Embedding Area) New tools with PV header extension support will read the extension if it exists and it's not an error if it does not exist (so old PVs will still work seamlessly with new tools). Old tools without PV header extension support will just ignore any extension. As for the Embedding Area location information (its start and size), there are actually two places where this is stored: - PV header extension - VG metadata The VG metadata contains a copy of what's written in the PV header extension about the Embedding Area location (NULL value is not copied): physical_volumes { pv0 { id = "AkSSRf-difg-fCCZ-NjAN-qP49-1zzg-S0Fd4T" device = "/dev/sda" # Hint only status = ["ALLOCATABLE"] flags = [] dev_size = 262144 # 128 Megabytes pe_start = 67584 pe_count = 23 # 92 Megabytes ea_start = 2048 ea_size = 65536 # 32 Megabytes } } The new metadata fields are "ea_start" and "ea_size". This is mostly useful when restoring the PV by using existing metadata backups (e.g. pvcreate --restorefile ...). New tools does not require these two fields to exist in VG metadata, they're not compulsory. Therefore, reading old VG metadata which doesn't contain any Embedding Area information will not end up with any kind of error but only a debug message that the ea_start and ea_size values were not found. Old tools just ignore these extra fields in VG metadata.
2013-02-14 19:04:35 +04:00
}
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
return 1;
}
int lvmcache_check_format(struct lvmcache_info *info, const struct format_type *fmt)
{
if (info->fmt != fmt) {
log_error("PV %s is a different format (seqno %s)",
dev_name(info->dev), info->fmt->name);
return 0;
}
return 1;
}
void lvmcache_del_mdas(struct lvmcache_info *info)
{
if (info->mdas.n)
del_mdas(&info->mdas);
dm_list_init(&info->mdas);
ability to keep track of bad mdas in lvmcache mda's that cannot be processed by lvm because of some corruption can be kept on a separate list. These will be used for more advanced repair in a subsequent commit.
2019-02-05 21:39:08 +03:00
if (info->bad_mdas.n)
del_mdas(&info->bad_mdas);
dm_list_init(&info->bad_mdas);
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
}
void lvmcache_del_das(struct lvmcache_info *info)
{
if (info->das.n)
del_das(&info->das);
dm_list_init(&info->das);
}
refactor: rename embedding area -> bootloader area
2013-05-28 14:37:22 +04:00
void lvmcache_del_bas(struct lvmcache_info *info)
pv_header_extension: add supporting infrastructure for PV header extension (flags & Embedding Area) PV header extension comes just beyond the existing PV header base: PV header base (existing): - uuid - device size - null-terminated list of Data Areas - null-terminater list of MetaData Areas PV header extension: - extension version - flags - null-terminated list of Embedding Areas This patch also adds "eas" (Embedding Areas) list to lvmcache (lvmcache_info) and it also adds support for common operations on the list (just like for already existing "das" - Data Areas list): - lvmcache_add_ea - lvmcache_update_eas - lvmcache_foreach_ea - lvmcache_del_eas Also, add ea_start and ea_size to struct physical_volume for processing PV Embedding Area location throughout the code (currently only one Embedding Area is supported, though the definition on disk allows for more if needed in the future...). Also, define FMT_EAS format flag to mark that the format actually supports Embedding Areas (currently format-text only).
2013-02-14 18:35:57 +04:00
{
refactor: rename embedding area -> bootloader area
2013-05-28 14:37:22 +04:00
if (info->bas.n)
del_bas(&info->bas);
dm_list_init(&info->bas);
pv_header_extension: add supporting infrastructure for PV header extension (flags & Embedding Area) PV header extension comes just beyond the existing PV header base: PV header base (existing): - uuid - device size - null-terminated list of Data Areas - null-terminater list of MetaData Areas PV header extension: - extension version - flags - null-terminated list of Embedding Areas This patch also adds "eas" (Embedding Areas) list to lvmcache (lvmcache_info) and it also adds support for common operations on the list (just like for already existing "das" - Data Areas list): - lvmcache_add_ea - lvmcache_update_eas - lvmcache_foreach_ea - lvmcache_del_eas Also, add ea_start and ea_size to struct physical_volume for processing PV Embedding Area location throughout the code (currently only one Embedding Area is supported, though the definition on disk allows for more if needed in the future...). Also, define FMT_EAS format flag to mark that the format actually supports Embedding Areas (currently format-text only).
2013-02-14 18:35:57 +04:00
}
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
int lvmcache_add_mda(struct lvmcache_info *info, struct device *dev,
add mda arg to add_mda Allow the caller of lvmcache_add_mda() to have the new mda returned.
2019-02-05 22:24:23 +03:00
uint64_t start, uint64_t size, unsigned ignored,
struct metadata_area **mda_new)
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
{
add mda arg to add_mda Allow the caller of lvmcache_add_mda() to have the new mda returned.
2019-02-05 22:24:23 +03:00
return add_mda(info->fmt, NULL, &info->mdas, dev, start, size, ignored, mda_new);
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
}
int lvmcache_add_da(struct lvmcache_info *info, uint64_t start, uint64_t size)
{
return add_da(NULL, &info->das, start, size);
}
refactor: rename embedding area -> bootloader area
2013-05-28 14:37:22 +04:00
int lvmcache_add_ba(struct lvmcache_info *info, uint64_t start, uint64_t size)
pv_header_extension: add supporting infrastructure for PV header extension (flags & Embedding Area) PV header extension comes just beyond the existing PV header base: PV header base (existing): - uuid - device size - null-terminated list of Data Areas - null-terminater list of MetaData Areas PV header extension: - extension version - flags - null-terminated list of Embedding Areas This patch also adds "eas" (Embedding Areas) list to lvmcache (lvmcache_info) and it also adds support for common operations on the list (just like for already existing "das" - Data Areas list): - lvmcache_add_ea - lvmcache_update_eas - lvmcache_foreach_ea - lvmcache_del_eas Also, add ea_start and ea_size to struct physical_volume for processing PV Embedding Area location throughout the code (currently only one Embedding Area is supported, though the definition on disk allows for more if needed in the future...). Also, define FMT_EAS format flag to mark that the format actually supports Embedding Areas (currently format-text only).
2013-02-14 18:35:57 +04:00
{
refactor: rename embedding area -> bootloader area
2013-05-28 14:37:22 +04:00
return add_ba(NULL, &info->bas, start, size);
pv_header_extension: add supporting infrastructure for PV header extension (flags & Embedding Area) PV header extension comes just beyond the existing PV header base: PV header base (existing): - uuid - device size - null-terminated list of Data Areas - null-terminater list of MetaData Areas PV header extension: - extension version - flags - null-terminated list of Embedding Areas This patch also adds "eas" (Embedding Areas) list to lvmcache (lvmcache_info) and it also adds support for common operations on the list (just like for already existing "das" - Data Areas list): - lvmcache_add_ea - lvmcache_update_eas - lvmcache_foreach_ea - lvmcache_del_eas Also, add ea_start and ea_size to struct physical_volume for processing PV Embedding Area location throughout the code (currently only one Embedding Area is supported, though the definition on disk allows for more if needed in the future...). Also, define FMT_EAS format flag to mark that the format actually supports Embedding Areas (currently format-text only).
2013-02-14 18:35:57 +04:00
}
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
void lvmcache_update_pv(struct lvmcache_info *info, struct physical_volume *pv,
const struct format_type *fmt)
{
info->device_size = pv->size << SECTOR_SHIFT;
info->fmt = fmt;
}
int lvmcache_update_das(struct lvmcache_info *info, struct physical_volume *pv)
{
struct data_area_list *da;
if (info->das.n) {
if (!pv->pe_start)
dm_list_iterate_items(da, &info->das)
pv->pe_start = da->disk_locn.offset >> SECTOR_SHIFT;
del_das(&info->das);
} else
dm_list_init(&info->das);
The lvmetad client-side integration. Only active when use_lvmetad = 1 is set in lvm.conf *and* lvmetad is running.
2012-02-23 17:11:07 +04:00
if (!add_da(NULL, &info->das, pv->pe_start << SECTOR_SHIFT, 0 /*pv->size << SECTOR_SHIFT*/))
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
return_0;
return 1;
}
refactor: rename embedding area -> bootloader area
2013-05-28 14:37:22 +04:00
int lvmcache_update_bas(struct lvmcache_info *info, struct physical_volume *pv)
pv_header_extension: add supporting infrastructure for PV header extension (flags & Embedding Area) PV header extension comes just beyond the existing PV header base: PV header base (existing): - uuid - device size - null-terminated list of Data Areas - null-terminater list of MetaData Areas PV header extension: - extension version - flags - null-terminated list of Embedding Areas This patch also adds "eas" (Embedding Areas) list to lvmcache (lvmcache_info) and it also adds support for common operations on the list (just like for already existing "das" - Data Areas list): - lvmcache_add_ea - lvmcache_update_eas - lvmcache_foreach_ea - lvmcache_del_eas Also, add ea_start and ea_size to struct physical_volume for processing PV Embedding Area location throughout the code (currently only one Embedding Area is supported, though the definition on disk allows for more if needed in the future...). Also, define FMT_EAS format flag to mark that the format actually supports Embedding Areas (currently format-text only).
2013-02-14 18:35:57 +04:00
{
refactor: rename embedding area -> bootloader area
2013-05-28 14:37:22 +04:00
struct data_area_list *ba;
if (info->bas.n) {
if (!pv->ba_start && !pv->ba_size)
dm_list_iterate_items(ba, &info->bas) {
pv->ba_start = ba->disk_locn.offset >> SECTOR_SHIFT;
pv->ba_size = ba->disk_locn.size >> SECTOR_SHIFT;
pv_header_extension: add supporting infrastructure for PV header extension (flags & Embedding Area) PV header extension comes just beyond the existing PV header base: PV header base (existing): - uuid - device size - null-terminated list of Data Areas - null-terminater list of MetaData Areas PV header extension: - extension version - flags - null-terminated list of Embedding Areas This patch also adds "eas" (Embedding Areas) list to lvmcache (lvmcache_info) and it also adds support for common operations on the list (just like for already existing "das" - Data Areas list): - lvmcache_add_ea - lvmcache_update_eas - lvmcache_foreach_ea - lvmcache_del_eas Also, add ea_start and ea_size to struct physical_volume for processing PV Embedding Area location throughout the code (currently only one Embedding Area is supported, though the definition on disk allows for more if needed in the future...). Also, define FMT_EAS format flag to mark that the format actually supports Embedding Areas (currently format-text only).
2013-02-14 18:35:57 +04:00
}
refactor: rename embedding area -> bootloader area
2013-05-28 14:37:22 +04:00
del_das(&info->bas);
pv_header_extension: add supporting infrastructure for PV header extension (flags & Embedding Area) PV header extension comes just beyond the existing PV header base: PV header base (existing): - uuid - device size - null-terminated list of Data Areas - null-terminater list of MetaData Areas PV header extension: - extension version - flags - null-terminated list of Embedding Areas This patch also adds "eas" (Embedding Areas) list to lvmcache (lvmcache_info) and it also adds support for common operations on the list (just like for already existing "das" - Data Areas list): - lvmcache_add_ea - lvmcache_update_eas - lvmcache_foreach_ea - lvmcache_del_eas Also, add ea_start and ea_size to struct physical_volume for processing PV Embedding Area location throughout the code (currently only one Embedding Area is supported, though the definition on disk allows for more if needed in the future...). Also, define FMT_EAS format flag to mark that the format actually supports Embedding Areas (currently format-text only).
2013-02-14 18:35:57 +04:00
} else
refactor: rename embedding area -> bootloader area
2013-05-28 14:37:22 +04:00
dm_list_init(&info->bas);
pv_header_extension: add supporting infrastructure for PV header extension (flags & Embedding Area) PV header extension comes just beyond the existing PV header base: PV header base (existing): - uuid - device size - null-terminated list of Data Areas - null-terminater list of MetaData Areas PV header extension: - extension version - flags - null-terminated list of Embedding Areas This patch also adds "eas" (Embedding Areas) list to lvmcache (lvmcache_info) and it also adds support for common operations on the list (just like for already existing "das" - Data Areas list): - lvmcache_add_ea - lvmcache_update_eas - lvmcache_foreach_ea - lvmcache_del_eas Also, add ea_start and ea_size to struct physical_volume for processing PV Embedding Area location throughout the code (currently only one Embedding Area is supported, though the definition on disk allows for more if needed in the future...). Also, define FMT_EAS format flag to mark that the format actually supports Embedding Areas (currently format-text only).
2013-02-14 18:35:57 +04:00
refactor: rename embedding area -> bootloader area
2013-05-28 14:37:22 +04:00
if (!add_ba(NULL, &info->bas, pv->ba_start << SECTOR_SHIFT, pv->ba_size << SECTOR_SHIFT))
pv_header_extension: add supporting infrastructure for PV header extension (flags & Embedding Area) PV header extension comes just beyond the existing PV header base: PV header base (existing): - uuid - device size - null-terminated list of Data Areas - null-terminater list of MetaData Areas PV header extension: - extension version - flags - null-terminated list of Embedding Areas This patch also adds "eas" (Embedding Areas) list to lvmcache (lvmcache_info) and it also adds support for common operations on the list (just like for already existing "das" - Data Areas list): - lvmcache_add_ea - lvmcache_update_eas - lvmcache_foreach_ea - lvmcache_del_eas Also, add ea_start and ea_size to struct physical_volume for processing PV Embedding Area location throughout the code (currently only one Embedding Area is supported, though the definition on disk allows for more if needed in the future...). Also, define FMT_EAS format flag to mark that the format actually supports Embedding Areas (currently format-text only).
2013-02-14 18:35:57 +04:00
return_0;
return 1;
}
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
int lvmcache_foreach_pv(struct lvmcache_vginfo *vginfo,
int (*fun)(struct lvmcache_info *, void *),
void *baton)
{
struct lvmcache_info *info;
dm_list_iterate_items(info, &vginfo->infos) {
if (!fun(info, baton))
return_0;
}
return 1;
}
int lvmcache_foreach_mda(struct lvmcache_info *info,
int (*fun)(struct metadata_area *, void *),
void *baton)
{
struct metadata_area *mda;
dm_list_iterate_items(mda, &info->mdas) {
if (!fun(mda, baton))
return_0;
}
return 1;
}
cleanup: preserve signesss and type size on return values
2013-02-05 19:43:16 +04:00
unsigned lvmcache_mda_count(struct lvmcache_info *info)
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
{
return dm_list_size(&info->mdas);
}
int lvmcache_foreach_da(struct lvmcache_info *info,
The lvmetad client-side integration. Only active when use_lvmetad = 1 is set in lvm.conf *and* lvmetad is running.
2012-02-23 17:11:07 +04:00
int (*fun)(struct disk_locn *, void *),
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
void *baton)
{
struct data_area_list *da;
dm_list_iterate_items(da, &info->das) {
The lvmetad client-side integration. Only active when use_lvmetad = 1 is set in lvm.conf *and* lvmetad is running.
2012-02-23 17:11:07 +04:00
if (!fun(&da->disk_locn, baton))
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
return_0;
}
return 1;
}
refactor: rename embedding area -> bootloader area
2013-05-28 14:37:22 +04:00
int lvmcache_foreach_ba(struct lvmcache_info *info,
pv_header_extension: add supporting infrastructure for PV header extension (flags & Embedding Area) PV header extension comes just beyond the existing PV header base: PV header base (existing): - uuid - device size - null-terminated list of Data Areas - null-terminater list of MetaData Areas PV header extension: - extension version - flags - null-terminated list of Embedding Areas This patch also adds "eas" (Embedding Areas) list to lvmcache (lvmcache_info) and it also adds support for common operations on the list (just like for already existing "das" - Data Areas list): - lvmcache_add_ea - lvmcache_update_eas - lvmcache_foreach_ea - lvmcache_del_eas Also, add ea_start and ea_size to struct physical_volume for processing PV Embedding Area location throughout the code (currently only one Embedding Area is supported, though the definition on disk allows for more if needed in the future...). Also, define FMT_EAS format flag to mark that the format actually supports Embedding Areas (currently format-text only).
2013-02-14 18:35:57 +04:00
int (*fun)(struct disk_locn *, void *),
void *baton)
{
refactor: rename embedding area -> bootloader area
2013-05-28 14:37:22 +04:00
struct data_area_list *ba;
dm_list_iterate_items(ba, &info->bas) {
if (!fun(&ba->disk_locn, baton))
pv_header_extension: add supporting infrastructure for PV header extension (flags & Embedding Area) PV header extension comes just beyond the existing PV header base: PV header base (existing): - uuid - device size - null-terminated list of Data Areas - null-terminater list of MetaData Areas PV header extension: - extension version - flags - null-terminated list of Embedding Areas This patch also adds "eas" (Embedding Areas) list to lvmcache (lvmcache_info) and it also adds support for common operations on the list (just like for already existing "das" - Data Areas list): - lvmcache_add_ea - lvmcache_update_eas - lvmcache_foreach_ea - lvmcache_del_eas Also, add ea_start and ea_size to struct physical_volume for processing PV Embedding Area location throughout the code (currently only one Embedding Area is supported, though the definition on disk allows for more if needed in the future...). Also, define FMT_EAS format flag to mark that the format actually supports Embedding Areas (currently format-text only).
2013-02-14 18:35:57 +04:00
return_0;
}
return 1;
}
pvremove: device check doesn't require label_read It just needs to check if the device was found during the scan, which means checking if it exists in lvmcache.
2018-02-09 21:43:12 +03:00
struct label *lvmcache_get_dev_label(struct device *dev)
{
struct lvmcache_info *info;
if ((info = lvmcache_info_from_pvid(dev->pvid, NULL, 0))) {
/* dev would be different for a duplicate */
if (info->dev == dev)
return info->label;
}
return NULL;
}
int lvmcache_has_dev_info(struct device *dev)
{
if (lvmcache_info_from_pvid(dev->pvid, NULL, 0))
return 1;
return 0;
}
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
/*
* The lifetime of the label returned is tied to the lifetime of the
* lvmcache_info which is the same as lvmcache itself.
*/
struct label *lvmcache_get_label(struct lvmcache_info *info) {
return info->label;
}
uint64_t lvmcache_device_size(struct lvmcache_info *info) {
return info->device_size;
}
void lvmcache_set_device_size(struct lvmcache_info *info, uint64_t size) {
info->device_size = size;
}
struct device *lvmcache_device(struct lvmcache_info *info) {
return info->dev;
}
lvmcache/lvmetad: cache PV extension version Store PV extension version in lvmcache/lvmetad for use throughout the code.
2016-02-11 18:25:36 +03:00
void lvmcache_set_ext_version(struct lvmcache_info *info, uint32_t version)
{
info->ext_version = version;
}
uint32_t lvmcache_ext_version(struct lvmcache_info *info) {
return info->ext_version;
}
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
lvmcache/lvmetad: cache PV extension flags Store PV extension flags in lvmcache/lvmetad for use throughout the code.
2015-03-09 14:52:07 +03:00
void lvmcache_set_ext_flags(struct lvmcache_info *info, uint32_t flags) {
info->ext_flags = flags;
}
uint32_t lvmcache_ext_flags(struct lvmcache_info *info) {
return info->ext_flags;
}
cleanup: preserve signesss and type size on return values
2013-02-05 19:43:16 +04:00
uint64_t lvmcache_smallest_mda_size(struct lvmcache_info *info)
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
{
pvs: fix segfaults with orphans Several fields used to display 0 if undefined. Recent changes to the way the fields are reported threw away some tests for valid pointers, leading to segfaults with 'pvs -o all'. Reinstate the original behaviour.
2014-01-14 07:17:27 +04:00
if (!info)
return UINT64_C(0);
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
return find_min_mda_size(&info->mdas);
}
const struct format_type *lvmcache_fmt(struct lvmcache_info *info) {
return info->fmt;
}
cache: Store metadata size and checksum. Refactor the recent metadata-reading optimisation patches. Remove the recently-added cache fields from struct labeller and struct format_instance. Instead, introduce struct lvmcache_vgsummary to wrap the VG information that lvmcache holds and add the metadata size and checksum to it. Allow this VG summary information to be looked up by metadata size + checksum. Adjust the debug log messages to make it clear when this shortcut has been successful. (This changes the optimisation slightly, and might be extendable further.) Add struct cached_vg_fmtdata to format-specific vg_read calls to preserve state alongside the VG across separate calls and indicate if the details supplied match, avoiding the need to read and process the VG metadata again.
2015-03-19 02:43:02 +03:00
int lvmcache_lookup_mda(struct lvmcache_vgsummary *vgsummary)
{
struct lvmcache_vginfo *vginfo;
if (!vgsummary->mda_size)
return 0;
/* FIXME Index the checksums */
dm_list_iterate_items(vginfo, &_vginfos) {
if (vgsummary->mda_checksum == vginfo->mda_checksum &&
vgsummary->mda_size == vginfo->mda_size &&
!is_orphan_vg(vginfo->vgname)) {
vgsummary->vgname = vginfo->vgname;
vgsummary->creation_host = vginfo->creation_host;
vgsummary->vgstatus = vginfo->status;
scan: skip device rescan in vg_read For reporting commands (pvs,vgs,lvs,pvdisplay,vgdisplay,lvdisplay) we do not need to repeat the label scan of devices in vg_read if they all had matching metadata in the initial label scan. The data read by label scan can just be reused for the vg_read. This cuts the amount of device i/o in half, from two reads of each device to one. We have to be careful to avoid repairing the VG if we've skipped rescanning. (The VG repair code is very poor, and will be redone soon.)
2018-04-19 00:29:42 +03:00
vgsummary->seqno = vginfo->seqno;
lvmcache: copy just 32bytes Copy only bytes which fits. vginfo->vgid is [ID_LEN + 1] vgsummary->vgid has only [ID_LEN] Reported by Coverity.
2015-05-07 12:28:22 +03:00
/* vginfo->vgid has 1 extra byte then vgsummary->vgid */
memcpy(&vgsummary->vgid, vginfo->vgid, sizeof(vgsummary->vgid));
cache: Store metadata size and checksum. Refactor the recent metadata-reading optimisation patches. Remove the recently-added cache fields from struct labeller and struct format_instance. Instead, introduce struct lvmcache_vgsummary to wrap the VG information that lvmcache holds and add the metadata size and checksum to it. Allow this VG summary information to be looked up by metadata size + checksum. Adjust the debug log messages to make it clear when this shortcut has been successful. (This changes the optimisation slightly, and might be extendable further.) Add struct cached_vg_fmtdata to format-specific vg_read calls to preserve state alongside the VG across separate calls and indicate if the details supplied match, avoiding the need to read and process the VG metadata again.
2015-03-19 02:43:02 +03:00
return 1;
}
}
return 0;
}
vgcreate: improve checks for existing global lock This tries harder to avoid creating duplicate global locks in sanlock VGs by refusing to create a new sanlock VG with a global lock if other sanlock VGs exist that may have a gl.
2015-07-24 18:06:58 +03:00
int lvmcache_contains_lock_type_sanlock(struct cmd_context *cmd)
{
struct lvmcache_vginfo *vginfo;
dm_list_iterate_items(vginfo, &_vginfos) {
if (vginfo->lock_type && !strcmp(vginfo->lock_type, "sanlock"))
return 1;
}
return 0;
}
pvscan: use process_each_pv The old code made two loops through the PVs: in the first loop it found the max PV and VG name lengths, and in the second loop it printed each PV using the name lengths as field widths for aligning columns. The new code uses process_each_pv() which makes one loop through the PVs. In the *first* call to pvscan_single(), the max name lengths are found by looping through the lvmcache entries which have been populated by the generic process_each code prior to calling any _single functions. Subsequent calls to pvscan_single() reuse the max lengths that were found by the first call.
2015-10-19 21:58:43 +03:00
void lvmcache_get_max_name_lengths(struct cmd_context *cmd,
unsigned *pv_max_name_len,
unsigned *vg_max_name_len)
{
struct lvmcache_vginfo *vginfo;
struct lvmcache_info *info;
unsigned len;
*vg_max_name_len = 0;
*pv_max_name_len = 0;
dm_list_iterate_items(vginfo, &_vginfos) {
len = strlen(vginfo->vgname);
if (*vg_max_name_len < len)
*vg_max_name_len = len;
dm_list_iterate_items(info, &vginfo->infos) {
len = strlen(dev_name(info->dev));
if (*pv_max_name_len < len)
*pv_max_name_len = len;
}
}
}
lvmcache: new function to check if VG is foreign When not using lvmetad, this uses the system_id field in the cached vginfo structs that are populated during a scan. When using lvmetad, this requests the VG from lvmetad, and checks the system_id field in the returned metadata.
2015-11-30 20:54:56 +03:00
int lvmcache_vg_is_foreign(struct cmd_context *cmd, const char *vgname, const char *vgid)
{
struct lvmcache_vginfo *vginfo;
int ret = 0;
if ((vginfo = lvmcache_vginfo_from_vgid(vgid)))
ret = !is_system_id_allowed(cmd, vginfo->system_id);
return ret;
}
scan: skip device rescan in vg_read For reporting commands (pvs,vgs,lvs,pvdisplay,vgdisplay,lvdisplay) we do not need to repeat the label scan of devices in vg_read if they all had matching metadata in the initial label scan. The data read by label scan can just be reused for the vg_read. This cuts the amount of device i/o in half, from two reads of each device to one. We have to be careful to avoid repairing the VG if we've skipped rescanning. (The VG repair code is very poor, and will be redone soon.)
2018-04-19 00:29:42 +03:00
/*
* Example of reading four devs in sequence from the same VG:
*
* dev1:
* lvmcache: creates vginfo with initial values
*
* dev2: all checksums match.
* mda_header checksum matches vginfo from dev1
* metadata checksum matches vginfo from dev1
* metadata is not parsed, and the vgsummary values copied
* from lvmcache from dev1 and passed back to lvmcache for dev2.
* lvmcache: attach info for dev2 to existing vginfo
*
* dev3: mda_header and metadata have unmatching checksums.
* mda_header checksum matches vginfo from dev1
* metadata checksum doesn't match vginfo from dev1
* produces read error in config.c
* lvmcache: info for dev3 is deleted, FIXME: use a defective state
*
* dev4: mda_header and metadata have matching checksums, but
* does not match checksum in lvmcache from prev dev.
* mda_header checksum doesn't match vginfo from dev1
* lvmcache_lookup_mda returns 0, no vgname, no checksum_only
* lvmcache: update_vgname_and_id sees checksum from dev4 does not
* match vginfo from dev1, so vginfo->scan_summary_mismatch is set.
* attach info for dev4 to existing vginfo
*
* dev5: config parsing error.
* lvmcache: info for dev5 is deleted, FIXME: use a defective state
*/
keep track of which mdas have old metadata in lvmcache This will be used for more advanced repair in a subsequent commit.
2019-02-05 22:09:56 +03:00
bool lvmcache_scan_mismatch(struct cmd_context *cmd, const char *vgname, const char *vgid)
scan: skip device rescan in vg_read For reporting commands (pvs,vgs,lvs,pvdisplay,vgdisplay,lvdisplay) we do not need to repeat the label scan of devices in vg_read if they all had matching metadata in the initial label scan. The data read by label scan can just be reused for the vg_read. This cuts the amount of device i/o in half, from two reads of each device to one. We have to be careful to avoid repairing the VG if we've skipped rescanning. (The VG repair code is very poor, and will be redone soon.)
2018-04-19 00:29:42 +03:00
{
struct lvmcache_vginfo *vginfo;
if (!vgname || !vgid)
keep track of which mdas have old metadata in lvmcache This will be used for more advanced repair in a subsequent commit.
2019-02-05 22:09:56 +03:00
return true;
scan: skip device rescan in vg_read For reporting commands (pvs,vgs,lvs,pvdisplay,vgdisplay,lvdisplay) we do not need to repeat the label scan of devices in vg_read if they all had matching metadata in the initial label scan. The data read by label scan can just be reused for the vg_read. This cuts the amount of device i/o in half, from two reads of each device to one. We have to be careful to avoid repairing the VG if we've skipped rescanning. (The VG repair code is very poor, and will be redone soon.)
2018-04-19 00:29:42 +03:00
if ((vginfo = lvmcache_vginfo_from_vgid(vgid)))
return vginfo->scan_summary_mismatch;
keep track of which mdas have old metadata in lvmcache This will be used for more advanced repair in a subsequent commit.
2019-02-05 22:09:56 +03:00
return true;
scan: skip device rescan in vg_read For reporting commands (pvs,vgs,lvs,pvdisplay,vgdisplay,lvdisplay) we do not need to repeat the label scan of devices in vg_read if they all had matching metadata in the initial label scan. The data read by label scan can just be reused for the vg_read. This cuts the amount of device i/o in half, from two reads of each device to one. We have to be careful to avoid repairing the VG if we've skipped rescanning. (The VG repair code is very poor, and will be redone soon.)
2018-04-19 00:29:42 +03:00
}
io: warn when metadata size approaches io memory size When a single copy of metadata gets within 1MB of the current io_memory_size value, begin printing a warning that the io_memory_size should be increased.
2019-03-04 21:13:09 +03:00
static uint64_t _max_metadata_size;
void lvmcache_save_metadata_size(uint64_t val)
{
if (!_max_metadata_size)
_max_metadata_size = val;
else if (_max_metadata_size < val)
_max_metadata_size = val;
}
uint64_t lvmcache_max_metadata_size(void)
{
return _max_metadata_size;
}
add device hints to reduce scanning Save the list of PVs in /run/lvm/hints. These hints are used to reduce scanning in a number of commands to only the PVs on the system, or only the PVs in a requested VG (rather than all devices on the system.)
2018-12-07 23:35:22 +03:00
int lvmcache_vginfo_has_pvid(struct lvmcache_vginfo *vginfo, char *pvid)
{
struct lvmcache_info *info;
dm_list_iterate_items(info, &vginfo->infos) {
if (!strcmp(info->dev->pvid, pvid))
return 1;
}
return 0;
}
pvck: new dump option to extract metadata The new command 'pvck --dump metadata PV' will extract the current version of VG metadata from a PV for testing and debugging. --dump metadata_area extracts the entire text metadata area.
2019-05-22 22:25:08 +03:00
keep track of which mdas have old metadata in lvmcache This will be used for more advanced repair in a subsequent commit.
2019-02-05 22:09:56 +03:00
/*
* This is used by the metadata repair command to check if
* the metadata on a dev needs repair because it's old.
*/
bool lvmcache_has_old_metadata(struct cmd_context *cmd, const char *vgname, const char *vgid, struct device *dev)
{
struct lvmcache_vginfo *vginfo;
struct lvmcache_info *info;
/* shouldn't happen */
if (!vgname || !vgid)
return false;
/* shouldn't happen */
if (!(vginfo = lvmcache_vginfo_from_vgid(vgid)))
return false;
/* shouldn't happen */
if (!(info = lvmcache_info_from_pvid(dev->pvid, NULL, 0)))
return false;
/* writing to a new PV */
if (!info->summary_seqno)
return false;
/* on same dev, one mda has newer metadata than the other */
if (info->summary_seqno_mismatch)
return true;
/* one or both mdas on this dev has older metadata than another dev */
if (vginfo->seqno > info->summary_seqno)
return true;
return false;
}
ability to keep track of outdated pvs in lvmcache Outdated PVs hold metadata for VG from which they have been removed. Add the ability to keep track of these in lvmcache. This will be used for more advanced repair in a subsequent commit.
2019-02-05 21:55:51 +03:00
void lvmcache_get_outdated_devs(struct cmd_context *cmd,
const char *vgname, const char *vgid,
struct dm_list *devs)
{
struct lvmcache_vginfo *vginfo;
struct lvmcache_info *info;
struct device_list *devl;
if (!(vginfo = lvmcache_vginfo_from_vgname(vgname, vgid))) {
log_error(INTERNAL_ERROR "lvmcache_get_outdated_devs no vginfo %s", vgname);
return;
}
dm_list_iterate_items(info, &vginfo->outdated_infos) {
lvmcache: fix memory leak With commit 0b18c25d934564015402de33e15a267045ed1b8c there was introduced 'zalloc()' for allocation of outdates pvs, but no matching 'free()' is present. Switch to use cmd mempool instead of adding free() code into several places.
2021-04-23 15:44:57 +03:00
if (!(devl = dm_pool_zalloc(cmd->mem, sizeof(*devl))))
ability to keep track of outdated pvs in lvmcache Outdated PVs hold metadata for VG from which they have been removed. Add the ability to keep track of these in lvmcache. This will be used for more advanced repair in a subsequent commit.
2019-02-05 21:55:51 +03:00
return;
devl->dev = info->dev;
dm_list_add(devs, &devl->list);
}
}
void lvmcache_del_outdated_devs(struct cmd_context *cmd,
const char *vgname, const char *vgid)
{
struct lvmcache_vginfo *vginfo;
struct lvmcache_info *info, *info2;
if (!(vginfo = lvmcache_vginfo_from_vgname(vgname, vgid))) {
reset cmd wipe_outdated_pvs at the start of a command, which is needed in case the cmd struct is reused.
2019-06-10 18:33:41 +03:00
log_error(INTERNAL_ERROR "lvmcache_del_outdated_devs no vginfo");
ability to keep track of outdated pvs in lvmcache Outdated PVs hold metadata for VG from which they have been removed. Add the ability to keep track of these in lvmcache. This will be used for more advanced repair in a subsequent commit.
2019-02-05 21:55:51 +03:00
return;
}
dm_list_iterate_items_safe(info, info2, &vginfo->outdated_infos)
lvmcache_del(info);
}
void lvmcache_get_outdated_mdas(struct cmd_context *cmd,
const char *vgname, const char *vgid,
struct device *dev,
struct dm_list **mdas)
{
struct lvmcache_vginfo *vginfo;
struct lvmcache_info *info;
*mdas = NULL;
if (!(vginfo = lvmcache_vginfo_from_vgname(vgname, vgid))) {
log_error(INTERNAL_ERROR "lvmcache_get_outdated_mdas no vginfo");
return;
}
dm_list_iterate_items(info, &vginfo->outdated_infos) {
if (info->dev != dev)
continue;
*mdas = &info->mdas;
return;
}
}
bool lvmcache_is_outdated_dev(struct cmd_context *cmd,
const char *vgname, const char *vgid,
struct device *dev)
{
struct lvmcache_vginfo *vginfo;
struct lvmcache_info *info;
if (!(vginfo = lvmcache_vginfo_from_vgname(vgname, vgid))) {
log_error(INTERNAL_ERROR "lvmcache_get_outdated_mdas no vginfo");
return false;
}
dm_list_iterate_items(info, &vginfo->outdated_infos) {
if (info->dev == dev)
return true;
}
return false;
}
devices: support printing the filter that rejects a device Use of this new message function needs to be added to various commands to improve the output.
2020-07-20 20:48:36 +03:00
const char *dev_filtered_reason(struct device *dev)
{
if (dev->filtered_flags & DEV_FILTERED_REGEX)
return "device is rejected by filter config";
if (dev->filtered_flags & DEV_FILTERED_INTERNAL)
return "device is restricted internally";
if (dev->filtered_flags & DEV_FILTERED_MD_COMPONENT)
return "device is an md component";
if (dev->filtered_flags & DEV_FILTERED_MPATH_COMPONENT)
return "device is a multipath component";
if (dev->filtered_flags & DEV_FILTERED_PARTITIONED)
return "device is partitioned";
if (dev->filtered_flags & DEV_FILTERED_SIGNATURE)
return "device has a signature";
if (dev->filtered_flags & DEV_FILTERED_SYSFS)
return "device is missing sysfs info";
if (dev->filtered_flags & DEV_FILTERED_DEVTYPE)
return "device type is unknown";
if (dev->filtered_flags & DEV_FILTERED_MINSIZE)
return "device is too small (pv_min_size)";
if (dev->filtered_flags & DEV_FILTERED_UNUSABLE)
return "device is not in a usable state";
device usage based on devices file The LVM devices file lists devices that lvm can use. The default file is /etc/lvm/devices/system.devices, and the lvmdevices(8) command is used to add or remove device entries. If the file does not exist, or if lvm.conf includes use_devicesfile=0, then lvm will not use a devices file. When the devices file is in use, the regex filter is not used, and the filter settings in lvm.conf or on the command line are ignored. LVM records devices in the devices file using hardware-specific IDs, such as the WWID, and attempts to use subsystem-specific IDs for virtual device types. These device IDs are also written in the VG metadata. When no hardware or virtual ID is available, lvm falls back using the unstable device name as the device ID. When devnames are used, lvm performs extra scanning to find devices if their devname changes, e.g. after reboot. When proper device IDs are used, an lvm command will not look at devices outside the devices file, but when devnames are used as a fallback, lvm will scan devices outside the devices file to locate PVs on renamed devices. A config setting search_for_devnames can be used to control the scanning for renamed devname entries. Related to the devices file, the new command option --devices <devnames> allows a list of devices to be specified for the command to use, overriding the devices file. The listed devices act as a sort of devices file in terms of limiting which devices lvm will see and use. Devices that are not listed will appear to be missing to the lvm command. Multiple devices files can be kept in /etc/lvm/devices, which allows lvm to be used with different sets of devices, e.g. system devices do not need to be exposed to a specific application, and the application can use lvm on its own set of devices that are not exposed to the system. The option --devicesfile <filename> is used to select the devices file to use with the command. Without the option set, the default system devices file is used. Setting --devicesfile "" causes lvm to not use a devices file. An existing, empty devices file means lvm will see no devices. The new command vgimportdevices adds PVs from a VG to the devices file and updates the VG metadata to include the device IDs. vgimportdevices -a will import all VGs into the system devices file. LVM commands run by dmeventd not use a devices file by default, and will look at all devices on the system. A devices file can be created for dmeventd (/etc/lvm/devices/dmeventd.devices) If this file exists, lvm commands run by dmeventd will use it. Internal implementaion: - device_ids_read - read the devices file . add struct dev_use (du) to cmd->use_devices for each devices file entry - dev_cache_scan - get /dev entries . add struct device (dev) to dev_cache for each device on the system - device_ids_match - match devices file entries to /dev entries . match each du on cmd->use_devices to a dev in dev_cache, using device ID . on match, set du->dev, dev->id, dev->flags MATCHED_USE_ID - label_scan - read lvm headers and metadata from devices . filters are applied, those that do not need data from the device . filter-deviceid skips devs without MATCHED_USE_ID, i.e. skips /dev entries that are not listed in the devices file . read lvm label from dev . filters are applied, those that use data from the device . read lvm metadata from dev . add info/vginfo structs for PVs/VGs (info is "lvmcache") - device_ids_find_renamed_devs - handle devices with unstable devname ID where devname changed . this step only needed when devs do not have proper device IDs, and their dev names change, e.g. after reboot sdb becomes sdc. . detect incorrect match because PVID in the devices file entry does not match the PVID found when the device was read above . undo incorrect match between du and dev above . search system devices for new location of PVID . update devices file with new devnames for PVIDs on renamed devices . label_scan the renamed devs - continue with command processing
2020-06-23 21:25:41 +03:00
if (dev->filtered_flags & DEV_FILTERED_DEVICES_FILE)
return "device is not in devices file";
if (dev->filtered_flags & DEV_FILTERED_DEVICES_LIST)
return "device is not in devices list";
filters: better message for excluding LV Make the generic "device is not usable" message from filter-usable more specific in case the device is not usable because it's an LV. (i.e. when scan_lvs=0)
2021-03-03 21:07:57 +03:00
if (dev->filtered_flags & DEV_FILTERED_IS_LV)
return "device is an LV";
devices: support printing the filter that rejects a device Use of this new message function needs to be added to various commands to improve the output.
2020-07-20 20:48:36 +03:00
/* flag has not been added here */
if (dev->filtered_flags)
return "device is filtered";
return "device cannot be used";
}
const char *devname_error_reason(const char *devname)
{
struct device *dev;
if ((dev = dev_hash_get(devname))) {
if (dev->filtered_flags)
return dev_filtered_reason(dev);
if (lvmcache_dev_is_unused_duplicate(dev))
return "device is a duplicate";
/* Avoid this case by adding by adding other more descriptive checks above. */
return "device cannot be used";
}
return "device not found";
}
Copy Permalink