2002-11-18 16:53:58 +03:00
/*
2008-01-30 17:00:02 +03:00
* Copyright ( C ) 2001 - 2004 Sistina Software , Inc . All rights reserved .
2011-08-11 21:24:23 +04:00
* Copyright ( C ) 2004 - 2011 Red Hat , Inc . All rights reserved .
2002-11-18 16:53:58 +03:00
*
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
2007-08-21 00:55:30 +04:00
* of the GNU Lesser General Public License v .2 .1 .
2004-03-30 23:35:44 +04:00
*
2007-08-21 00:55:30 +04:00
* You should have received a copy of the GNU Lesser General Public License
2004-03-30 23:35:44 +04:00
* along with this program ; if not , write to the Free Software Foundation ,
2016-01-21 13:49:46 +03:00
* Inc . , 51 Franklin Street , Fifth Floor , Boston , MA 02110 - 1301 USA
2002-11-18 16:53:58 +03:00
*/
2018-06-08 15:40:53 +03:00
# include "base/memory/zalloc.h"
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"
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"
2020-07-20 20:48:36 +03:00
# include "lib/filters/filter.h"
2003-01-07 00:10:43 +03:00
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 */
2013-05-28 14:37:22 +04:00
struct dm_list bas ; /* list head for bootloader areas */
2019-02-05 21:39:08 +03:00
struct dm_list bad_mdas ; /* list head for bad metadata areas */
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 */
2016-02-11 18:25:36 +03:00
uint32_t ext_version ; /* Extension version */
2015-03-09 14:52:07 +03:00
uint32_t ext_flags ; /* Extension flags */
2012-02-10 05:28:27 +04:00
uint32_t status ;
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 */
2019-02-05 22:09:56 +03:00
bool summary_seqno_mismatch ; /* two mdas on this dev has mismatching metadata */
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 ;
2012-02-10 05:28:27 +04:00
} ;
/* One per VG */
struct lvmcache_vginfo {
2020-01-28 20:47:37 +03:00
struct dm_list list ; /* _vginfos */
2012-02-10 05:28:27 +04:00
struct dm_list infos ; /* List head for lvmcache_infos */
2019-02-05 21:55:51 +03:00
struct dm_list outdated_infos ; /* vg_read moves info from infos to outdated_infos */
2019-09-26 19:27:38 +03:00
struct dm_list pvsummaries ; /* pv_list taken directly from vgsummary */
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 ;
2015-11-30 20:32:17 +03:00
char * system_id ;
2015-07-24 23:20:37 +03:00
char * lock_type ;
2015-03-19 02:43:02 +03:00
uint32_t mda_checksum ;
size_t mda_size ;
2020-08-28 20:48:40 +03:00
uint32_t seqno ;
2019-02-05 22:09:56 +03:00
bool scan_summary_mismatch ; /* vgsummary from devs had mismatching seqno or checksum */
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 */
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
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 ) .
*/
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 ;
2010-04-30 16:54:31 +04:00
static DM_LIST_INIT ( _vginfos ) ;
2019-08-01 21:50:04 +03:00
static DM_LIST_INIT ( _initial_duplicates ) ;
static DM_LIST_INIT ( _unused_duplicates ) ;
2003-07-05 02:34:56 +04:00
static int _vgs_locked = 0 ;
2018-12-07 23:35:22 +03:00
static int _found_duplicate_vgnames = 0 ;
2020-06-03 20:38:27 +03:00
static int _outdated_warning = 0 ;
2002-11-18 16:53:58 +03:00
2018-05-03 00:58:49 +03:00
int lvmcache_init ( struct cmd_context * cmd )
2002-11-18 16:53:58 +03:00
{
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 ;
2008-11-04 01:14:30 +03:00
dm_list_init ( & _vginfos ) ;
2019-08-01 21:50:04 +03:00
dm_list_init ( & _initial_duplicates ) ;
dm_list_init ( & _unused_duplicates ) ;
2002-11-18 16:53:58 +03:00
2021-03-07 17:33:50 +03:00
if ( ! ( _vgname_hash = dm_hash_create ( 127 ) ) )
2002-11-18 16:53:58 +03:00
return 0 ;
2021-03-07 17:33:50 +03:00
if ( ! ( _vgid_hash = dm_hash_create ( 126 ) ) )
2002-11-18 16:53:58 +03:00
return 0 ;
2021-03-07 17:33:50 +03:00
if ( ! ( _pvid_hash = dm_hash_create ( 125 ) ) )
2002-11-18 16:53:58 +03:00
return 0 ;
return 1 ;
}
2010-07-09 19:34:40 +04:00
void lvmcache_lock_vgname ( const char * vgname , int read_only __attribute__ ( ( unused ) ) )
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 + + ;
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 ) {
2016-01-22 13:13:00 +03:00
dev_size_seqno_inc ( ) ; /* invalidate all cached dev sizes */
}
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 ;
}
2019-08-01 23:04:10 +03:00
int lvmcache_found_duplicate_vgnames ( void )
{
return _found_duplicate_vgnames ;
}
2019-08-01 21:50:04 +03:00
bool lvmcache_has_duplicate_devs ( void )
2015-01-14 23:38:05 +03:00
{
2019-08-01 21:53:20 +03:00
if ( dm_list_empty ( & _unused_duplicates ) & & dm_list_empty ( & _initial_duplicates ) )
return false ;
return true ;
2015-01-14 23:38:05 +03:00
}
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 ;
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 ;
}
2019-08-01 21:50:04 +03:00
void lvmcache_del_dev_from_duplicates ( struct device * dev )
2016-05-13 00:19:57 +03:00
{
struct device_list * devl ;
2022-11-07 20:38:46 +03:00
if ( ( devl = device_list_find_dev ( & _initial_duplicates , dev ) ) ) {
2019-08-01 23:04:10 +03:00
log_debug_cache ( " delete dev from initial duplicates %s " , dev_name ( dev ) ) ;
dm_list_del ( & devl - > list ) ;
}
2022-11-07 20:38:46 +03:00
if ( ( devl = device_list_find_dev ( & _unused_duplicates , dev ) ) ) {
2019-08-01 21:58:14 +03:00
log_debug_cache ( " delete dev from unused duplicates %s " , dev_name ( dev ) ) ;
dm_list_del ( & devl - > list ) ;
2016-05-13 00:19:57 +03:00
}
}
2019-08-01 21:50:04 +03:00
static void _destroy_device_list ( struct dm_list * head )
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 ) ;
2018-06-08 15:40:53 +03:00
free ( devl ) ;
2016-06-06 23:20:55 +03:00
}
dm_list_init ( head ) ;
}
2016-05-13 00:19:57 +03:00
2019-02-05 21:39:08 +03:00
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 ) ;
}
2021-09-28 22:58:03 +03:00
void lvmcache_del_save_bad_mda ( struct lvmcache_info * info , int mda_num , int bad_mda_flag )
{
struct metadata_area * mda , * mda_safe ;
dm_list_iterate_items_safe ( mda , mda_safe , & info - > mdas ) {
if ( mda - > mda_num = = mda_num ) {
dm_list_del ( & mda - > list ) ;
mda - > bad_fields | = bad_mda_flag ;
lvmcache_save_bad_mda ( info , mda ) ;
break ;
}
}
}
2019-02-05 21:39:08 +03:00
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 ) ;
}
}
}
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 ) ;
}
}
}
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 ;
}
2008-05-19 23:49:56 +04:00
static void _vginfo_detach_info ( struct lvmcache_info * info )
{
2008-11-04 01:14:30 +03:00
if ( ! dm_list_empty ( & info - > list ) ) {
dm_list_del ( & info - > list ) ;
dm_list_init ( & info - > list ) ;
2008-05-19 23:49:56 +04:00
}
info - > vginfo = NULL ;
}
2020-01-28 20:47:37 +03:00
static struct lvmcache_vginfo * _search_vginfos_list ( const char * vgname , const char * vgid )
2003-07-05 02:34:56 +04:00
{
struct lvmcache_vginfo * vginfo ;
2002-11-18 16:53:58 +03:00
2020-01-28 20:47:37 +03:00
if ( vgid ) {
dm_list_iterate_items ( vginfo , & _vginfos ) {
2021-08-03 23:32:33 +03:00
if ( ! memcmp ( vgid , vginfo - > vgid , ID_LEN ) )
2006-04-12 21:54:11 +04:00
return vginfo ;
2020-01-28 20:47:37 +03:00
}
} else {
dm_list_iterate_items ( vginfo , & _vginfos ) {
if ( ! strcmp ( vgname , vginfo - > vgname ) )
return vginfo ;
}
}
return NULL ;
2002-11-18 16:53:58 +03:00
}
2021-08-03 23:32:33 +03:00
static struct lvmcache_vginfo * _vginfo_lookup ( const char * vgname , const char * vgid_arg )
2002-11-18 16:53:58 +03:00
{
2021-08-03 23:32:33 +03:00
char vgid [ ID_LEN + 1 ] __attribute__ ( ( aligned ( 8 ) ) ) = { 0 } ;
2003-07-05 02:34:56 +04:00
struct lvmcache_vginfo * vginfo ;
2002-11-18 16:53:58 +03:00
2021-08-03 23:32:33 +03:00
/* In case vgid is not null terminated */
if ( vgid_arg )
memcpy ( vgid , vgid_arg , ID_LEN ) ;
2020-01-28 20:47:37 +03:00
2021-08-03 23:32:33 +03:00
if ( vgid_arg ) {
if ( ( vginfo = dm_hash_lookup ( _vgid_hash , vgid ) ) ) {
2020-01-28 20:47:37 +03:00
if ( vgname & & strcmp ( vginfo - > vgname , vgname ) ) {
2022-01-06 19:15:16 +03:00
log_warn ( " WARNING: lookup found duplicate VGID %s for VGs %s and %s. " , vgid , vginfo - > vgname , vgname ) ;
if ( ( vginfo = dm_hash_lookup ( _vgname_hash , vgname ) ) ) {
if ( ! memcmp ( vginfo - > vgid , vgid , ID_LEN ) )
return vginfo ;
}
2020-01-28 20:47:37 +03:00
return NULL ;
}
return vginfo ;
} else {
/* lookup by vgid that doesn't exist */
return NULL ;
}
2014-03-18 13:24:32 +04:00
}
2002-11-18 16:53:58 +03:00
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 */
2020-10-02 23:22:25 +03:00
log_error ( INTERNAL_ERROR " vginfo_lookup %s has_duplicate_local_vgname. " , vgname ) ;
2020-01-28 20:47:37 +03:00
return NULL ;
}
return vginfo ;
}
}
2003-01-10 22:14:01 +03:00
2020-01-28 20:47:37 +03:00
if ( vgname & & _found_duplicate_vgnames ) {
2021-08-03 23:32:33 +03:00
if ( ( vginfo = _search_vginfos_list ( vgname , vgid [ 0 ] ? vgid : NULL ) ) ) {
2020-01-28 20:47:37 +03:00
if ( vginfo - > has_duplicate_local_vgname ) {
2020-10-02 23:22:25 +03:00
log_debug ( " vginfo_lookup %s has_duplicate_local_vgname return none. " , vgname ) ;
2020-01-28 20:47:37 +03:00
return NULL ;
}
return vginfo ;
}
2014-03-18 13:24:32 +04:00
}
2002-11-18 16:53:58 +03:00
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 ) ;
2002-11-18 16:53:58 +03:00
}
2012-02-10 05:28:27 +04:00
const char * lvmcache_vgname_from_vgid ( struct dm_pool * mem , const char * vgid )
2006-04-13 01:23:04 +04:00
{
struct lvmcache_vginfo * vginfo ;
2006-06-15 00:11:22 +04:00
const char * vgname = NULL ;
2006-04-13 01:23:04 +04:00
2012-02-10 05:28:27 +04:00
if ( ( vginfo = lvmcache_vginfo_from_vgid ( vgid ) ) )
2006-06-15 00:11:22 +04:00
vgname = vginfo - > vgname ;
if ( mem & & vgname )
return dm_pool_strdup ( mem , vgname ) ;
2006-04-13 01:23:04 +04:00
2006-06-15 00:11:22 +04:00
return vgname ;
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 ;
2020-01-28 20:47:37 +03:00
if ( _found_duplicate_vgnames ) {
if ( ! ( vginfo = _search_vginfos_list ( vgname , NULL ) ) )
2023-08-31 19:48:15 +03:00
return NULL ;
2020-01-28 20:47:37 +03:00
} else {
if ( ! ( vginfo = dm_hash_lookup ( _vgname_hash , vgname ) ) )
2023-08-31 19:48:15 +03:00
return NULL ;
2020-01-28 20:47:37 +03: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
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
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
}
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 .
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 .
2008-01-30 02:45:48 +03:00
*/
2021-08-03 23:32:33 +03:00
struct lvmcache_info * lvmcache_info_from_pvid ( const char * pvid_arg , struct device * dev , int valid_only )
2002-11-18 16:53:58 +03:00
{
2021-08-03 23:32:33 +03:00
char pvid [ ID_LEN + 1 ] __attribute__ ( ( aligned ( 8 ) ) ) = { 0 } ;
2003-07-05 02:34:56 +04:00
struct lvmcache_info * info ;
2002-11-18 16:53:58 +03:00
2021-08-03 23:32:33 +03:00
if ( ! _pvid_hash | | ! pvid_arg )
2002-11-18 16:53:58 +03:00
return NULL ;
2021-08-03 23:32:33 +03:00
/* For cases where pvid_arg is not null terminated. */
memcpy ( pvid , pvid_arg , ID_LEN ) ;
2003-01-10 22:14:01 +03:00
2021-08-03 23:32:33 +03:00
if ( ! ( info = dm_hash_lookup ( _pvid_hash , pvid ) ) )
2002-11-18 16:53:58 +03:00
return NULL ;
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. " ,
2021-08-03 23:32:33 +03:00
dev_name ( info - > dev ) , dev_name ( dev ) , pvid ) ;
2016-06-06 22:04:17 +03:00
return NULL ;
}
2002-11-18 16:53:58 +03:00
return info ;
}
2021-09-20 17:32:21 +03:00
struct lvmcache_info * lvmcache_info_from_pv_id ( const struct id * pv_id_arg , struct device * dev , int valid_only )
2021-08-03 23:32:33 +03:00
{
/*
* Since we know that lvmcache_info_from_pvid directly above
* does not assume pvid_arg is null - terminated , we make an
* exception here and cast a struct id to char * .
*/
2021-09-20 17:32:21 +03:00
return lvmcache_info_from_pvid ( ( const char * ) pv_id_arg , dev , valid_only ) ;
2021-08-03 23:32:33 +03:00
}
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 ;
}
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 ;
}
2021-08-03 23:32:33 +03:00
static uint64_t _get_pvsummary_size ( const char * pvid_arg )
2019-09-27 19:11:57 +03:00
{
2021-08-03 23:32:33 +03:00
char pvid [ ID_LEN + 1 ] __attribute__ ( ( aligned ( 8 ) ) ) = { 0 } ;
2019-09-27 19:11:57 +03:00
struct lvmcache_vginfo * vginfo ;
struct pv_list * pvl ;
2021-08-03 23:32:33 +03:00
/* In case pvid_arg is not null terminated. */
memcpy ( pvid , pvid_arg , ID_LEN ) ;
2019-09-27 19:11:57 +03:00
dm_list_iterate_items ( vginfo , & _vginfos ) {
dm_list_iterate_items ( pvl , & vginfo - > pvsummaries ) {
2021-08-03 23:32:33 +03:00
if ( ! memcmp ( pvid , & pvl - > pv - > id . uuid , ID_LEN ) )
2019-09-27 19:11:57 +03:00
return pvl - > pv - > size ;
}
}
return 0 ;
}
2021-08-03 23:32:33 +03:00
static const char * _get_pvsummary_device_hint ( const char * pvid_arg )
2019-09-27 19:34:55 +03:00
{
2021-08-03 23:32:33 +03:00
char pvid [ ID_LEN + 1 ] __attribute__ ( ( aligned ( 8 ) ) ) = { 0 } ;
2019-09-27 19:34:55 +03:00
struct lvmcache_vginfo * vginfo ;
struct pv_list * pvl ;
2021-08-03 23:32:33 +03:00
/* In case pvid_arg is not null terminated. */
memcpy ( pvid , pvid_arg , ID_LEN ) ;
2019-09-27 19:34:55 +03:00
dm_list_iterate_items ( vginfo , & _vginfos ) {
dm_list_iterate_items ( pvl , & vginfo - > pvsummaries ) {
2021-08-03 23:32:33 +03:00
if ( ! memcmp ( pvid , & pvl - > pv - > id . uuid , ID_LEN ) )
2019-09-27 19:34:55 +03:00
return pvl - > pv - > device_hint ;
}
}
return NULL ;
}
2021-08-03 23:32:33 +03:00
static const char * _get_pvsummary_device_id ( const char * pvid_arg , const char * * device_id_type )
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
{
2021-08-03 23:32:33 +03:00
char pvid [ ID_LEN + 1 ] __attribute__ ( ( aligned ( 8 ) ) ) = { 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
struct lvmcache_vginfo * vginfo ;
struct pv_list * pvl ;
2021-08-03 23:32:33 +03:00
/* In case pvid_arg is not null terminated. */
memcpy ( pvid , pvid_arg , ID_LEN ) ;
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_iterate_items ( vginfo , & _vginfos ) {
dm_list_iterate_items ( pvl , & vginfo - > pvsummaries ) {
2021-08-03 23:32:33 +03:00
if ( ! memcmp ( & pvid , & pvl - > pv - > id . uuid , ID_LEN ) ) {
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
* device_id_type = pvl - > pv - > device_id_type ;
return pvl - > pv - > device_id ;
}
}
}
return NULL ;
}
2021-11-05 20:19:35 +03:00
int lvmcache_pvsummary_count ( const char * vgname )
{
struct lvmcache_vginfo * vginfo ;
if ( ! ( vginfo = lvmcache_vginfo_from_vgname ( vgname , NULL ) ) )
return_0 ;
return dm_list_size ( & vginfo - > pvsummaries ) ;
}
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
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 ) {
2019-08-01 21:50:04 +03:00
dm_list_iterate_items ( devl , & _unused_duplicates ) {
2021-08-03 23:32:33 +03:00
if ( ! memcmp ( & pvl - > pv - > id . uuid , devl - > dev - > pvid , ID_LEN ) )
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 1 ;
}
}
return 0 ;
}
2019-08-01 21:50:04 +03:00
bool lvmcache_dev_is_unused_duplicate ( struct device * dev )
2016-06-06 23:20:55 +03:00
{
2022-11-07 20:38:46 +03:00
return device_list_find_dev ( & _unused_duplicates , dev ) ? true : false ;
2016-06-06 23:20:55 +03:00
}
2019-08-01 21:50:04 +03:00
static void _warn_unused_duplicates ( struct cmd_context * cmd )
2018-05-21 22:20:19 +03:00
{
2021-08-03 23:32:33 +03:00
char pvid_dashed [ 64 ] __attribute__ ( ( aligned ( 8 ) ) ) ;
2018-05-21 22:20:19 +03:00
struct lvmcache_info * info ;
2019-08-01 23:04:10 +03:00
struct device_list * devl ;
2021-08-03 23:32:33 +03:00
struct id id ;
2018-05-21 22:20:19 +03:00
2019-08-01 23:04:10 +03:00
dm_list_iterate_items ( devl , & _unused_duplicates ) {
2021-08-03 23:32:33 +03:00
memcpy ( & id , devl - > dev - > pvid , ID_LEN ) ;
if ( ! id_write_format ( & id , pvid_dashed , sizeof ( pvid_dashed ) ) )
2018-05-21 22:20:19 +03:00
stack ;
2021-08-03 23:32:33 +03:00
log_warn ( " WARNING: Not using device %s for PV %s. " , dev_name ( devl - > dev ) , pvid_dashed ) ;
2018-05-21 22:20:19 +03:00
}
2019-08-01 23:04:10 +03:00
dm_list_iterate_items ( devl , & _unused_duplicates ) {
2018-05-21 22:20:19 +03:00
/* info for the preferred device that we're actually using */
2018-06-01 18:15:48 +03:00
if ( ! ( info = lvmcache_info_from_pvid ( devl - > dev - > pvid , NULL , 0 ) ) )
continue ;
2018-05-21 22:20:19 +03:00
2021-08-03 23:32:33 +03:00
memcpy ( & id , info - > dev - > pvid , ID_LEN ) ;
if ( ! id_write_format ( & id , pvid_dashed , sizeof ( pvid_dashed ) ) )
2018-05-21 22:20:19 +03:00
stack ;
log_warn ( " WARNING: PV %s prefers device %s because %s. " ,
2021-08-03 23:32:33 +03:00
pvid_dashed , dev_name ( info - > dev ) , info - > dev - > duplicate_prefer_reason ) ;
2018-05-21 22:20:19 +03:00
}
2018-05-11 23:52:22 +03:00
}
2021-11-18 02:10:45 +03:00
static int _all_multipath_components ( struct cmd_context * cmd , struct lvmcache_info * info , const char * pvid ,
struct dm_list * altdevs , struct device * * dev_mpath )
{
struct device_list * devl ;
struct device * dev_mp = NULL ;
struct device * dev1 = NULL ;
struct device * dev ;
2022-09-21 20:15:13 +03:00
char wwid1_buf [ DEV_WWID_SIZE ] = { 0 } ;
char wwid_buf [ DEV_WWID_SIZE ] = { 0 } ;
2021-11-18 02:10:45 +03:00
const char * wwid1 = NULL ;
2022-09-21 20:15:13 +03:00
const char * wwid = NULL ;
2021-11-18 02:10:45 +03:00
int diff_wwid = 0 ;
int same_wwid = 0 ;
int dev_is_mp ;
* dev_mpath = NULL ;
2022-07-25 21:50:43 +03:00
if ( ! find_config_tree_bool ( cmd , devices_multipath_component_detection_CFG , NULL ) )
return 0 ;
2021-11-18 02:10:45 +03:00
/* This function only makes sense with more than one dev. */
if ( ( info & & dm_list_empty ( altdevs ) ) | | ( ! info & & ( dm_list_size ( altdevs ) = = 1 ) ) ) {
log_debug ( " Skip multipath component checks with single device for PVID %s " , pvid ) ;
return 0 ;
}
log_debug ( " Checking for multipath components for duplicate PVID %s " , pvid ) ;
if ( info ) {
dev = info - > dev ;
dev_is_mp = ( cmd - > dev_types - > device_mapper_major = = MAJOR ( dev - > dev ) ) & & dev_has_mpath_uuid ( cmd , dev , NULL ) ;
2022-09-21 20:15:13 +03:00
/*
* dev_mpath_component_wwid allocates wwid from dm_pool ,
* device_id_system_read does not and needs free .
*/
2021-11-18 02:10:45 +03:00
if ( dev_is_mp ) {
if ( ( wwid1 = dev_mpath_component_wwid ( cmd , dev ) ) ) {
2022-12-01 19:03:06 +03:00
strncpy ( wwid1_buf , wwid1 , DEV_WWID_SIZE - 1 ) ;
2021-11-18 02:10:45 +03:00
dev_mp = dev ;
dev1 = dev ;
}
} else {
2022-09-21 20:15:13 +03:00
if ( ( wwid1 = device_id_system_read ( cmd , dev , DEV_ID_TYPE_SYS_WWID ) ) ) {
2022-12-01 19:03:06 +03:00
strncpy ( wwid1_buf , wwid1 , DEV_WWID_SIZE - 1 ) ;
2022-09-21 20:15:13 +03:00
free ( ( char * ) wwid1 ) ;
2021-11-18 02:10:45 +03:00
dev1 = dev ;
2022-09-21 20:15:13 +03:00
}
2021-11-18 02:10:45 +03:00
}
}
dm_list_iterate_items ( devl , altdevs ) {
dev = devl - > dev ;
dev_is_mp = ( cmd - > dev_types - > device_mapper_major = = MAJOR ( dev - > dev ) ) & & dev_has_mpath_uuid ( cmd , dev , NULL ) ;
2022-09-21 20:15:13 +03:00
if ( dev_is_mp ) {
if ( ( wwid = dev_mpath_component_wwid ( cmd , dev ) ) )
2022-12-01 19:03:06 +03:00
strncpy ( wwid_buf , wwid , DEV_WWID_SIZE - 1 ) ;
2022-09-21 20:15:13 +03:00
} else {
if ( ( wwid = device_id_system_read ( cmd , dev , DEV_ID_TYPE_SYS_WWID ) ) ) {
2022-12-01 19:03:06 +03:00
strncpy ( wwid_buf , wwid , DEV_WWID_SIZE - 1 ) ;
2022-09-21 20:15:13 +03:00
free ( ( char * ) wwid ) ;
}
}
2021-11-18 02:10:45 +03:00
2022-09-21 20:15:13 +03:00
if ( ! wwid_buf [ 0 ] & & wwid1_buf [ 0 ] ) {
2021-11-23 00:10:43 +03:00
log_debug ( " Different wwids for duplicate PVs %s %s %s none " ,
2022-09-21 20:15:13 +03:00
dev_name ( dev1 ) , wwid1_buf , dev_name ( dev ) ) ;
2021-11-18 02:10:45 +03:00
diff_wwid + + ;
continue ;
}
2022-09-21 20:15:13 +03:00
if ( ! wwid_buf [ 0 ] )
2021-11-18 02:10:45 +03:00
continue ;
2022-09-21 20:15:13 +03:00
if ( ! wwid1_buf [ 0 ] ) {
2022-12-01 19:03:06 +03:00
memcpy ( wwid1_buf , wwid_buf , DEV_WWID_SIZE - 1 ) ;
2021-11-18 02:10:45 +03:00
dev1 = dev ;
continue ;
}
/* Different wwids indicates these are not multipath components. */
2022-09-21 20:15:13 +03:00
if ( strcmp ( wwid1_buf , wwid_buf ) ) {
2021-11-23 00:10:43 +03:00
log_debug ( " Different wwids for duplicate PVs %s %s %s %s " ,
2022-09-21 20:15:13 +03:00
dev_name ( dev1 ) , wwid1_buf , dev_name ( dev ) , wwid_buf ) ;
2021-11-18 02:10:45 +03:00
diff_wwid + + ;
continue ;
}
/* Different mpath devs with the same wwid shouldn't happen. */
if ( dev_is_mp & & dev_mp ) {
2023-04-26 15:40:11 +03:00
log_print_unless_silent ( " Found multiple multipath devices for PVID %s WWID %s: %s %s. " ,
pvid , wwid1_buf , dev_name ( dev_mp ) , dev_name ( dev ) ) ;
2021-11-18 02:10:45 +03:00
continue ;
}
log_debug ( " Same wwids for duplicate PVs %s %s " , dev_name ( dev1 ) , dev_name ( dev ) ) ;
same_wwid + + ;
/* Save the mpath device so it can be used as the PV. */
if ( dev_is_mp )
dev_mp = dev ;
}
if ( diff_wwid | | ! same_wwid )
return 0 ;
if ( dev_mp )
2022-09-21 20:15:13 +03:00
log_debug ( " Found multipath device %s for PVID %s WWID %s. " , dev_name ( dev_mp ) , pvid , wwid1_buf ) ;
2021-11-18 02:10:45 +03:00
* dev_mpath = dev_mp ;
return 1 ;
}
2021-11-23 00:10:43 +03:00
static int _all_md_components ( struct cmd_context * cmd , struct lvmcache_info * info , const char * pvid ,
struct dm_list * altdevs , struct device * * dev_md_out )
{
struct device_list * devl ;
struct device * dev_md = NULL ;
struct device * dev ;
int real_dup = 0 ;
* dev_md_out = NULL ;
/* There will often be no info struct because of the extra_md_checks function. */
if ( info & & ( cmd - > dev_types - > md_major = = MAJOR ( info - > dev - > dev ) ) )
dev_md = info - > dev ;
dm_list_iterate_items ( devl , altdevs ) {
dev = devl - > dev ;
if ( cmd - > dev_types - > md_major = = MAJOR ( dev - > dev ) ) {
if ( dev_md ) {
/* md devs themselves are dups */
log_debug ( " Found multiple md devices for PVID %s: %s %s " ,
pvid , dev_name ( dev_md ) , dev_name ( dev ) ) ;
real_dup = 1 ;
break ;
} else
dev_md = dev ;
} else {
if ( ! dev_is_md_component ( cmd , dev , NULL , 1 ) ) {
/* md dev copied to another device */
real_dup = 1 ;
break ;
}
}
}
if ( real_dup )
return 0 ;
if ( dev_md )
log_debug ( " Found md device %s for PVID %s. " , dev_name ( dev_md ) , pvid ) ;
* dev_md_out = dev_md ;
return 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
/*
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
*
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
*
2019-08-01 21:50:04 +03:00
* _unused_duplicates : duplicate devs not chosen to be used .
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
*/
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
{
2021-08-03 23:32:33 +03:00
const char * pvid ;
2016-10-03 14:04:16 +03:00
const char * reason ;
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 ;
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 ;
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 ;
2021-11-23 00:10:43 +03:00
struct device * dev_mpath , * dev_md ;
2021-11-18 02:10:45 +03:00
struct device * dev_drop ;
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 ;
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 ;
2016-03-29 21:29:39 +03:00
int has_lv1 , has_lv2 ;
2019-09-27 19:11:57 +03:00
int same_size1 , same_size2 ;
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: 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 ;
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 ) ;
2019-08-01 23:04:10 +03:00
pvid = NULL ;
2021-11-18 02:10:45 +03:00
dev_mpath = NULL ;
2021-11-23 00:10:43 +03:00
dev_md = 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
2019-08-01 21:50:04 +03:00
dm_list_iterate_items_safe ( devl , devl_safe , & _initial_duplicates ) {
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 ) ;
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 {
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 ) ;
}
}
2019-08-01 23:04:10 +03:00
/* done, no more entries to process */
if ( ! pvid ) {
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 ;
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
2021-11-18 02:10:45 +03:00
info = lvmcache_info_from_pvid ( pvid , NULL , 0 ) ;
2019-08-01 23:04:10 +03:00
/*
2021-11-18 02:10:45 +03:00
* Usually and ideally , components of md and multipath devs should have
* been excluded by filters , and not scanned for a PV . In some unusual
* cases the components can get through the filters , and a PV can be
* found on them . Detecting the same PVID on both the component and
* the md / mpath device gives us a last chance to drop the component .
* An md / mpath component device is completely ignored , as if it had
* been filtered , and not kept in the list unused duplicates .
2021-11-23 00:10:43 +03:00
*
* One issue related to eliminating mpath / md duplicate PVs here is
* that it occurs after label_scan , and hints are created based
* on what label_scan finds , so hints are disabled due to duplicate
* PVs that are later resolved here .
2019-08-01 23:04:10 +03:00
*/
2021-11-18 02:10:45 +03:00
/*
* Get rid of multipath components based on matching wwids .
*/
if ( _all_multipath_components ( cmd , info , pvid , & altdevs , & dev_mpath ) ) {
if ( info & & dev_mpath & & ( info - > dev ! = dev_mpath ) ) {
/*
* info should be dropped from lvmcache and info - > dev
* should be treated as if it had been excluded by a filter .
* dev_mpath should be added to lvmcache by the caller .
*/
dev_drop = info - > dev ;
/* Have caller add dev_mpath to lvmcache. */
log_debug ( " Using multipath device %s for PVID %s. " , dev_name ( dev_mpath ) , pvid ) ;
if ( ( devl_add = zalloc ( sizeof ( * devl_add ) ) ) ) {
devl_add - > dev = dev_mpath ;
dm_list_add ( add_cache_devs , & devl_add - > list ) ;
}
/* Remove dev_mpath from altdevs. */
2024-04-04 01:54:48 +03:00
if ( ( devl = device_list_find_dev ( & altdevs , dev_mpath ) ) ) {
2021-11-18 02:10:45 +03:00
dm_list_del ( & devl - > list ) ;
2024-04-04 01:54:48 +03:00
free ( devl ) ;
}
2021-11-18 02:10:45 +03:00
/* Remove info from lvmcache that came from the component dev. */
log_debug ( " Ignoring multipath component %s with PVID %s (dropping info) " , dev_name ( dev_drop ) , pvid ) ;
lvmcache_del ( info ) ;
info = NULL ;
/* Make the component dev look like it was filtered. */
cmd - > filter - > wipe ( cmd , cmd - > filter , dev_drop , NULL ) ;
dev_drop - > flags & = ~ DEV_SCAN_FOUND_LABEL ;
}
if ( info & & ! dev_mpath ) {
/*
* Only mpath component devs were found and no actual
* multipath dev , so drop the component from lvmcache .
*/
dev_drop = info - > dev ;
log_debug ( " Ignoring multipath component %s with PVID %s (dropping info) " , dev_name ( dev_drop ) , pvid ) ;
lvmcache_del ( info ) ;
info = NULL ;
/* Make the component dev look like it was filtered. */
cmd - > filter - > wipe ( cmd , cmd - > filter , dev_drop , NULL ) ;
dev_drop - > flags & = ~ DEV_SCAN_FOUND_LABEL ;
}
dm_list_iterate_items_safe ( devl , devl_safe , & altdevs ) {
/*
* The altdevs are all mpath components that should look
* like they were filtered , they are not in lvmcache .
*/
dev_drop = devl - > dev ;
log_debug ( " Ignoring multipath component %s with PVID %s (dropping duplicate) " , dev_name ( dev_drop ) , pvid ) ;
dm_list_del ( & devl - > list ) ;
2024-04-04 01:54:48 +03:00
free ( devl ) ;
2021-11-18 02:10:45 +03:00
cmd - > filter - > wipe ( cmd , cmd - > filter , dev_drop , NULL ) ;
dev_drop - > flags & = ~ DEV_SCAN_FOUND_LABEL ;
}
goto next ;
}
/*
* Get rid of any md components .
*/
2021-11-23 00:10:43 +03:00
if ( _all_md_components ( cmd , info , pvid , & altdevs , & dev_md ) ) {
if ( info & & dev_md & & ( info - > dev ! = dev_md ) ) {
/*
* info should be dropped from lvmcache and info - > dev
* should be treated as if it had been excluded by a filter .
* dev_md should be added to lvmcache by the caller .
* Often this info struct has been removed by
* lvmcache_extra_md_component_checks .
*/
dev_drop = info - > dev ;
2019-08-01 23:04:10 +03:00
2021-11-23 00:10:43 +03:00
/* Have caller add dev_md to lvmcache. */
log_debug ( " Using md device %s for PVID %s. " , dev_name ( dev_md ) , pvid ) ;
if ( ( devl_add = zalloc ( sizeof ( * devl_add ) ) ) ) {
devl_add - > dev = dev_md ;
dm_list_add ( add_cache_devs , & devl_add - > list ) ;
}
/* Remove dev_md from altdevs. */
2024-04-04 01:54:48 +03:00
if ( ( devl = device_list_find_dev ( & altdevs , dev_md ) ) ) {
2021-11-23 00:10:43 +03:00
dm_list_del ( & devl - > list ) ;
2024-04-04 01:54:48 +03:00
free ( devl ) ;
}
2021-11-23 00:10:43 +03:00
/* Remove info from lvmcache that came from the component dev. */
log_debug ( " Ignoring md component %s with PVID %s (dropping info) " , dev_name ( dev_drop ) , pvid ) ;
lvmcache_del ( info ) ;
info = NULL ;
/* Make the component dev look like it was filtered. */
cmd - > filter - > wipe ( cmd , cmd - > filter , dev_drop , NULL ) ;
dev_drop - > flags & = ~ DEV_SCAN_FOUND_LABEL ;
2019-08-01 23:04:10 +03:00
}
2021-11-23 00:10:43 +03:00
if ( ! info & & dev_md ) {
/*
* The info struct was from a component and was dropped
* and the actual md dev was found on initial_duplicates
* and the caller should add it to lvmcache .
*/
/* Have caller add dev_md to lvmcache. */
log_debug ( " Using md device %s for PVID %s. " , dev_name ( dev_md ) , pvid ) ;
if ( ( devl_add = zalloc ( sizeof ( * devl_add ) ) ) ) {
devl_add - > dev = dev_md ;
dm_list_add ( add_cache_devs , & devl_add - > list ) ;
}
/* Remove dev_md from altdevs. */
2024-04-04 01:54:48 +03:00
if ( ( devl = device_list_find_dev ( & altdevs , dev_md ) ) ) {
2021-11-23 00:10:43 +03:00
dm_list_del ( & devl - > list ) ;
2024-04-04 01:54:48 +03:00
free ( devl ) ;
}
2021-11-23 00:10:43 +03:00
}
if ( info & & ! dev_md ) {
/*
* Only md component devs were found and no actual
* md dev , so drop the component from lvmcache .
*/
dev_drop = info - > dev ;
log_debug ( " Ignoring md component %s with PVID %s (dropping info) " , dev_name ( dev_drop ) , pvid ) ;
lvmcache_del ( info ) ;
info = NULL ;
/* Make the component dev look like it was filtered. */
cmd - > filter - > wipe ( cmd , cmd - > filter , dev_drop , NULL ) ;
dev_drop - > flags & = ~ DEV_SCAN_FOUND_LABEL ;
}
dm_list_iterate_items_safe ( devl , devl_safe , & altdevs ) {
/*
* The altdevs are all md components that should look
* like they were filtered , they are not in lvmcache .
*/
dev_drop = devl - > dev ;
log_debug ( " Ignoring md component %s with PVID %s (dropping duplicate) " , dev_name ( dev_drop ) , pvid ) ;
dm_list_del ( & devl - > list ) ;
2024-04-04 01:54:48 +03:00
free ( devl ) ;
2021-11-23 00:10:43 +03:00
cmd - > filter - > wipe ( cmd , cmd - > filter , dev_drop , NULL ) ;
dev_drop - > flags & = ~ DEV_SCAN_FOUND_LABEL ;
}
2019-08-01 23:04:10 +03:00
goto next ;
2021-11-23 00:10:43 +03:00
}
2019-08-01 23:04:10 +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 the device for the pvid that ' s currently in lvmcache .
*/
2019-08-01 23:04:10 +03:00
if ( ! ( info = lvmcache_info_from_pvid ( pvid , NULL , 0 ) ) ) {
2019-05-21 20:06:34 +03:00
/*
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 .
2019-05-21 20:06:34 +03:00
*/
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 ;
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 ;
dev1_major = MAJOR ( dev1 - > dev ) ;
dev1_minor = MINOR ( dev1 - > dev ) ;
dev2_major = MAJOR ( dev2 - > dev ) ;
dev2_minor = MINOR ( dev2 - > dev ) ;
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 ;
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 ) ;
2019-09-27 19:11:57 +03:00
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 ) ;
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 ) ;
2019-09-27 19:34:55 +03:00
log_debug_cache ( " PV %s compare duplicates: %s %u:%u. %s %u:%u. device_hint %s. " ,
2016-03-29 21:29:39 +03:00
devl - > dev - > pvid ,
dev_name ( dev1 ) , dev1_major , dev1_minor ,
2019-09-27 19:34:55 +03:00
dev_name ( dev2 ) , dev2_major , dev2_minor ,
device_hint ? : " none " ) ;
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 ? : " . " ) ;
2019-09-27 19:11:57 +03:00
log_debug_cache ( " PV %s: size %llu. %s is %llu. %s is %llu. " ,
devl - > dev - > pvid ,
2019-10-21 13:32:11 +03:00
( unsigned long long ) pvsummary_size ,
2019-09-27 19:11:57 +03:00
dev_name ( dev1 ) , ( unsigned long long ) dev1_size ,
dev_name ( dev2 ) , ( unsigned long long ) dev2_size ) ;
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
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 ;
2024-04-26 22:13:46 +03:00
if ( same_id1 & & ! same_id2 ) {
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
/* keep 1 */
reason = " device id " ;
} else if ( same_id2 & & ! same_id1 ) {
/* change to 2 */
change = 1 ;
reason = " device id " ;
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 */
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 " ;
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 " ;
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 " ;
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 ;
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 */
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 ;
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 */
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 ;
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
}
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 ;
2018-05-21 22:20:19 +03:00
dev1 - > duplicate_prefer_reason = reason ;
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
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 ) ) ;
2022-11-07 20:38:46 +03:00
if ( ! ( devl_add = device_list_find_dev ( & altdevs , dev1 ) ) ) {
2019-08-01 23:04:10 +03:00
/* 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
/*
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
*/
2022-11-07 20:38:46 +03:00
if ( ! ( devl_add = device_list_find_dev ( & altdevs , dev1 ) ) ) {
2019-08-01 23:04:10 +03:00
/* 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
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
}
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 {
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
}
/*
2019-08-01 23:04:10 +03:00
* Any altdevs entries not chosen are moved to _unused_duplicates .
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 .
*/
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 ;
}
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
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 .
2018-02-07 22:14:08 +03:00
*/
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 )
2018-02-07 22:14:08 +03:00
{
struct dm_list devs ;
2018-05-14 21:38:16 +03:00
struct device_list * devl , * devl2 ;
2018-05-03 00:58:49 +03:00
struct lvmcache_vginfo * vginfo ;
2018-05-14 21:45:55 +03:00
struct lvmcache_info * info ;
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 ) {
2018-06-08 15:40:53 +03:00
if ( ! ( devl = malloc ( sizeof ( * devl ) ) ) ) {
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 ) ;
}
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 ) ;
2018-02-07 22:14:08 +03:00
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 ) ;
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 ) ;
2018-02-07 22:14:08 +03:00
2018-05-14 21:38:16 +03:00
dm_list_iterate_items_safe ( devl , devl2 , & devs ) {
dm_list_del ( & devl - > list ) ;
2018-06-08 15:40:53 +03:00
free ( devl ) ;
2018-05-14 21:38:16 +03:00
}
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 ;
}
2018-02-07 22:14:08 +03:00
return 1 ;
}
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 ) ;
}
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 ;
}
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 .
2021-11-23 00:10:43 +03:00
*
* It might be nice to do this checking in the filter ( when passes_filter is
* called after the initial read ) , but that doesn ' t work because passes_filter
* is called before _text_read so metadata / pvsummary info is not yet available
* which this function uses .
*
* The unique value of this function is that it can eliminate md components
* without there being duplicate PVs . But , there will often be duplicate PVs ,
* handled by _all_md_components ( ) , where other devs with the same pvid will be
* in _initial_duplicates . One could be the md device itself which will be
* added to lvmcache by choose_duplicates , and other duplicates that are
* components will be dropped .
2021-02-06 01:16:03 +03:00
*/
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 ;
2021-02-08 20:23:42 +03:00
int do_check_size , do_check_name ;
int md_check_start ;
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 | |
2021-02-08 20:23:42 +03:00
! strcmp ( cmd - > md_component_checks , " none " ) )
2021-02-06 01:16:03 +03:00
return ;
2021-02-08 20:23:42 +03:00
md_check_start = ! strcmp ( cmd - > md_component_checks , " start " ) ;
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 ) {
2023-04-25 22:46:36 +03:00
char vgid [ ID_LEN + 1 ] __attribute__ ( ( aligned ( 8 ) ) ) = { 0 } ;
memcpy ( vgid , vginfo - > vgid , ID_LEN ) ;
2021-02-06 01:16:03 +03:00
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 ;
2021-02-08 20:23:42 +03:00
do_check_size = 0 ;
do_check_name = 0 ;
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 ) )
2021-02-08 20:23:42 +03:00
do_check_size = 1 ;
2021-11-23 00:10:43 +03:00
if ( device_hint & & ! strncmp ( device_hint , " /dev/md " , 7 ) & &
( MAJOR ( info - > dev - > dev ) ! = cmd - > dev_types - > md_major ) )
2021-02-08 20:23:42 +03:00
do_check_name = 1 ;
if ( ! do_check_size & & ! do_check_name )
continue ;
2021-02-06 01:16:03 +03:00
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 " ,
2021-02-06 01:16:03 +03:00
( unsigned long long ) pvsize , ( unsigned long long ) devsize ,
device_hint ? : " none " , dev_name ( dev ) ) ;
2021-02-08 20:23:42 +03:00
continue ;
}
2021-02-06 01:16:03 +03:00
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 ) ) {
2021-11-23 00:10:43 +03:00
log_debug ( " Ignoring PV from md component %s with PVID %s (metadata %s %llu) " ,
dev_name ( dev ) , dev - > pvid , device_hint ? : " none " , ( unsigned long long ) pvsize ) ;
2021-02-08 20:23:42 +03:00
dev - > flags & = ~ DEV_SCAN_FOUND_LABEL ;
/* lvmcache_del will also delete vginfo if info was last one */
lvmcache_del ( info ) ;
cmd - > filter - > wipe ( cmd , cmd - > filter , dev , NULL ) ;
2023-04-25 22:46:36 +03:00
/* If vginfo was deleted don't continue using vginfo->infos */
if ( ! _search_vginfos_list ( NULL , vgid ) )
break ;
2021-02-06 01:16:03 +03:00
}
}
}
}
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 .
*/
2015-12-01 23:09:01 +03:00
int lvmcache_label_scan ( struct cmd_context * cmd )
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 ;
struct lvmcache_info * info ;
struct device_list * devl ;
2002-11-18 16:53:58 +03:00
2021-02-06 01:16:03 +03:00
log_debug_cache ( " lvmcache label scan begin " ) ;
2018-04-06 21:05:17 +03:00
2016-06-06 23:20:55 +03:00
/*
2019-08-01 23:04:10 +03:00
* Duplicates found during this label scan are added to _initial_duplicates .
2016-06-06 23:20:55 +03:00
*/
2019-08-01 21:50:04 +03:00
_destroy_device_list ( & _initial_duplicates ) ;
2019-08-01 23:04:10 +03:00
_destroy_device_list ( & _unused_duplicates ) ;
2016-06-06 23:20:55 +03:00
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 .
*/
2022-07-06 01:08:00 +03:00
if ( ! label_scan ( cmd ) )
return_0 ;
2015-12-11 23:02:36 +03:00
2022-11-01 00:14:01 +03:00
/*
* device_ids_validate ( ) found devices using a sys_serial device id
* which had a PVID on disk that did not match the PVID in the devices
* file . Serial numbers may not always be unique , so any device with
* the same serial number is found and searched for the correct PVID .
* If the PVID is found on a device that has not been scanned , then
* it needs to be scanned so it can be used .
*/
if ( ! dm_list_empty ( & cmd - > device_ids_check_serial ) ) {
struct dm_list scan_devs ;
dm_list_init ( & scan_devs ) ;
2023-10-28 01:13:25 +03:00
device_ids_check_serial ( cmd , & scan_devs , 0 , NULL ) ;
2022-11-01 00:14:01 +03:00
if ( ! dm_list_empty ( & scan_devs ) )
label_scan_devs ( cmd , cmd - > filter , & scan_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
/*
2023-10-05 23:22:32 +03:00
* device_ids_invalid is set by device_ids_validate ( ) when there
* are entries in the devices file that need to be corrected ,
* i . e . device IDs read from the system and / or PVIDs read from
* disk do not match info in the devices file . This is usually
* related to incorrect device names which routinely change on
* reboot . When device names change for entries that use
* IDTYPE = devname , it often means that all devs on the system
* need to be scanned to find the new device for the PVIDs .
* device_ids_validate ( ) will update the devices file to correct
* some info , but to locate new devices for PVIDs , it defers
2023-10-28 01:39:32 +03:00
* to device_ids_search ( ) which involves label scanning .
2023-10-05 23:22:32 +03:00
*
* device_ids_refresh_trigger is set by device_ids_read ( ) when
* it sees that the local machine doesn ' t match the machine
* that wrote the devices file , and device IDs of all types
* may need to be replaced for the PVIDs in the devices file .
* This also means that all devs on the system need to be
* scanned to find the new devices for the PVIDs .
*
2023-10-28 01:39:32 +03:00
* When device_ids_search ( ) locates the correct devices
2023-10-05 23:22:32 +03:00
* for the PVs in the devices file , it returns those new
* devices in the refresh_devs list . Those devs need to
* be passed to label_scan to populate lvmcache info .
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
*/
2023-10-05 23:22:32 +03:00
if ( cmd - > device_ids_invalid | | cmd - > device_ids_refresh_trigger ) {
2023-10-28 01:39:32 +03:00
struct dm_list new_devs ;
dm_list_init ( & new_devs ) ;
device_ids_search ( cmd , & new_devs , 0 , 0 , NULL ) ;
if ( ! dm_list_empty ( & new_devs ) )
label_scan_devs ( cmd , cmd - > filter , & new_devs ) ;
2023-10-05 23:22:32 +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
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
/*
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
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
*/
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 ) ;
2018-04-06 21:05:17 +03:00
log_debug_cache ( " Resolving duplicate devices " ) ;
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 ) {
2019-08-01 23:04:10 +03:00
log_debug_cache ( " Dropping unchosen duplicate %s " , dev_name ( devl - > dev ) ) ;
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 ) {
2019-08-01 23:04:10 +03:00
log_debug_cache ( " Adding chosen duplicate %s " , dev_name ( devl - > dev ) ) ;
2021-10-14 22:02:59 +03:00
label_scan_dev ( cmd , 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
}
2024-04-03 23:59:25 +03:00
_destroy_device_list ( & add_cache_devs ) ;
2019-08-01 21:50:04 +03:00
dm_list_splice ( & _unused_duplicates , & del_cache_devs ) ;
2018-05-11 23:52:22 +03:00
2019-08-01 23:04:10 +03:00
/* Warn about unused duplicates that the user might want to resolve. */
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
}
2021-02-06 01:16:03 +03:00
log_debug_cache ( " lvmcache label scan done " ) ;
return 1 ;
2002-11-18 16:53:58 +03:00
}
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 )
2015-05-06 00:24:50 +03:00
{
struct vgnameid_list * vgnl ;
struct lvmcache_vginfo * vginfo ;
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 ;
}
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 ;
}
2021-09-20 17:12:10 +03:00
struct device * lvmcache_device_from_pv_id ( struct cmd_context * cmd , const struct id * pvid , uint64_t * label_sector )
2011-06-01 23:29:31 +04:00
{
2018-02-07 22:14:08 +03:00
struct lvmcache_info * info ;
2002-11-18 16:53:58 +03:00
2021-09-20 17:12:10 +03:00
if ( ( info = lvmcache_info_from_pv_id ( pvid , NULL , 0 ) ) ) {
2018-02-07 22:14:08 +03:00
if ( info - > label & & label_sector )
* label_sector = info - > label - > sector ;
return info - > dev ;
}
2002-11-18 16:53:58 +03:00
return NULL ;
}
2019-08-01 21:50:04 +03:00
int lvmcache_pvid_in_unused_duplicates ( const char * pvid )
2016-06-06 23:39:51 +03:00
{
struct device_list * devl ;
2019-08-01 21:50:04 +03:00
dm_list_iterate_items ( devl , & _unused_duplicates ) {
2021-08-03 23:32:33 +03:00
if ( ! memcmp ( devl - > dev - > pvid , pvid , ID_LEN ) )
2016-06-06 23:39:51 +03:00
return 1 ;
}
return 0 ;
}
2010-05-19 15:52:07 +04:00
2020-01-28 20:47:37 +03:00
static void _free_vginfo ( struct lvmcache_vginfo * vginfo )
2008-05-19 23:49:56 +04:00
{
2018-06-08 15:40:53 +03:00
free ( vginfo - > vgname ) ;
2020-01-28 20:47:37 +03:00
free ( vginfo - > system_id ) ;
2018-06-08 15:40:53 +03:00
free ( vginfo - > creation_host ) ;
2021-02-27 16:14:25 +03:00
free ( vginfo - > lock_type ) ;
2018-06-08 15:40:53 +03:00
free ( vginfo ) ;
2008-05-19 23:49:56 +04:00
}
2008-04-08 16:49:21 +04:00
/*
2020-01-28 20:47:37 +03:00
* Remove vginfo from standard lists / hashes .
2008-04-08 16:49:21 +04:00
*/
2020-01-28 20:47:37 +03:00
static void _drop_vginfo ( struct lvmcache_info * info , struct lvmcache_vginfo * vginfo )
2002-11-18 16:53:58 +03:00
{
2008-05-19 23:49:56 +04:00
if ( info )
_vginfo_detach_info ( info ) ;
2006-04-12 21:54:11 +04:00
2008-05-19 23:49:56 +04:00
/* vginfo still referenced? */
if ( ! vginfo | | is_orphan_vg ( vginfo - > vgname ) | |
2008-11-04 01:14:30 +03:00
! dm_list_empty ( & vginfo - > infos ) )
2020-01-28 20:47:37 +03:00
return ;
2002-11-18 16:53:58 +03:00
2020-01-28 20:47:37 +03:00
if ( dm_hash_lookup ( _vgname_hash , vginfo - > vgname ) = = vginfo )
dm_hash_remove ( _vgname_hash , vginfo - > vgname ) ;
2006-04-12 21:54:11 +04:00
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 ) ;
2002-11-18 16:53:58 +03:00
}
2003-07-05 02:34:56 +04:00
void lvmcache_del ( struct lvmcache_info * info )
2002-11-18 16:53:58 +03:00
{
if ( info - > dev - > pvid [ 0 ] & & _pvid_hash )
2005-10-17 03:03:59 +04:00
dm_hash_remove ( _pvid_hash , info - > dev - > pvid ) ;
2002-11-18 16:53:58 +03:00
2008-04-08 16:49:21 +04:00
_drop_vginfo ( info , info - > vginfo ) ;
2002-11-18 16:53:58 +03:00
info - > label - > labeller - > ops - > destroy_label ( info - > label - > labeller ,
2014-06-09 00:57:04 +04:00
info - > label ) ;
2018-05-14 21:38:16 +03:00
label_destroy ( info - > label ) ;
2018-06-08 15:40:53 +03:00
free ( info ) ;
2014-06-09 00:57:04 +04:00
}
2002-11-18 16:53:58 +03:00
2018-03-01 19:20:34 +03:00
void lvmcache_del_dev ( struct device * dev )
{
struct lvmcache_info * info ;
2021-08-03 23:32:33 +03:00
if ( ( info = lvmcache_info_from_pvid ( dev - > pvid , dev , 0 ) ) )
2018-03-01 19:20:34 +03:00
lvmcache_del ( info ) ;
}
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 )
2002-11-18 16:53:58 +03:00
{
2008-04-08 16:49:21 +04:00
if ( ! vgid | | ! vginfo | |
2021-08-03 23:32:33 +03:00
! memcmp ( vginfo - > vgid , vgid , ID_LEN ) )
2002-11-18 16:53:58 +03:00
return 1 ;
2008-04-08 16:49:21 +04:00
if ( vginfo & & * vginfo - > vgid )
dm_hash_remove ( _vgid_hash , vginfo - > vgid ) ;
2006-04-11 02:09:00 +04:00
if ( ! vgid ) {
2012-02-08 16:57:15 +04:00
/* FIXME: unreachable code path */
2013-01-08 02:30:29 +04:00
log_debug_cache ( " lvmcache: %s: clearing VGID " , info ? dev_name ( info - > dev ) : vginfo - > vgname ) ;
2002-11-18 16:53:58 +03:00
return 1 ;
2006-04-11 02:09:00 +04:00
}
2002-11-18 16:53:58 +03:00
2021-08-03 23:32:33 +03:00
memset ( vginfo - > vgid , 0 , sizeof ( vginfo - > vgid ) ) ;
memcpy ( vginfo - > vgid , vgid , ID_LEN ) ;
2008-04-08 16:49:21 +04:00
if ( ! dm_hash_insert ( _vgid_hash , vginfo - > vgid , vginfo ) ) {
2003-07-05 02:34:56 +04:00
log_error ( " _lvmcache_update: vgid hash insertion failed: %s " ,
2008-04-08 16:49:21 +04:00
vginfo - > vgid ) ;
2002-11-18 16:53:58 +03:00
return 0 ;
}
2008-04-08 16:49:21 +04:00
if ( ! is_orphan_vg ( vginfo - > vgname ) )
2016-04-12 14:06:16 +03:00
log_debug_cache ( " lvmcache %s: VG %s: set VGID to " FMTVGID " . " ,
2013-01-08 02:30:29 +04:00
( info ) ? dev_name ( info - > dev ) : " " ,
vginfo - > vgname , vginfo - > vgid ) ;
2006-04-11 02:09:00 +04:00
2002-11-18 16:53:58 +03:00
return 1 ;
}
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 )
2006-04-12 21:54:11 +04:00
{
2021-08-03 23:32:33 +03:00
char vgid_dashed [ 64 ] __attribute__ ( ( aligned ( 8 ) ) ) ;
char other_dashed [ 64 ] __attribute__ ( ( aligned ( 8 ) ) ) ;
2020-01-28 20:47:37 +03:00
struct lvmcache_vginfo * vginfo ;
struct lvmcache_vginfo * other ;
int vginfo_is_allowed ;
int other_is_allowed ;
2006-04-13 01:23:04 +04:00
2020-01-28 20:47:37 +03:00
if ( ! vgname | | ( info & & info - > vginfo & & ! strcmp ( info - > vginfo - > vgname , vgname ) ) )
return 1 ;
2006-04-13 01:23:04 +04:00
2021-08-03 23:32:33 +03:00
if ( ! id_write_format ( ( const struct id * ) vgid , vgid_dashed , sizeof ( vgid_dashed ) ) )
2020-01-28 20:47:37 +03:00
stack ;
2018-12-07 23:35:22 +03:00
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 ;
2006-04-13 21:32:24 +04:00
}
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 ;
2006-04-13 21:32:24 +04:00
}
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 ;
2006-04-12 21:54:11 +04:00
2020-01-28 20:47:37 +03:00
if ( ! dm_hash_insert ( _vgname_hash , vgname , vginfo ) ) {
free ( vginfo - > vgname ) ;
free ( vginfo ) ;
return_0 ;
}
2006-04-12 21:54:11 +04:00
2020-01-28 20:47:37 +03:00
if ( ! _lvmcache_update_vgid ( NULL , vginfo , vgid ) ) {
free ( vginfo - > vgname ) ;
free ( vginfo ) ;
return_0 ;
}
2002-11-18 16:53:58 +03:00
2020-01-28 20:47:37 +03:00
/* Ensure orphans appear last on list_iterate */
dm_list_add ( & _vginfos , & vginfo - > list ) ;
2002-11-18 16:53:58 +03:00
return 1 ;
2020-01-28 20:47:37 +03:00
}
2002-11-18 16:53:58 +03:00
2020-01-28 20:47:37 +03:00
_drop_vginfo ( info , info - > vginfo ) ;
2002-11-18 16:53:58 +03:00
2022-01-06 19:15:16 +03:00
vginfo = lvmcache_vginfo_from_vgid ( vgid ) ;
if ( vginfo & & strcmp ( vginfo - > vgname , vgname ) ) {
log_warn ( " WARNING: fix duplicate VGID %s for VGs %s and %s (see vgchange -u). " , vgid_dashed , vgname , vginfo - > vgname ) ;
vginfo = lvmcache_vginfo_from_vgname ( vgname , NULL ) ;
if ( vginfo & & memcmp ( vginfo - > vgid , vgid , ID_LEN ) ) {
log_error ( " Ignoring %s with conflicting VG info %s %s. " , dev_name ( info - > dev ) , vgid_dashed , vgname ) ;
return_0 ;
}
}
if ( ! vginfo ) {
2018-04-09 21:40:49 +03:00
/*
* Create a vginfo struct for this VG and put the vginfo
* into the hash table .
*/
2006-04-14 01:08:29 +04:00
2021-08-03 23:32:33 +03:00
log_debug_cache ( " lvmcache adding vginfo for %s %s " , vgname , vgid_dashed ) ;
2020-01-28 20:47:37 +03:00
2018-06-08 15:40:53 +03:00
if ( ! ( vginfo = zalloc ( sizeof ( * vginfo ) ) ) ) {
2020-01-28 20:47:37 +03:00
log_error ( " lvmcache adding vg list alloc failed %s " , vgname ) ;
2002-11-18 16:53:58 +03:00
return 0 ;
}
2018-06-08 15:40:53 +03:00
if ( ! ( vginfo - > vgname = strdup ( vgname ) ) ) {
free ( vginfo ) ;
2020-01-28 20:47:37 +03:00
log_error ( " lvmcache adding vg name alloc failed %s " , vgname ) ;
2002-11-18 16:53:58 +03:00
return 0 ;
}
2008-11-04 01:14:30 +03:00
dm_list_init ( & vginfo - > infos ) ;
2019-02-05 21:55:51 +03:00
dm_list_init ( & vginfo - > outdated_infos ) ;
2019-09-26 19:27:38 +03:00
dm_list_init ( & vginfo - > pvsummaries ) ;
2008-05-29 02:27:47 +04:00
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 ) ;
2008-05-29 02:27:47 +04:00
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 " ,
2021-08-03 23:32:33 +03:00
vgname , vgid , other - > vgname , other - > vgid ) ;
2020-01-28 20:47:37 +03:00
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 ) {
2021-08-03 23:32:33 +03:00
if ( ! id_write_format ( ( const struct id * ) other - > vgid , other_dashed , sizeof ( other_dashed ) ) )
2020-01-28 20:47:37 +03:00
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. " ,
2021-08-03 23:32:33 +03:00
vgname , vgid_dashed , other_dashed ) ;
2020-01-28 20:47:37 +03:00
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 ;
}
2002-11-18 16:53:58 +03:00
}
2018-04-09 21:40:49 +03:00
2020-01-28 20:47:37 +03:00
dm_list_add_h ( & _vginfos , & vginfo - > list ) ;
2002-11-18 16:53:58 +03:00
}
2008-04-08 16:49:21 +04:00
vginfo - > fmt = fmt ;
2020-01-28 20:47:37 +03:00
info - > vginfo = vginfo ;
dm_list_add ( & vginfo - > infos , & info - > list ) ;
2008-04-08 16:49:21 +04:00
2021-08-03 23:32:33 +03:00
log_debug_cache ( " lvmcache %s: now in VG %s %s " , dev_name ( info - > dev ) , vgname , vgid ) ;
2005-03-22 01:40:35 +03:00
2002-11-18 16:53:58 +03:00
return 1 ;
}
2006-04-13 21:32:24 +04:00
static int _lvmcache_update_vgstatus ( struct lvmcache_info * info , uint32_t vgstatus ,
2015-11-30 20:32:17 +03:00
const char * creation_host , const char * lock_type ,
const char * system_id )
2006-04-11 21:42:15 +04:00
{
if ( ! info | | ! info - > vginfo )
return 1 ;
if ( ( info - > vginfo - > status & EXPORTED_VG ) ! = ( vgstatus & EXPORTED_VG ) )
2016-04-12 14:06:16 +03:00
log_debug_cache ( " lvmcache %s: VG %s %s exported. " ,
2013-01-08 02:30:29 +04:00
dev_name ( info - > dev ) , info - > vginfo - > vgname ,
vgstatus & EXPORTED_VG ? " now " : " no longer " ) ;
2006-04-11 21:42:15 +04:00
info - > vginfo - > status = vgstatus ;
2006-04-13 21:32:24 +04:00
if ( ! creation_host )
2015-07-24 23:20:37 +03:00
goto set_lock_type ;
2006-04-13 21:32:24 +04:00
if ( info - > vginfo - > creation_host & & ! strcmp ( creation_host ,
info - > vginfo - > creation_host ) )
2015-07-24 23:20:37 +03:00
goto set_lock_type ;
2006-04-13 21:32:24 +04:00
2018-06-08 15:40:53 +03:00
free ( info - > vginfo - > creation_host ) ;
2006-04-13 21:32:24 +04:00
2018-06-08 15:40:53 +03:00
if ( ! ( info - > vginfo - > creation_host = strdup ( creation_host ) ) ) {
2016-04-12 14:06:16 +03:00
log_error ( " cache creation host alloc failed for %s. " ,
2006-04-13 21:32:24 +04:00
creation_host ) ;
return 0 ;
}
2016-04-12 14:06:16 +03:00
log_debug_cache ( " lvmcache %s: VG %s: set creation host to %s. " ,
2013-01-08 02:30:29 +04:00
dev_name ( info - > dev ) , info - > vginfo - > vgname , creation_host ) ;
2006-04-13 21:32:24 +04:00
2015-07-24 23:20:37 +03:00
set_lock_type :
if ( ! lock_type )
2015-11-30 20:32:17 +03:00
goto set_system_id ;
2015-07-24 23:20:37 +03:00
if ( info - > vginfo - > lock_type & & ! strcmp ( lock_type , info - > vginfo - > lock_type ) )
2015-11-30 20:32:17 +03:00
goto set_system_id ;
2015-07-24 23:20:37 +03:00
2018-06-08 15:40:53 +03:00
free ( info - > vginfo - > lock_type ) ;
2015-07-24 23:20:37 +03:00
2018-06-08 15:40:53 +03:00
if ( ! ( info - > vginfo - > lock_type = strdup ( lock_type ) ) ) {
2015-11-30 20:32:17 +03:00
log_error ( " cache lock_type alloc failed for %s " , lock_type ) ;
return 0 ;
}
2016-04-12 14:06:16 +03:00
log_debug_cache ( " lvmcache %s: VG %s: set lock_type to %s. " ,
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 ;
2018-06-08 15:40:53 +03:00
free ( info - > vginfo - > system_id ) ;
2015-11-30 20:32:17 +03:00
2018-06-08 15:40:53 +03:00
if ( ! ( info - > vginfo - > system_id = strdup ( system_id ) ) ) {
2015-11-30 20:32:17 +03:00
log_error ( " cache system_id alloc failed for %s " , system_id ) ;
2015-07-24 23:20:37 +03:00
return 0 ;
}
2016-04-12 14:06:16 +03:00
log_debug_cache ( " lvmcache %s: VG %s: set system_id to %s. " ,
2015-11-30 20:32:17 +03:00
dev_name ( info - > dev ) , info - > vginfo - > vgname , system_id ) ;
2015-07-24 23:20:37 +03:00
out :
2006-04-11 21:42:15 +04:00
return 1 ;
}
2020-01-28 20:47:37 +03:00
int lvmcache_add_orphan_vginfo ( struct cmd_context * cmd , const char * vgname , struct format_type * fmt )
2008-04-08 16:49:21 +04:00
{
2020-01-28 20:47:37 +03:00
return _lvmcache_update_vgname ( cmd , NULL , vgname , vgname , " " , fmt ) ;
2008-04-08 16:49:21 +04:00
}
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 ) ;
}
}
2018-04-19 00:29:42 +03:00
/*
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 .
2018-04-19 00:29:42 +03:00
*/
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 )
2006-04-11 20:00:26 +04:00
{
2015-03-19 02:43:02 +03:00
const char * vgname = vgsummary - > vgname ;
2021-08-03 23:32:33 +03:00
const char * vgid = vgsummary - > vgid ;
2018-04-19 00:29:42 +03:00
struct lvmcache_vginfo * vginfo ;
2015-03-19 02:43:02 +03:00
2008-02-06 18:47:28 +03:00
if ( ! vgname & & ! info - > vginfo ) {
2009-12-16 22:22:11 +03:00
log_error ( INTERNAL_ERROR " NULL vgname handed to cache " ) ;
2008-02-06 18:47:28 +03:00
/* FIXME Remove this */
vgname = info - > fmt - > orphan_vg_name ;
vgid = vgname ;
}
2008-04-08 16:49:21 +04:00
2020-01-28 20:47:37 +03:00
/* FIXME: remove this, it shouldn't be needed */
2008-06-11 15:02:05 +04:00
/* If PV without mdas is already in a real VG, don't make it orphan */
2010-06-29 00:34:58 +04:00
if ( is_orphan_vg ( vgname ) & & info - > vginfo & &
mdas_empty_or_ignored ( & info - > mdas ) & &
2011-02-18 17:16:11 +03:00
! is_orphan_vg ( info - > vginfo - > vgname ) & & critical_section ( ) )
2008-06-11 15:02:05 +04:00
return 1 ;
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 .
*/
2020-01-28 20:47:37 +03:00
if ( ! _lvmcache_update_vgname ( cmd , info , vgname , vgid , vgsummary - > system_id , info - > fmt ) ) {
2019-02-05 22:09:56 +03:00
/* shouldn't happen, internal error */
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 ) ) {
2019-02-05 22:09:56 +03:00
/* shouldn't happen, internal error */
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 ;
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 */
2018-04-19 00:29:42 +03:00
if ( ! ( vginfo = info - > vginfo ) )
return 1 ;
if ( ! vginfo - > seqno ) {
vginfo - > seqno = vgsummary - > seqno ;
2019-02-05 22:09:56 +03:00
vginfo - > mda_checksum = vgsummary - > mda_checksum ;
vginfo - > mda_size = vgsummary - > mda_size ;
2018-04-19 00:29:42 +03:00
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 ;
2018-04-19 00:29:42 +03:00
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 ) ;
2018-04-19 00:29:42 +03:00
return 1 ;
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 ;
2018-04-19 00:29:42 +03:00
vginfo - > mda_checksum = vgsummary - > mda_checksum ;
vginfo - > mda_size = vgsummary - > mda_size ;
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 .
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 .
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 ;
2019-10-08 22:44:24 +03:00
vgsummary - > mismatch = 1 ;
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 .
*/
2018-04-19 00:29:42 +03:00
return 1 ;
}
2019-02-05 22:09:56 +03:00
update_vginfo :
2018-04-19 00:29:42 +03:00
if ( ! _lvmcache_update_vgstatus ( info , vgsummary - > vgstatus , vgsummary - > creation_host ,
vgsummary - > lock_type , vgsummary - > system_id ) ) {
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 .
*/
2018-04-19 00:29:42 +03:00
log_error ( " Failed to update VG %s info in lvmcache. " , vgname ) ;
}
2006-04-11 20:00:26 +04:00
2019-09-26 19:27:38 +03:00
_lvmcache_update_pvsummaries ( vginfo , vgsummary ) ;
2006-04-11 20:00:26 +04:00
return 1 ;
}
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
2023-02-09 19:05:01 +03:00
* shouldn ' t be . After vg_read ( ) gets the full metadata in the form of a ' vg ' ,
2019-02-06 21:10:13 +03:00
* 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 )
{
2021-08-03 23:32:33 +03:00
char pvid [ ID_LEN + 1 ] __attribute__ ( ( aligned ( 8 ) ) ) = { 0 } ;
char vgid [ ID_LEN + 1 ] __attribute__ ( ( aligned ( 8 ) ) ) = { 0 } ;
2019-02-06 21:10:13 +03:00
struct pv_list * pvl ;
struct lvmcache_vginfo * vginfo ;
struct lvmcache_info * info , * info2 ;
struct metadata_area * mda ;
struct lvmcache_vgsummary vgsummary = {
. vgname = vg - > name ,
2020-08-29 22:37:39 +03:00
. vgstatus = vg - > status ,
2019-02-06 21:10:13 +03:00
. system_id = vg - > system_id ,
. lock_type = vg - > lock_type
} ;
2021-08-03 23:32:33 +03:00
memcpy ( vgid , & vg - > id , ID_LEN ) ;
memcpy ( vgsummary . vgid , vgid , ID_LEN ) ;
if ( ! ( vginfo = lvmcache_vginfo_from_vgname ( vg - > name , vgid ) ) ) {
2019-02-06 21:10:13 +03:00
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 ) ;
2020-06-03 20:38:27 +03:00
if ( ! _outdated_warning + + )
log_warn ( " See vgck --updatemetadata to clear outdated metadata. " ) ;
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 ) {
2021-08-03 23:32:33 +03:00
memcpy ( pvid , & pvl - > pv - > id . uuid , ID_LEN ) ;
2019-02-06 21:10:13 +03:00
2021-08-03 23:32:33 +03:00
if ( ! ( info = lvmcache_info_from_pvid ( pvid , pvl - > pv - > dev , 0 ) ) ) {
2019-02-06 21:10:13 +03:00
log_debug_cache ( " lvmcache_update_vg %s no info for %s %s " ,
2021-08-03 23:32:33 +03:00
vg - > name , pvid ,
2019-02-06 21:10:13 +03:00
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 .
*/
2020-01-28 19:33:15 +03:00
if ( ! lvmcache_update_vgname_and_id ( vg - > cmd , info , & vgsummary ) ) {
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 ;
}
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 ?
*/
2019-02-05 22:40:34 +03:00
static struct lvmcache_info * _create_info ( struct labeller * labeller , struct device * dev , uint64_t label_sector )
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 ;
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 ;
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 ) ;
2002-11-18 16:53:58 +03:00
return NULL ;
}
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 ;
}
2020-01-28 19:33:15 +03:00
struct lvmcache_info * lvmcache_add ( struct cmd_context * cmd , struct labeller * labeller ,
2021-08-03 23:32:33 +03:00
const char * pvid_arg , struct device * dev , uint64_t label_sector ,
const char * vgname , const char * vgid_arg , uint32_t vgstatus ,
2019-02-05 22:40:34 +03:00
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
{
2021-10-01 15:10:39 +03:00
const char * pvid = pvid_arg ;
const char * vgid = vgid_arg ;
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_vgsummary vgsummary = { 0 } ;
struct lvmcache_info * info ;
struct lvmcache_info * info_lookup ;
struct device_list * devl ;
int created = 0 ;
2021-10-14 00:26:00 +03:00
/*
* Note : ensure that callers of lvmcache_add ( ) pass null terminated
* pvid and vgid strings , and do not pass char * that is type cast
* from struct id .
*/
2002-11-18 16:53:58 +03:00
2021-08-03 23:32:33 +03:00
log_debug_cache ( " Found PVID %s on %s " , pvid , dev_name ( 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
/*
* Find existing info struct in _pvid_hash or create a new one .
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
*/
2002-11-18 16:53:58 +03:00
2021-08-03 23:32:33 +03:00
info = lvmcache_info_from_pvid ( pvid , NULL , 0 ) ;
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 )
2016-06-06 22:04:17 +03:00
info = lvmcache_info_from_pvid ( dev - > pvid , NULL , 0 ) ;
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 ) {
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 ;
}
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 ) {
2019-08-01 23:04:10 +03:00
log_debug_cache ( " Saving initial duplicate device %s previously seen on %s with PVID %s. " ,
2021-10-14 00:26:00 +03:00
dev_name ( dev ) , dev_name ( info - > dev ) , pvid ) ;
2015-04-24 22:58:58 +03:00
2021-08-03 23:32:33 +03:00
memset ( & dev - > pvid , 0 , sizeof ( dev - > pvid ) ) ;
memcpy ( dev - > pvid , pvid , ID_LEN ) ;
2015-04-24 22:58:58 +03:00
2019-08-01 23:04:10 +03:00
/* shouldn't happen */
2022-11-07 20:38:46 +03:00
if ( device_list_find_dev ( & _initial_duplicates , dev ) )
2019-08-01 23:04:10 +03:00
log_debug_cache ( " Initial duplicate already in list %s " , dev_name ( dev ) ) ;
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 ;
2019-08-01 23:04:10 +03:00
dm_list_add ( & _initial_duplicates , & devl - > list ) ;
2019-11-14 19:08:20 +03:00
}
2019-08-01 23:04:10 +03:00
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 ;
2003-01-07 00:10:43 +03:00
}
2015-04-24 22:58:58 +03:00
2021-08-03 23:32:33 +03:00
if ( info - > dev - > pvid [ 0 ] & & pvid [ 0 ] & & memcmp ( pvid , info - > dev - > pvid , ID_LEN ) ) {
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
/* This happens when running pvcreate on an existing PV. */
2019-08-01 23:04:10 +03:00
log_debug_cache ( " Changing pvid on dev %s from %s to %s " ,
2021-08-03 23:32:33 +03:00
dev_name ( info - > dev ) , info - > dev - > pvid , pvid ) ;
2015-04-24 22:58:58 +03:00
}
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 ) ;
2002-11-18 16:53:58 +03:00
label_destroy ( info - > label ) ;
2008-01-30 16:19:47 +03:00
if ( ! ( info - > label = label_create ( labeller ) ) )
return_NULL ;
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 .
*/
2021-08-03 23:32:33 +03:00
info_lookup = dm_hash_lookup ( _pvid_hash , pvid ) ;
if ( ( info_lookup = = info ) & & ! memcmp ( info - > dev - > pvid , pvid , ID_LEN ) )
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 update_vginfo ;
if ( info - > dev - > pvid [ 0 ] )
dm_hash_remove ( _pvid_hash , info - > dev - > pvid ) ;
2021-08-03 23:32:33 +03:00
memset ( info - > dev - > pvid , 0 , sizeof ( info - > dev - > pvid ) ) ;
memcpy ( info - > dev - > pvid , pvid , ID_LEN ) ;
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
2021-08-03 23:32:33 +03:00
if ( ! dm_hash_insert ( _pvid_hash , pvid , info ) ) {
log_error ( " Adding pvid to hash failed %s " , pvid ) ;
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 ;
2021-10-01 15:10:39 +03:00
if ( vgid & & vgid [ 0 ] )
2021-08-03 23:32:33 +03:00
memcpy ( vgsummary . vgid , vgid , ID_LEN ) ;
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
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 ) {
2021-08-03 23:32:33 +03:00
dm_hash_remove ( _pvid_hash , pvid ) ;
info - > dev - > pvid [ 0 ] = 0 ;
2018-06-08 15:40:53 +03:00
free ( info - > label ) ;
free ( info ) ;
2002-11-18 16:53:58 +03:00
}
return NULL ;
}
return info ;
}
2020-01-28 20:47:37 +03:00
static void _lvmcache_destroy_info ( struct lvmcache_info * info )
2002-11-18 16:53:58 +03:00
{
2008-05-19 23:49:56 +04:00
_vginfo_detach_info ( info ) ;
2013-07-19 17:32:49 +04:00
info - > dev - > pvid [ 0 ] = 0 ;
2002-11-18 16:53:58 +03:00
label_destroy ( info - > label ) ;
2018-06-08 15:40:53 +03:00
free ( info ) ;
2002-11-18 16:53:58 +03:00
}
2014-03-22 01:26:39 +04:00
void lvmcache_destroy ( struct cmd_context * cmd , int retain_orphans , int reset )
2002-11-18 16:53:58 +03:00
{
2020-01-28 20:47:37 +03:00
struct lvmcache_vginfo * vginfo , * vginfo2 ;
log_debug_cache ( " Destroy lvmcache content " ) ;
2005-03-22 01:40:35 +03:00
2002-11-18 16:53:58 +03:00
if ( _vgid_hash ) {
2005-10-17 03:03:59 +04:00
dm_hash_destroy ( _vgid_hash ) ;
2002-11-18 16:53:58 +03:00
_vgid_hash = NULL ;
}
if ( _pvid_hash ) {
2020-01-28 20:47:37 +03:00
dm_hash_iter ( _pvid_hash , ( dm_hash_iterate_fn ) _lvmcache_destroy_info ) ;
2005-10-17 03:03:59 +04:00
dm_hash_destroy ( _pvid_hash ) ;
2002-11-18 16:53:58 +03:00
_pvid_hash = NULL ;
}
if ( _vgname_hash ) {
2005-10-17 03:03:59 +04:00
dm_hash_destroy ( _vgname_hash ) ;
2002-11-18 16:53:58 +03:00
_vgname_hash = NULL ;
}
2003-07-05 02:34:56 +04:00
2020-01-28 20:47:37 +03:00
dm_list_iterate_items_safe ( vginfo , vginfo2 , & _vginfos ) {
dm_list_del ( & vginfo - > list ) ;
_free_vginfo ( vginfo ) ;
}
2008-11-04 01:14:30 +03:00
if ( ! dm_list_empty ( & _vginfos ) )
2020-01-28 20:47:37 +03:00
log_error ( INTERNAL_ERROR " vginfos list should be empty " ) ;
2008-11-04 01:14:30 +03:00
dm_list_init ( & _vginfos ) ;
2008-04-08 16:49:21 +04:00
2019-08-01 21:50:04 +03:00
_destroy_device_list ( & _unused_duplicates ) ;
_destroy_device_list ( & _initial_duplicates ) ; /* should be empty anyway */
2016-06-06 23:20:55 +03:00
2018-05-03 00:58:49 +03:00
if ( retain_orphans ) {
struct format_type * fmt ;
2018-11-03 00:19:26 +03:00
if ( ! lvmcache_init ( cmd ) )
stack ;
2018-05-03 00:58:49 +03:00
dm_list_iterate_items ( fmt , & cmd - > formats ) {
2020-01-28 20:47:37 +03:00
if ( ! lvmcache_add_orphan_vginfo ( cmd , fmt - > orphan_vg_name , fmt ) )
2018-05-03 00:58:49 +03:00
stack ;
}
}
2002-11-18 16:53:58 +03:00
}
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 .
*/
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 ,
2017-11-06 21:09:52 +03:00
struct volume_group * vg ,
struct physical_volume * pv )
2012-02-10 05:28:27 +04:00
{
struct data_area_list * da ;
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 ;
2012-02-10 05:28:27 +04:00
}
2017-11-06 21:09:52 +03:00
pv - > label_sector = info - > label - > sector ;
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 ;
2021-08-03 23:32:33 +03:00
memset ( & pv - > id , 0 , sizeof ( pv - > id ) ) ;
memcpy ( & pv - > id , & info - > dev - > pvid , ID_LEN ) ;
2012-02-10 05:28:27 +04:00
2017-11-06 21:09:52 +03:00
if ( ! pv - > size ) {
log_error ( " PV %s size is zero. " , dev_name ( info - > dev ) ) ;
return 0 ;
}
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 ;
}
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 ) ) ;
2013-02-14 19:04:35 +04:00
return 0 ;
}
2012-02-10 05:28:27 +04:00
dm_list_iterate_items ( da , & info - > das )
pv - > pe_start = da - > disk_locn . offset > > SECTOR_SHIFT ;
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 ;
2013-02-14 19:04:35 +04:00
}
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 ) ;
2019-02-05 21:39:08 +03:00
if ( info - > bad_mdas . n )
del_mdas ( & info - > bad_mdas ) ;
dm_list_init ( & info - > bad_mdas ) ;
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 ) ;
}
2013-05-28 14:37:22 +04:00
void lvmcache_del_bas ( struct lvmcache_info * info )
2013-02-14 18:35:57 +04:00
{
2013-05-28 14:37:22 +04:00
if ( info - > bas . n )
del_bas ( & info - > bas ) ;
dm_list_init ( & info - > bas ) ;
2013-02-14 18:35:57 +04:00
}
2012-02-10 05:28:27 +04:00
int lvmcache_add_mda ( struct lvmcache_info * info , struct device * dev ,
2019-02-05 22:24:23 +03:00
uint64_t start , uint64_t size , unsigned ignored ,
struct metadata_area * * mda_new )
2012-02-10 05:28:27 +04:00
{
2019-02-05 22:24:23 +03:00
return add_mda ( info - > fmt , NULL , & info - > mdas , dev , start , size , ignored , mda_new ) ;
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 ) ;
}
2013-05-28 14:37:22 +04:00
int lvmcache_add_ba ( struct lvmcache_info * info , uint64_t start , uint64_t size )
2013-02-14 18:35:57 +04:00
{
2013-05-28 14:37:22 +04:00
return add_ba ( NULL , & info - > bas , start , size ) ;
2013-02-14 18:35:57 +04:00
}
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 ) ;
2012-02-23 17:11:07 +04:00
if ( ! add_da ( NULL , & info - > das , pv - > pe_start < < SECTOR_SHIFT , 0 /*pv->size << SECTOR_SHIFT*/ ) )
2012-02-10 05:28:27 +04:00
return_0 ;
return 1 ;
}
2013-05-28 14:37:22 +04:00
int lvmcache_update_bas ( struct lvmcache_info * info , struct physical_volume * pv )
2013-02-14 18:35:57 +04:00
{
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 ;
2013-02-14 18:35:57 +04:00
}
2013-05-28 14:37:22 +04:00
del_das ( & info - > bas ) ;
2013-02-14 18:35:57 +04:00
} else
2013-05-28 14:37:22 +04:00
dm_list_init ( & info - > bas ) ;
2013-02-14 18:35:57 +04:00
2013-05-28 14:37:22 +04:00
if ( ! add_ba ( NULL , & info - > bas , pv - > ba_start < < SECTOR_SHIFT , pv - > ba_size < < SECTOR_SHIFT ) )
2013-02-14 18:35:57 +04:00
return_0 ;
return 1 ;
}
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 ;
}
2013-02-05 19:43:16 +04:00
unsigned lvmcache_mda_count ( struct lvmcache_info * info )
2012-02-10 05:28:27 +04:00
{
return dm_list_size ( & info - > mdas ) ;
}
int lvmcache_foreach_da ( struct lvmcache_info * info ,
2012-02-23 17:11:07 +04:00
int ( * fun ) ( struct disk_locn * , void * ) ,
2012-02-10 05:28:27 +04:00
void * baton )
{
struct data_area_list * da ;
dm_list_iterate_items ( da , & info - > das ) {
2012-02-23 17:11:07 +04:00
if ( ! fun ( & da - > disk_locn , baton ) )
2012-02-10 05:28:27 +04:00
return_0 ;
}
return 1 ;
}
2013-05-28 14:37:22 +04:00
int lvmcache_foreach_ba ( struct lvmcache_info * info ,
2013-02-14 18:35:57 +04:00
int ( * fun ) ( struct disk_locn * , void * ) ,
void * baton )
{
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 ) )
2013-02-14 18:35:57 +04:00
return_0 ;
}
return 1 ;
}
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 ;
}
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 ;
}
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 ;
}
2012-02-10 05:28:27 +04:00
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 ;
}
2013-02-05 19:43:16 +04:00
uint64_t lvmcache_smallest_mda_size ( struct lvmcache_info * info )
2012-02-10 05:28:27 +04:00
{
2014-01-14 07:17:27 +04:00
if ( ! info )
return UINT64_C ( 0 ) ;
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 ;
}
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 ;
2018-04-19 00:29:42 +03:00
vgsummary - > seqno = vginfo - > seqno ;
2021-08-03 23:32:33 +03:00
memset ( & vgsummary - > vgid , 0 , sizeof ( vgsummary - > vgid ) ) ;
memcpy ( & vgsummary - > vgid , vginfo - > vgid , ID_LEN ) ;
2015-03-19 02:43:02 +03:00
return 1 ;
}
}
return 0 ;
}
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 ;
}
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 ) {
2023-11-11 01:24:45 +03:00
if ( ! is_orphan_vg ( vginfo - > vgname ) ) {
len = strlen ( vginfo - > vgname ) ;
if ( * vg_max_name_len < len )
* vg_max_name_len = len ;
}
2015-10-19 21:58:43 +03:00
dm_list_iterate_items ( info , & vginfo - > infos ) {
len = strlen ( dev_name ( info - > dev ) ) ;
if ( * pv_max_name_len < len )
* pv_max_name_len = len ;
}
}
}
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 ;
}
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
*/
2019-02-05 22:09:56 +03:00
bool lvmcache_scan_mismatch ( struct cmd_context * cmd , const char * vgname , const char * vgid )
2018-04-19 00:29:42 +03:00
{
struct lvmcache_vginfo * vginfo ;
if ( ! vgname | | ! vgid )
2019-02-05 22:09:56 +03:00
return true ;
2018-04-19 00:29:42 +03:00
if ( ( vginfo = lvmcache_vginfo_from_vgid ( vgid ) ) )
return vginfo - > scan_summary_mismatch ;
2019-02-05 22:09:56 +03:00
return true ;
2018-04-19 00:29:42 +03:00
}
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 ;
}
2021-08-03 23:32:33 +03:00
int lvmcache_vginfo_has_pvid ( struct lvmcache_vginfo * vginfo , const char * pvid_arg )
2018-12-07 23:35:22 +03:00
{
2021-08-03 23:32:33 +03:00
char pvid [ ID_LEN + 1 ] __attribute__ ( ( aligned ( 8 ) ) ) = { 0 } ;
2018-12-07 23:35:22 +03:00
struct lvmcache_info * info ;
2021-08-03 23:32:33 +03:00
/* In case pvid_arg is not null terminated. */
memcpy ( pvid , pvid_arg , ID_LEN ) ;
2018-12-07 23:35:22 +03:00
dm_list_iterate_items ( info , & vginfo - > infos ) {
2021-08-03 23:32:33 +03:00
if ( ! memcmp ( info - > dev - > pvid , pvid , ID_LEN ) )
2018-12-07 23:35:22 +03:00
return 1 ;
}
return 0 ;
}
2019-05-22 22:25:08 +03:00
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 ;
}
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 ) {
2021-04-23 15:44:57 +03:00
if ( ! ( devl = dm_pool_zalloc ( cmd - > mem , sizeof ( * devl ) ) ) )
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 ) ) ) {
2019-06-10 18:33:41 +03:00
log_error ( INTERNAL_ERROR " lvmcache_del_outdated_devs no vginfo " ) ;
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 ;
}
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 " ;
2021-03-03 21:07:57 +03:00
if ( dev - > filtered_flags & DEV_FILTERED_IS_LV )
return " device is an LV " ;
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 " ;
}