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

2845 lines
75 KiB
C
Raw Normal View History

A new cache.
2002-11-18 16:53:58 +03:00
/*
Some whitespace tidy-ups.
2008-01-30 17:00:02 +03:00
* Copyright (C) 2001-2004 Sistina Software, Inc. All rights reserved.
Cache and share generated VG structs Extend vginfo cache with cached VG structure. So if the same metadata are use, skip mda decoding in the case, the same data are in use. This helps for operations like activation of all LVs in one VG, where same data were decoded giving the same output result. Patch adds 1-to-1 connection between volume_group and lvmcache_vginfo.
2011-08-11 21:24:23 +04:00
* Copyright (C) 2004-2011 Red Hat, Inc. All rights reserved.
A new cache.
2002-11-18 16:53:58 +03:00
*
Update copyright notices.
2004-03-30 23:35:44 +04:00
* This file is part of LVM2.
*
* This copyrighted material is made available to anyone wishing to use,
* modify, copy, or redistribute it subject to the terms and conditions
Fix inconsistent licence notices: executables are GPLv2; libraries LGPLv2.1.
2007-08-21 00:55:30 +04:00
* of the GNU Lesser General Public License v.2.1.
Update copyright notices.
2004-03-30 23:35:44 +04:00
*
Fix inconsistent licence notices: executables are GPLv2; libraries LGPLv2.1.
2007-08-21 00:55:30 +04:00
* You should have received a copy of the GNU Lesser General Public License
Update copyright notices.
2004-03-30 23:35:44 +04:00
* along with this program; if not, write to the Free Software Foundation,
doc: change fsf address Hmm rpmlint suggest fsf is using a different address these days, so lets keep it up-to-date
2016-01-21 13:49:46 +03:00
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
A new cache.
2002-11-18 16:53:58 +03:00
*/
#include "lib.h"
Another sync point - numerous fixes & clean ups.
2003-07-05 02:34:56 +04:00
#include "lvmcache.h"
A new cache.
2002-11-18 16:53:58 +03:00
#include "toolcontext.h"
#include "dev-cache.h"
Add some basic internal VG lock validation.
2008-04-03 22:56:40 +04:00
#include "locking.h"
A new cache.
2002-11-18 16:53:58 +03:00
#include "metadata.h"
Another sync point - numerous fixes & clean ups.
2003-07-05 02:34:56 +04:00
#include "memlock.h"
more str_list fns
2003-10-16 00:04:29 +04:00
#include "str_list.h"
When asked to drop cached committed VG metadata, invalidate cached PV labels.
2008-05-08 22:28:27 +04:00
#include "format-text.h"
Change import_vg_from_buffer to use config_tree Change function import_vg_from_buffer() to import_vg_from_config_tree(). Instead of creating config tree inside the function allow config tree to be passed as parameter - usable later for caching.
2011-01-10 16:13:42 +03:00
#include "config.h"
Detect duplicate PV uuids - select the one on an md device if appropriate.
2003-01-07 00:10:43 +03:00
The lvmetad client-side integration. Only active when use_lvmetad = 1 is set in lvm.conf *and* lvmetad is running.
2012-02-23 17:11:07 +04:00
#include "lvmetad.h"
lvmetad: set disabled flag in lvmetad if duplicate PVs are found When devices are being scanned, if duplicate PVs are seen, tell lvmetad to set its disabled flag because of duplicate PVs.
2016-01-29 21:25:20 +03:00
#include "lvmetad-client.h"
The lvmetad client-side integration. Only active when use_lvmetad = 1 is set in lvm.conf *and* lvmetad is running.
2012-02-23 17:11:07 +04:00
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
#define CACHE_LOCKED 0x00000002
/* One per device */
struct lvmcache_info {
struct dm_list list; /* Join VG members together */
struct dm_list mdas; /* list head for metadata areas */
struct dm_list das; /* list head for data areas */
refactor: rename embedding area -> bootloader area
2013-05-28 14:37:22 +04:00
struct dm_list bas; /* list head for bootloader areas */
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
struct lvmcache_vginfo *vginfo; /* NULL == unknown */
struct label *label;
const struct format_type *fmt;
struct device *dev;
uint64_t device_size; /* Bytes */
lvmcache/lvmetad: cache PV extension version Store PV extension version in lvmcache/lvmetad for use throughout the code.
2016-02-11 18:25:36 +03:00
uint32_t ext_version; /* Extension version */
lvmcache/lvmetad: cache PV extension flags Store PV extension flags in lvmcache/lvmetad for use throughout the code.
2015-03-09 14:52:07 +03:00
uint32_t ext_flags; /* Extension flags */
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
uint32_t status;
};
/* One per VG */
struct lvmcache_vginfo {
struct dm_list list; /* Join these vginfos together */
struct dm_list infos; /* List head for lvmcache_infos */
const struct format_type *fmt;
char *vgname; /* "" == orphan */
uint32_t status;
char vgid[ID_LEN + 1];
char _padding[7];
struct lvmcache_vginfo *next; /* Another VG with same name? */
char *creation_host;
lvmcache: include system_id in vginfo cache Save system_id just like creation_host and lock_type strings in vginfo cache.
2015-11-30 20:32:17 +03:00
char *system_id;
lvmcache: add lock_type to VG summary and info structs vgsummary information contains provisional VG information that is obtained without holding the VG lock. This info can be used to lock the VG, and then read it with vg_read(). After the VG is read properly, the vgsummary info should be verified. Add the VG lock_type to the vgsummary. It needs to be known before the VG can be locked and read.
2015-07-24 23:20:37 +03:00
char *lock_type;
cache: Store metadata size and checksum. Refactor the recent metadata-reading optimisation patches. Remove the recently-added cache fields from struct labeller and struct format_instance. Instead, introduce struct lvmcache_vgsummary to wrap the VG information that lvmcache holds and add the metadata size and checksum to it. Allow this VG summary information to be looked up by metadata size + checksum. Adjust the debug log messages to make it clear when this shortcut has been successful. (This changes the optimisation slightly, and might be extendable further.) Add struct cached_vg_fmtdata to format-specific vg_read calls to preserve state alongside the VG across separate calls and indicate if the details supplied match, avoiding the need to read and process the VG metadata again.
2015-03-19 02:43:02 +03:00
uint32_t mda_checksum;
size_t mda_size;
scan: skip device rescan in vg_read For reporting commands (pvs,vgs,lvs,pvdisplay,vgdisplay,lvdisplay) we do not need to repeat the label scan of devices in vg_read if they all had matching metadata in the initial label scan. The data read by label scan can just be reused for the vg_read. This cuts the amount of device i/o in half, from two reads of each device to one. We have to be careful to avoid repairing the VG if we've skipped rescanning. (The VG repair code is very poor, and will be redone soon.)
2018-04-19 00:29:42 +03:00
int seqno;
scan: use new label_scan for lvmcache_label_scan To do label scanning, lvm code calls lvmcache_label_scan(). Change lvmcache_label_scan() to use the new label_scan() based on bcache. Also add lvmcache_label_rescan_vg() which calls the new label_scan_devs() which does label scanning on only the specified devices. This is for a subsequent commit and is not yet used.
2018-02-07 22:14:08 +03:00
int independent_metadata_location; /* metadata read from independent areas */
scan: skip device rescan in vg_read For reporting commands (pvs,vgs,lvs,pvdisplay,vgdisplay,lvdisplay) we do not need to repeat the label scan of devices in vg_read if they all had matching metadata in the initial label scan. The data read by label scan can just be reused for the vg_read. This cuts the amount of device i/o in half, from two reads of each device to one. We have to be careful to avoid repairing the VG if we've skipped rescanning. (The VG repair code is very poor, and will be redone soon.)
2018-04-19 00:29:42 +03:00
int scan_summary_mismatch; /* vgsummary from devs had mismatching seqno or checksum */
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
/*
* The following are not related to lvmcache or vginfo,
* but are borrowing the vginfo to store the data.
lvmcache: rename suspended_vg to saved_vg The copy of the VG which clvmd stashes in lvmcache should not only be used between suspend and resume, but between sequential LV operations in clvmd, so that clvmd does not need to reread the VG for each one. Prepare for that by renaming the stashed VG as "saved_vg".
2018-04-24 20:18:22 +03:00
* saved_vg_* are used only by clvmd.
lvmcache: simplify metadata cache The copy of VG metadata stored in lvmcache was not being used in general. It pretended to be a generic VG metadata cache, but was not being used except for clvmd activation. There it was used to avoid reading from disk while devices were suspended, i.e. in resume. This removes the code that attempted to make this look like a generic metadata cache, and replaces with with something narrowly targetted to what it's actually used for. This is a way of passing the VG from suspend to resume in clvmd. Since in the case of clvmd one caller can't simply pass the same VG to both suspend and resume, suspend needs to stash the VG somewhere that resume can grab it from. (resume doesn't want to read it from disk since devices are suspended.) The lvmcache vginfo struct is used as a convenient place to stash the VG to pass it from suspend to resume, even though it isn't related to the lvmcache or vginfo. These suspended_vg* vginfo fields should not be used or touched anywhere else, they are only to be used for passing the VG data from suspend to resume in clvmd. The VG data being passed between suspend and resume is never modified, and will only exist in the brief period between suspend and resume in clvmd. suspend has both old (current) and new (precommitted) copies of the VG metadata. It stashes both of these in the vginfo prior to suspending devices. When vg_commit is successful, it sets a flag in vginfo as before, signaling the transition from old to new metadata. resume grabs the VG stashed by suspend. If the vg_commit happened, it grabs the new VG, and if the vg_commit didn't happen it grabs the old VG. The VG is then used to resume LVs. This isolates clvmd-specific code and usage from the normal lvm vg_read code, making the code simpler and the behavior easier to verify. Sequence of operations: - lv_suspend() has both vg_old and vg_new and stashes a copy of each onto the vginfo: lvmcache_save_suspended_vg(vg_old); lvmcache_save_suspended_vg(vg_new); - vg_commit() happens, which causes all clvmd instances to call lvmcache_commit_metadata(vg). A flag is set in the vginfo indicating the transition from the old to new VG: vginfo->suspended_vg_committed = 1; - lv_resume() needs either vg_old or vg_new to use in resuming LVs. It doesn't want to read the VG from disk since devices are suspended, so it gets the VG stashed by lv_suspend: vg = lvmcache_get_suspended_vg(vgid); If the vg_commit did not happen, suspended_vg_committed will not be set, and in this case, lvmcache_get_suspended_vg() will return the old VG instead of the new VG, and it will resume LVs based on the old metadata.
2017-11-01 17:35:40 +03:00
*
lvmcache: rename suspended_vg to saved_vg The copy of the VG which clvmd stashes in lvmcache should not only be used between suspend and resume, but between sequential LV operations in clvmd, so that clvmd does not need to reread the VG for each one. Prepare for that by renaming the stashed VG as "saved_vg".
2018-04-24 20:18:22 +03:00
* For activation/deactivation, these are used to avoid
* clvmd rereading a VG for each LV that is activated.
*
* For suspend/resume, this is used to avoid disk reads
* while devices are suspended:
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
* In suspend, both old (current) and new (precommitted)
* metadata is saved. (Each in three forms: buffer, cft,
* and vg). In resume, if the vg was committed
lvmcache: rename suspended_vg to saved_vg The copy of the VG which clvmd stashes in lvmcache should not only be used between suspend and resume, but between sequential LV operations in clvmd, so that clvmd does not need to reread the VG for each one. Prepare for that by renaming the stashed VG as "saved_vg".
2018-04-24 20:18:22 +03:00
* (saved_vg_committed is set), then LVs are resumed
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
* using the new metadata, but if the vg wasn't committed,
* then LVs are resumed using the old metadata.
*
lvmcache: rename suspended_vg to saved_vg The copy of the VG which clvmd stashes in lvmcache should not only be used between suspend and resume, but between sequential LV operations in clvmd, so that clvmd does not need to reread the VG for each one. Prepare for that by renaming the stashed VG as "saved_vg".
2018-04-24 20:18:22 +03:00
* saved_vg_committed is set to 1 when clvmd gets
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
* LCK_VG_COMMIT from vg_commit().
*
lvmcache: rename suspended_vg to saved_vg The copy of the VG which clvmd stashes in lvmcache should not only be used between suspend and resume, but between sequential LV operations in clvmd, so that clvmd does not need to reread the VG for each one. Prepare for that by renaming the stashed VG as "saved_vg".
2018-04-24 20:18:22 +03:00
* This data does not really belong in lvmcache, it's unrelated
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
* to lvmcache or vginfo, but it's just a convenient place
lvmcache: rename suspended_vg to saved_vg The copy of the VG which clvmd stashes in lvmcache should not only be used between suspend and resume, but between sequential LV operations in clvmd, so that clvmd does not need to reread the VG for each one. Prepare for that by renaming the stashed VG as "saved_vg".
2018-04-24 20:18:22 +03:00
* for clvmd to stash the VG (since the same caller isn't
* present to pass the VG to both suspend and resume in the
* case of clvmd.)
lvmcache: simplify metadata cache The copy of VG metadata stored in lvmcache was not being used in general. It pretended to be a generic VG metadata cache, but was not being used except for clvmd activation. There it was used to avoid reading from disk while devices were suspended, i.e. in resume. This removes the code that attempted to make this look like a generic metadata cache, and replaces with with something narrowly targetted to what it's actually used for. This is a way of passing the VG from suspend to resume in clvmd. Since in the case of clvmd one caller can't simply pass the same VG to both suspend and resume, suspend needs to stash the VG somewhere that resume can grab it from. (resume doesn't want to read it from disk since devices are suspended.) The lvmcache vginfo struct is used as a convenient place to stash the VG to pass it from suspend to resume, even though it isn't related to the lvmcache or vginfo. These suspended_vg* vginfo fields should not be used or touched anywhere else, they are only to be used for passing the VG data from suspend to resume in clvmd. The VG data being passed between suspend and resume is never modified, and will only exist in the brief period between suspend and resume in clvmd. suspend has both old (current) and new (precommitted) copies of the VG metadata. It stashes both of these in the vginfo prior to suspending devices. When vg_commit is successful, it sets a flag in vginfo as before, signaling the transition from old to new metadata. resume grabs the VG stashed by suspend. If the vg_commit happened, it grabs the new VG, and if the vg_commit didn't happen it grabs the old VG. The VG is then used to resume LVs. This isolates clvmd-specific code and usage from the normal lvm vg_read code, making the code simpler and the behavior easier to verify. Sequence of operations: - lv_suspend() has both vg_old and vg_new and stashes a copy of each onto the vginfo: lvmcache_save_suspended_vg(vg_old); lvmcache_save_suspended_vg(vg_new); - vg_commit() happens, which causes all clvmd instances to call lvmcache_commit_metadata(vg). A flag is set in the vginfo indicating the transition from the old to new VG: vginfo->suspended_vg_committed = 1; - lv_resume() needs either vg_old or vg_new to use in resuming LVs. It doesn't want to read the VG from disk since devices are suspended, so it gets the VG stashed by lv_suspend: vg = lvmcache_get_suspended_vg(vgid); If the vg_commit did not happen, suspended_vg_committed will not be set, and in this case, lvmcache_get_suspended_vg() will return the old VG instead of the new VG, and it will resume LVs based on the old metadata.
2017-11-01 17:35:40 +03:00
*/
lvmcache: rename suspended_vg to saved_vg The copy of the VG which clvmd stashes in lvmcache should not only be used between suspend and resume, but between sequential LV operations in clvmd, so that clvmd does not need to reread the VG for each one. Prepare for that by renaming the stashed VG as "saved_vg".
2018-04-24 20:18:22 +03:00
int saved_vg_committed;
char *saved_vg_old_buf;
struct dm_config_tree *saved_vg_old_cft;
struct volume_group *saved_vg_old;
char *saved_vg_new_buf;
struct dm_config_tree *saved_vg_new_cft;
struct volume_group *saved_vg_new;
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
};
Use hash, bitset, malloc, pool from libdevmapper.
2005-10-17 03:03:59 +04:00
static struct dm_hash_table *_pvid_hash = NULL;
static struct dm_hash_table *_vgid_hash = NULL;
static struct dm_hash_table *_vgname_hash = NULL;
static struct dm_hash_table *_lock_hash = NULL;
Initialise _vginfos list staticaly so there is no problem with using uninitialised variables in case, lvmcache_destory() is called without lvmcache_init().
2010-04-30 16:54:31 +04:00
static DM_LIST_INIT(_vginfos);
lvmcache: 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
static DM_LIST_INIT(_found_duplicate_devs);
static DM_LIST_INIT(_unused_duplicate_devs);
Avoid spurious duplicate VG messages referring to VGs that are gone. (untested)
2008-05-29 02:27:47 +04:00
static int _scanning_in_progress = 0;
Another sync point - numerous fixes & clean ups.
2003-07-05 02:34:56 +04:00
static int _has_scanned = 0;
static int _vgs_locked = 0;
Add some basic internal VG lock validation.
2008-04-03 22:56:40 +04:00
static int _vg_global_lock_held = 0; /* Global lock held when cache wiped? */
toollib: search for duplicate PVs only when needed A full search for duplicate PVs in the case of pvs -a is only necessary when duplicates have previously been detected in lvmcache. Use a global variable from lvmcache to indicate that duplicate PVs exist, so we can skip the search for duplicates when none exist.
2015-01-14 23:38:05 +03:00
static int _found_duplicate_pvs = 0; /* If we never see a duplicate PV we can skip checking for them later. */
vgrename: use process_each_vg Use process_each_vg() to lock and read the old VG, and then call the main vgrename code. When real VG names are used (not a UUID in place of the old name), the command still pre-locks the new name (when strcmp wants it locked first), before calling process_each_vg on the old name. In the case where the old name is replaced with a UUID, process_each_vg now translates that UUID into the real VG name, which it locks and reads. In this case, we cannot do pre-locking to maintain lock ordering because the old name is unknown. So, in this case the strcmp based lock ordering is suppressed and the old name is always locked first. This opens a remote chance for lock ordering conflict between racing vgrenames between two names where one or both commands use the UUID.
2015-12-01 23:09:01 +03:00
static int _suppress_lock_ordering = 0;
A new cache.
2002-11-18 16:53:58 +03:00
Another sync point - numerous fixes & clean ups.
2003-07-05 02:34:56 +04:00
int lvmcache_init(void)
A new cache.
2002-11-18 16:53:58 +03:00
{
Reset _vgs_locked in lvmcache_init() Upon successful fork(), _become_daemon() must assert that the locks that are currently held belong to the parent, not the child. All of the child's internal state saying 'this process holds a lock' has to be reset. A proper lvmcache_locking_reset() should follow later.
2010-01-11 22:08:18 +03:00
/*
* FIXME add a proper lvmcache_locking_reset() that
* resets the cache so no previous locks are locked
*/
_vgs_locked = 0;
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
dm_list_init(&_vginfos);
lvmcache: fix duplicate handling with multiple scans Some commands scan labels to populate lvmcache multiple times, i.e. lvmcache_init, scan labels to fill lvmcache, lvmcache_destroy, then later repeat Each time labels are scanned, duplicates are detected, and preferred devices are chosen. Each time this is done within a single command, we want to choose the same preferred devices. So, check for existing preferences when choosing preferred devices. This also fixes a problem with the list of unused duplicate devs when run in an lvm shell. The devs had been allocated from cmd memory, resulting in invalid list entries between commands.
2016-06-06 23:20:55 +03:00
dm_list_init(&_found_duplicate_devs);
dm_list_init(&_unused_duplicate_devs);
A new cache.
2002-11-18 16:53:58 +03:00
Use hash, bitset, malloc, pool from libdevmapper.
2005-10-17 03:03:59 +04:00
if (!(_vgname_hash = dm_hash_create(128)))
A new cache.
2002-11-18 16:53:58 +03:00
return 0;
Use hash, bitset, malloc, pool from libdevmapper.
2005-10-17 03:03:59 +04:00
if (!(_vgid_hash = dm_hash_create(128)))
A new cache.
2002-11-18 16:53:58 +03:00
return 0;
Use hash, bitset, malloc, pool from libdevmapper.
2005-10-17 03:03:59 +04:00
if (!(_pvid_hash = dm_hash_create(128)))
A new cache.
2002-11-18 16:53:58 +03:00
return 0;
Use hash, bitset, malloc, pool from libdevmapper.
2005-10-17 03:03:59 +04:00
if (!(_lock_hash = dm_hash_create(128)))
Another sync point - numerous fixes & clean ups.
2003-07-05 02:34:56 +04:00
return 0;
Remember to clear 'global lock held during cache refresh' state after use.
2009-10-22 21:33:09 +04:00
/*
* Reinitialising the cache clears the internal record of
* which locks are held. The global lock can be held during
* this operation so its state must be restored afterwards.
*/
if (_vg_global_lock_held) {
Add some basic internal VG lock validation.
2008-04-03 22:56:40 +04:00
lvmcache_lock_vgname(VG_GLOBAL, 0);
Remember to clear 'global lock held during cache refresh' state after use.
2009-10-22 21:33:09 +04:00
_vg_global_lock_held = 0;
}
Add some basic internal VG lock validation.
2008-04-03 22:56:40 +04:00
A new cache.
2002-11-18 16:53:58 +03:00
return 1;
}
The lvmetad client-side integration. Only active when use_lvmetad = 1 is set in lvm.conf *and* lvmetad is running.
2012-02-23 17:11:07 +04:00
void lvmcache_seed_infos_from_lvmetad(struct cmd_context *cmd)
{
lvmetad: rework command connection setup and checking The lvmetad connection is created within the init_connections() path during command startup, rather than via the old lvmetad_active() check. The old lvmetad_active() checks are replaced with lvmetad_used() which is a simple check that tests if the command is using/connected to lvmetad. The old lvmetad_set_active(cmd, 0) calls, which stopped the command from using lvmetad (to revert to disk scanning), are replaced with lvmetad_make_unused(cmd).
2016-04-14 01:00:01 +03:00
if (!lvmetad_used() || _has_scanned)
If lvmetad fails, don't set _has_scanned
2012-02-28 22:20:17 +04:00
return;
dev_cache: clean up scan Pull out all of the twisted logic and simply call dev_cache_scan at the start of the command prior to label scan.
2018-04-09 19:13:43 +03:00
dev_cache_scan();
If lvmetad fails, don't set _has_scanned
2012-02-28 22:20:17 +04:00
if (!lvmetad_pv_list_to_lvmcache(cmd)) {
stack;
return;
The lvmetad client-side integration. Only active when use_lvmetad = 1 is set in lvm.conf *and* lvmetad is running.
2012-02-23 17:11:07 +04:00
}
If lvmetad fails, don't set _has_scanned
2012-02-28 22:20:17 +04:00
_has_scanned = 1;
Minor fixes Just small updates and remove <backtrace> after log_error.
2012-03-28 15:11:25 +04:00
}
The lvmetad client-side integration. Only active when use_lvmetad = 1 is set in lvm.conf *and* lvmetad is running.
2012-02-23 17:11:07 +04:00
lvmcache: 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
static void _update_cache_info_lock_state(struct lvmcache_info *info, int locked)
Rely upon internally-cached PV labels while corresponding VG lock is held.
2008-01-30 02:45:48 +03:00
{
if (locked)
info->status |= CACHE_LOCKED;
else
info->status &= ~CACHE_LOCKED;
}
static void _update_cache_vginfo_lock_state(struct lvmcache_vginfo *vginfo,
int locked)
{
struct lvmcache_info *info;
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
dm_list_iterate_items(info, &vginfo->infos)
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
_update_cache_info_lock_state(info, locked);
Rely upon internally-cached PV labels while corresponding VG lock is held.
2008-01-30 02:45:48 +03:00
}
static void _update_cache_lock_state(const char *vgname, int locked)
{
struct lvmcache_vginfo *vginfo;
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
if (!(vginfo = lvmcache_vginfo_from_vgname(vgname, NULL)))
Rely upon internally-cached PV labels while corresponding VG lock is held.
2008-01-30 02:45:48 +03:00
return;
_update_cache_vginfo_lock_state(vginfo, locked);
}
lvmcache: rename suspended_vg to saved_vg The copy of the VG which clvmd stashes in lvmcache should not only be used between suspend and resume, but between sequential LV operations in clvmd, so that clvmd does not need to reread the VG for each one. Prepare for that by renaming the stashed VG as "saved_vg".
2018-04-24 20:18:22 +03:00
static void _saved_vg_free(struct lvmcache_vginfo *vginfo, int free_old, int free_new)
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
{
if (free_old) {
clvmd: reuse a vg struct for sequential LV operations After reading a VG, stash it in lvmcache as "saved_vg". Before reading the VG again, try to use the saved_vg. The saved_vg is dropped on VG lock operations.
2018-04-24 21:19:48 +03:00
if (vginfo->saved_vg_old) {
log_debug_cache("lvmcache: free saved_vg %s old %p",
vginfo->saved_vg_old->name,
vginfo->saved_vg_old);
vginfo->saved_vg_old->saved_in_clvmd = 0;
}
lvmcache: rename suspended_vg to saved_vg The copy of the VG which clvmd stashes in lvmcache should not only be used between suspend and resume, but between sequential LV operations in clvmd, so that clvmd does not need to reread the VG for each one. Prepare for that by renaming the stashed VG as "saved_vg".
2018-04-24 20:18:22 +03:00
if (vginfo->saved_vg_old_buf)
dm_free(vginfo->saved_vg_old_buf);
if (vginfo->saved_vg_old_cft)
dm_config_destroy(vginfo->saved_vg_old_cft);
if (vginfo->saved_vg_old)
release_vg(vginfo->saved_vg_old);
vginfo->saved_vg_old_buf = NULL;
vginfo->saved_vg_old_cft = NULL;
vginfo->saved_vg_old = NULL;
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
}
if (free_new) {
clvmd: reuse a vg struct for sequential LV operations After reading a VG, stash it in lvmcache as "saved_vg". Before reading the VG again, try to use the saved_vg. The saved_vg is dropped on VG lock operations.
2018-04-24 21:19:48 +03:00
if (vginfo->saved_vg_new) {
log_debug_cache("lvmcache: free saved_vg %s new pre %p",
vginfo->saved_vg_new->name,
vginfo->saved_vg_new);
vginfo->saved_vg_new->saved_in_clvmd = 0;
}
lvmcache: rename suspended_vg to saved_vg The copy of the VG which clvmd stashes in lvmcache should not only be used between suspend and resume, but between sequential LV operations in clvmd, so that clvmd does not need to reread the VG for each one. Prepare for that by renaming the stashed VG as "saved_vg".
2018-04-24 20:18:22 +03:00
if (vginfo->saved_vg_new_buf)
dm_free(vginfo->saved_vg_new_buf);
if (vginfo->saved_vg_new_cft)
dm_config_destroy(vginfo->saved_vg_new_cft);
if (vginfo->saved_vg_new)
release_vg(vginfo->saved_vg_new);
vginfo->saved_vg_new_buf = NULL;
vginfo->saved_vg_new_cft = NULL;
vginfo->saved_vg_new = NULL;
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
}
}
Add possibility to handle precommitted metadata in lvmcache. - Add drop_precommitted flag to force drop precommitted metadata - add lvmcache_commit_metadata() which upgrades precommitted metadata in cache No functional change in this patch - just preparation for following change.
2010-01-05 19:06:42 +03:00
static void _drop_metadata(const char *vgname, int drop_precommitted)
Drop cached VG metadata before and after committing changes to it.
2008-04-15 18:46:19 +04:00
{
struct lvmcache_vginfo *vginfo;
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
if (!(vginfo = lvmcache_vginfo_from_vgname(vgname, NULL)))
Drop cached VG metadata before and after committing changes to it.
2008-04-15 18:46:19 +04:00
return;
When dropping the VG metadata from the cache during a VG revert, we must reset the 'precomitted' flag, just as we'd clear if we next did a 'commit'.
2011-12-09 03:18:00 +04:00
if (drop_precommitted)
lvmcache: rename suspended_vg to saved_vg The copy of the VG which clvmd stashes in lvmcache should not only be used between suspend and resume, but between sequential LV operations in clvmd, so that clvmd does not need to reread the VG for each one. Prepare for that by renaming the stashed VG as "saved_vg".
2018-04-24 20:18:22 +03:00
_saved_vg_free(vginfo, 0, 1);
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
else
lvmcache: rename suspended_vg to saved_vg The copy of the VG which clvmd stashes in lvmcache should not only be used between suspend and resume, but between sequential LV operations in clvmd, so that clvmd does not need to reread the VG for each one. Prepare for that by renaming the stashed VG as "saved_vg".
2018-04-24 20:18:22 +03:00
_saved_vg_free(vginfo, 1, 1);
lvmcache: simplify metadata cache The copy of VG metadata stored in lvmcache was not being used in general. It pretended to be a generic VG metadata cache, but was not being used except for clvmd activation. There it was used to avoid reading from disk while devices were suspended, i.e. in resume. This removes the code that attempted to make this look like a generic metadata cache, and replaces with with something narrowly targetted to what it's actually used for. This is a way of passing the VG from suspend to resume in clvmd. Since in the case of clvmd one caller can't simply pass the same VG to both suspend and resume, suspend needs to stash the VG somewhere that resume can grab it from. (resume doesn't want to read it from disk since devices are suspended.) The lvmcache vginfo struct is used as a convenient place to stash the VG to pass it from suspend to resume, even though it isn't related to the lvmcache or vginfo. These suspended_vg* vginfo fields should not be used or touched anywhere else, they are only to be used for passing the VG data from suspend to resume in clvmd. The VG data being passed between suspend and resume is never modified, and will only exist in the brief period between suspend and resume in clvmd. suspend has both old (current) and new (precommitted) copies of the VG metadata. It stashes both of these in the vginfo prior to suspending devices. When vg_commit is successful, it sets a flag in vginfo as before, signaling the transition from old to new metadata. resume grabs the VG stashed by suspend. If the vg_commit happened, it grabs the new VG, and if the vg_commit didn't happen it grabs the old VG. The VG is then used to resume LVs. This isolates clvmd-specific code and usage from the normal lvm vg_read code, making the code simpler and the behavior easier to verify. Sequence of operations: - lv_suspend() has both vg_old and vg_new and stashes a copy of each onto the vginfo: lvmcache_save_suspended_vg(vg_old); lvmcache_save_suspended_vg(vg_new); - vg_commit() happens, which causes all clvmd instances to call lvmcache_commit_metadata(vg). A flag is set in the vginfo indicating the transition from the old to new VG: vginfo->suspended_vg_committed = 1; - lv_resume() needs either vg_old or vg_new to use in resuming LVs. It doesn't want to read the VG from disk since devices are suspended, so it gets the VG stashed by lv_suspend: vg = lvmcache_get_suspended_vg(vgid); If the vg_commit did not happen, suspended_vg_committed will not be set, and in this case, lvmcache_get_suspended_vg() will return the old VG instead of the new VG, and it will resume LVs based on the old metadata.
2017-11-01 17:35:40 +03:00
}
lvmcache: rename suspended_vg to saved_vg The copy of the VG which clvmd stashes in lvmcache should not only be used between suspend and resume, but between sequential LV operations in clvmd, so that clvmd does not need to reread the VG for each one. Prepare for that by renaming the stashed VG as "saved_vg".
2018-04-24 20:18:22 +03:00
void lvmcache_save_vg(struct volume_group *vg, int precommitted)
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
{
struct lvmcache_vginfo *vginfo;
struct format_instance *fid;
struct format_instance_ctx fic;
clvmd: reuse a vg struct for sequential LV operations After reading a VG, stash it in lvmcache as "saved_vg". Before reading the VG again, try to use the saved_vg. The saved_vg is dropped on VG lock operations.
2018-04-24 21:19:48 +03:00
struct volume_group *save_vg = NULL;
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
struct dm_config_tree *susp_cft = NULL;
char *susp_buf = NULL;
size_t size;
int new = precommitted;
int old = !precommitted;
if (!(vginfo = lvmcache_vginfo_from_vgid((const char *)&vg->id)))
goto_bad;
/* already saved */
lvmcache: rename suspended_vg to saved_vg The copy of the VG which clvmd stashes in lvmcache should not only be used between suspend and resume, but between sequential LV operations in clvmd, so that clvmd does not need to reread the VG for each one. Prepare for that by renaming the stashed VG as "saved_vg".
2018-04-24 20:18:22 +03:00
if (old && vginfo->saved_vg_old &&
(vginfo->saved_vg_old->seqno == vg->seqno))
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
return;
/* already saved */
lvmcache: rename suspended_vg to saved_vg The copy of the VG which clvmd stashes in lvmcache should not only be used between suspend and resume, but between sequential LV operations in clvmd, so that clvmd does not need to reread the VG for each one. Prepare for that by renaming the stashed VG as "saved_vg".
2018-04-24 20:18:22 +03:00
if (new && vginfo->saved_vg_new &&
(vginfo->saved_vg_new->seqno == vg->seqno))
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
return;
lvmcache: rename suspended_vg to saved_vg The copy of the VG which clvmd stashes in lvmcache should not only be used between suspend and resume, but between sequential LV operations in clvmd, so that clvmd does not need to reread the VG for each one. Prepare for that by renaming the stashed VG as "saved_vg".
2018-04-24 20:18:22 +03:00
_saved_vg_free(vginfo, old, new);
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
if (!(size = export_vg_to_buffer(vg, &susp_buf)))
goto_bad;
fic.type = FMT_INSTANCE_MDAS | FMT_INSTANCE_AUX_MDAS;
fic.context.vg_ref.vg_name = vginfo->vgname;
fic.context.vg_ref.vg_id = vginfo->vgid;
if (!(fid = vginfo->fmt->ops->create_instance(vginfo->fmt, &fic)))
goto_bad;
if (!(susp_cft = config_tree_from_string_without_dup_node_check(susp_buf)))
goto_bad;
clvmd: reuse a vg struct for sequential LV operations After reading a VG, stash it in lvmcache as "saved_vg". Before reading the VG again, try to use the saved_vg. The saved_vg is dropped on VG lock operations.
2018-04-24 21:19:48 +03:00
if (!(save_vg = import_vg_from_config_tree(susp_cft, fid)))
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
goto_bad;
clvmd: reuse a vg struct for sequential LV operations After reading a VG, stash it in lvmcache as "saved_vg". Before reading the VG again, try to use the saved_vg. The saved_vg is dropped on VG lock operations.
2018-04-24 21:19:48 +03:00
save_vg->saved_in_clvmd = 1;
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
if (old) {
lvmcache: rename suspended_vg to saved_vg The copy of the VG which clvmd stashes in lvmcache should not only be used between suspend and resume, but between sequential LV operations in clvmd, so that clvmd does not need to reread the VG for each one. Prepare for that by renaming the stashed VG as "saved_vg".
2018-04-24 20:18:22 +03:00
vginfo->saved_vg_old_buf = susp_buf;
vginfo->saved_vg_old_cft = susp_cft;
clvmd: reuse a vg struct for sequential LV operations After reading a VG, stash it in lvmcache as "saved_vg". Before reading the VG again, try to use the saved_vg. The saved_vg is dropped on VG lock operations.
2018-04-24 21:19:48 +03:00
vginfo->saved_vg_old = save_vg;
clvmd: drop old saved_vg when returning new saved_vg In some pvmove tests, clvmd uses the new (precommitted) saved_vg, but then requests the old saved_vg, and expects that the new saved_vg be returned instead of the old. So, when returning the new saved_vg, forget the old one so we don't return it again.
2018-04-26 22:41:57 +03:00
log_debug_cache("lvmcache saved old vg %s seqno %d %p",
clvmd: reuse a vg struct for sequential LV operations After reading a VG, stash it in lvmcache as "saved_vg". Before reading the VG again, try to use the saved_vg. The saved_vg is dropped on VG lock operations.
2018-04-24 21:19:48 +03:00
save_vg->name, save_vg->seqno, save_vg);
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
} else {
lvmcache: rename suspended_vg to saved_vg The copy of the VG which clvmd stashes in lvmcache should not only be used between suspend and resume, but between sequential LV operations in clvmd, so that clvmd does not need to reread the VG for each one. Prepare for that by renaming the stashed VG as "saved_vg".
2018-04-24 20:18:22 +03:00
vginfo->saved_vg_new_buf = susp_buf;
vginfo->saved_vg_new_cft = susp_cft;
clvmd: reuse a vg struct for sequential LV operations After reading a VG, stash it in lvmcache as "saved_vg". Before reading the VG again, try to use the saved_vg. The saved_vg is dropped on VG lock operations.
2018-04-24 21:19:48 +03:00
vginfo->saved_vg_new = save_vg;
log_debug_cache("lvmcache saved pre vg %s seqno %d %p",
save_vg->name, save_vg->seqno, save_vg);
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
}
return;
bad:
lvmcache: rename suspended_vg to saved_vg The copy of the VG which clvmd stashes in lvmcache should not only be used between suspend and resume, but between sequential LV operations in clvmd, so that clvmd does not need to reread the VG for each one. Prepare for that by renaming the stashed VG as "saved_vg".
2018-04-24 20:18:22 +03:00
_saved_vg_free(vginfo, old, new);
clvmd: reuse a vg struct for sequential LV operations After reading a VG, stash it in lvmcache as "saved_vg". Before reading the VG again, try to use the saved_vg. The saved_vg is dropped on VG lock operations.
2018-04-24 21:19:48 +03:00
log_debug_cache("lvmcache failed to save pre %d vg %s", precommitted, vg->name);
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
}
clvmd: reuse a vg struct for sequential LV operations After reading a VG, stash it in lvmcache as "saved_vg". Before reading the VG again, try to use the saved_vg. The saved_vg is dropped on VG lock operations.
2018-04-24 21:19:48 +03:00
struct volume_group *lvmcache_get_saved_vg(const char *vgid, int precommitted)
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
{
struct lvmcache_vginfo *vginfo;
clvmd: reuse a vg struct for sequential LV operations After reading a VG, stash it in lvmcache as "saved_vg". Before reading the VG again, try to use the saved_vg. The saved_vg is dropped on VG lock operations.
2018-04-24 21:19:48 +03:00
struct volume_group *vg = NULL;
int new = precommitted;
int old = !precommitted;
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
if (!(vginfo = lvmcache_vginfo_from_vgid(vgid)))
clvmd: reuse a vg struct for sequential LV operations After reading a VG, stash it in lvmcache as "saved_vg". Before reading the VG again, try to use the saved_vg. The saved_vg is dropped on VG lock operations.
2018-04-24 21:19:48 +03:00
goto out;
clvmd: drop old saved_vg when returning new saved_vg In some pvmove tests, clvmd uses the new (precommitted) saved_vg, but then requests the old saved_vg, and expects that the new saved_vg be returned instead of the old. So, when returning the new saved_vg, forget the old one so we don't return it again.
2018-04-26 22:41:57 +03:00
/*
* Once new is returned, then also return new if old is requested,
* i.e. new becomes both old and new once it's used.
*/
clvmd: reuse a vg struct for sequential LV operations After reading a VG, stash it in lvmcache as "saved_vg". Before reading the VG again, try to use the saved_vg. The saved_vg is dropped on VG lock operations.
2018-04-24 21:19:48 +03:00
if (new)
vg = vginfo->saved_vg_new;
else if (old)
vg = vginfo->saved_vg_old;
clvmd: drop old saved_vg when returning new saved_vg In some pvmove tests, clvmd uses the new (precommitted) saved_vg, but then requests the old saved_vg, and expects that the new saved_vg be returned instead of the old. So, when returning the new saved_vg, forget the old one so we don't return it again.
2018-04-26 22:41:57 +03:00
if (vg && old) {
if (!vginfo->saved_vg_new)
log_debug_cache("lvmcache: get old saved_vg %d %s %p",
vg->seqno, vg->name, vg);
else
log_debug_cache("lvmcache: get old saved_vg %d %s %p new is %d %p",
vg->seqno, vg->name, vg,
vginfo->saved_vg_new->seqno,
vginfo->saved_vg_new);
}
if (vg && new) {
if (!vginfo->saved_vg_old)
log_debug_cache("lvmcache: get new (pre) saved_vg %d %s %p",
vg->seqno, vg->name, vg);
else
log_debug_cache("lvmcache: get new (pre) saved_vg %d %s %p old is %d %p",
vg->seqno, vg->name, vg,
vginfo->saved_vg_old->seqno,
vginfo->saved_vg_old);
/* Do we need to actually set saved_vg_old to match saved_vg_new?
* By just dropping old, we force a subsequent request for old to
* reread it rather than just using new. */
clvmd: keep old saved_vg if it matches new There is no need to release the old saved_vg if it matches the new version.
2018-04-30 21:00:05 +03:00
lvmcache: fix typo in lvmcache_get_saved_vg
2018-05-01 17:06:04 +03:00
if (vginfo->saved_vg_old && (vginfo->saved_vg_old->seqno < vg->seqno)) {
clvmd: drop old saved_vg when returning new saved_vg In some pvmove tests, clvmd uses the new (precommitted) saved_vg, but then requests the old saved_vg, and expects that the new saved_vg be returned instead of the old. So, when returning the new saved_vg, forget the old one so we don't return it again.
2018-04-26 22:41:57 +03:00
log_debug_cache("lvmcache: drop saved_vg_old because new invalidates");
_saved_vg_free(vginfo, 1, 0);
}
}
if (!vg && new && vginfo->saved_vg_old)
log_warn("lvmcache_get_saved_vg pre %d wanted new but only have old %d %s",
precommitted,
vginfo->saved_vg_old->seqno,
vginfo->saved_vg_old->name);
if (!vg && old && vginfo->saved_vg_new)
log_warn("lvmcache_get_saved_vg pre %d wanted old but only have new %d %s",
precommitted,
vginfo->saved_vg_new->seqno,
vginfo->saved_vg_new->name);
clvmd: reuse a vg struct for sequential LV operations After reading a VG, stash it in lvmcache as "saved_vg". Before reading the VG again, try to use the saved_vg. The saved_vg is dropped on VG lock operations.
2018-04-24 21:19:48 +03:00
out:
if (!vg)
log_debug_cache("lvmcache no saved vg %s pre %d", vgid, precommitted);
return vg;
}
struct volume_group *lvmcache_get_saved_vg_latest(const char *vgid)
{
struct lvmcache_vginfo *vginfo;
struct volume_group *vg = NULL;
clvmd: drop old saved_vg when returning new saved_vg In some pvmove tests, clvmd uses the new (precommitted) saved_vg, but then requests the old saved_vg, and expects that the new saved_vg be returned instead of the old. So, when returning the new saved_vg, forget the old one so we don't return it again.
2018-04-26 22:41:57 +03:00
int old = 0;
int new = 0;
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
clvmd: reuse a vg struct for sequential LV operations After reading a VG, stash it in lvmcache as "saved_vg". Before reading the VG again, try to use the saved_vg. The saved_vg is dropped on VG lock operations.
2018-04-24 21:19:48 +03:00
if (!(vginfo = lvmcache_vginfo_from_vgid(vgid)))
goto out;
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
clvmd: drop old saved_vg when returning new saved_vg In some pvmove tests, clvmd uses the new (precommitted) saved_vg, but then requests the old saved_vg, and expects that the new saved_vg be returned instead of the old. So, when returning the new saved_vg, forget the old one so we don't return it again.
2018-04-26 22:41:57 +03:00
if (vginfo->saved_vg_committed) {
clvmd: reuse a vg struct for sequential LV operations After reading a VG, stash it in lvmcache as "saved_vg". Before reading the VG again, try to use the saved_vg. The saved_vg is dropped on VG lock operations.
2018-04-24 21:19:48 +03:00
vg = vginfo->saved_vg_new;
clvmd: drop old saved_vg when returning new saved_vg In some pvmove tests, clvmd uses the new (precommitted) saved_vg, but then requests the old saved_vg, and expects that the new saved_vg be returned instead of the old. So, when returning the new saved_vg, forget the old one so we don't return it again.
2018-04-26 22:41:57 +03:00
new = 1;
} else {
clvmd: reuse a vg struct for sequential LV operations After reading a VG, stash it in lvmcache as "saved_vg". Before reading the VG again, try to use the saved_vg. The saved_vg is dropped on VG lock operations.
2018-04-24 21:19:48 +03:00
vg = vginfo->saved_vg_old;
clvmd: drop old saved_vg when returning new saved_vg In some pvmove tests, clvmd uses the new (precommitted) saved_vg, but then requests the old saved_vg, and expects that the new saved_vg be returned instead of the old. So, when returning the new saved_vg, forget the old one so we don't return it again.
2018-04-26 22:41:57 +03:00
old = 1;
}
if (vg && old) {
if (!vginfo->saved_vg_new)
log_debug_cache("lvmcache: get_latest old saved_vg %d %s %p",
vg->seqno, vg->name, vg);
else
log_debug_cache("lvmcache: get_latest old saved_vg %d %s %p new is %d %p",
vg->seqno, vg->name, vg,
vginfo->saved_vg_new->seqno,
vginfo->saved_vg_new);
}
if (vg && new) {
if (!vginfo->saved_vg_old)
log_debug_cache("lvmcache: get_latest new (pre) saved_vg %d %s %p",
vg->seqno, vg->name, vg);
else
log_debug_cache("lvmcache: get_latest new (pre) saved_vg %d %s %p old is %d %p",
vg->seqno, vg->name, vg,
vginfo->saved_vg_old->seqno,
vginfo->saved_vg_old);
/* Do we need to actually set saved_vg_old to match saved_vg_new?
* By just dropping old, we force a subsequent request for old to
* reread it rather than just using new. */
clvmd: keep old saved_vg if it matches new There is no need to release the old saved_vg if it matches the new version.
2018-04-30 21:00:05 +03:00
if (vginfo->saved_vg_old && (vginfo->saved_vg_old->seqno < vg->seqno)) {
clvmd: drop old saved_vg when returning new saved_vg In some pvmove tests, clvmd uses the new (precommitted) saved_vg, but then requests the old saved_vg, and expects that the new saved_vg be returned instead of the old. So, when returning the new saved_vg, forget the old one so we don't return it again.
2018-04-26 22:41:57 +03:00
log_debug_cache("lvmcache: drop saved_vg_old because new invalidates");
_saved_vg_free(vginfo, 1, 0);
}
}
clvmd: reuse a vg struct for sequential LV operations After reading a VG, stash it in lvmcache as "saved_vg". Before reading the VG again, try to use the saved_vg. The saved_vg is dropped on VG lock operations.
2018-04-24 21:19:48 +03:00
out:
if (!vg)
log_debug_cache("lvmcache no saved vg %s", vgid);
return vg;
lvmcache: simplify metadata cache The copy of VG metadata stored in lvmcache was not being used in general. It pretended to be a generic VG metadata cache, but was not being used except for clvmd activation. There it was used to avoid reading from disk while devices were suspended, i.e. in resume. This removes the code that attempted to make this look like a generic metadata cache, and replaces with with something narrowly targetted to what it's actually used for. This is a way of passing the VG from suspend to resume in clvmd. Since in the case of clvmd one caller can't simply pass the same VG to both suspend and resume, suspend needs to stash the VG somewhere that resume can grab it from. (resume doesn't want to read it from disk since devices are suspended.) The lvmcache vginfo struct is used as a convenient place to stash the VG to pass it from suspend to resume, even though it isn't related to the lvmcache or vginfo. These suspended_vg* vginfo fields should not be used or touched anywhere else, they are only to be used for passing the VG data from suspend to resume in clvmd. The VG data being passed between suspend and resume is never modified, and will only exist in the brief period between suspend and resume in clvmd. suspend has both old (current) and new (precommitted) copies of the VG metadata. It stashes both of these in the vginfo prior to suspending devices. When vg_commit is successful, it sets a flag in vginfo as before, signaling the transition from old to new metadata. resume grabs the VG stashed by suspend. If the vg_commit happened, it grabs the new VG, and if the vg_commit didn't happen it grabs the old VG. The VG is then used to resume LVs. This isolates clvmd-specific code and usage from the normal lvm vg_read code, making the code simpler and the behavior easier to verify. Sequence of operations: - lv_suspend() has both vg_old and vg_new and stashes a copy of each onto the vginfo: lvmcache_save_suspended_vg(vg_old); lvmcache_save_suspended_vg(vg_new); - vg_commit() happens, which causes all clvmd instances to call lvmcache_commit_metadata(vg). A flag is set in the vginfo indicating the transition from the old to new VG: vginfo->suspended_vg_committed = 1; - lv_resume() needs either vg_old or vg_new to use in resuming LVs. It doesn't want to read the VG from disk since devices are suspended, so it gets the VG stashed by lv_suspend: vg = lvmcache_get_suspended_vg(vgid); If the vg_commit did not happen, suspended_vg_committed will not be set, and in this case, lvmcache_get_suspended_vg() will return the old VG instead of the new VG, and it will resume LVs based on the old metadata.
2017-11-01 17:35:40 +03:00
}
lvmcache: rename suspended_vg to saved_vg The copy of the VG which clvmd stashes in lvmcache should not only be used between suspend and resume, but between sequential LV operations in clvmd, so that clvmd does not need to reread the VG for each one. Prepare for that by renaming the stashed VG as "saved_vg".
2018-04-24 20:18:22 +03:00
void lvmcache_drop_saved_vg(struct volume_group *vg)
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
{
struct lvmcache_vginfo *vginfo;
if (!(vginfo = lvmcache_vginfo_from_vgid((const char *)&vg->id)))
return;
lvmcache: rename suspended_vg to saved_vg The copy of the VG which clvmd stashes in lvmcache should not only be used between suspend and resume, but between sequential LV operations in clvmd, so that clvmd does not need to reread the VG for each one. Prepare for that by renaming the stashed VG as "saved_vg".
2018-04-24 20:18:22 +03:00
_saved_vg_free(vginfo, 1, 1);
Drop cached VG metadata before and after committing changes to it.
2008-04-15 18:46:19 +04:00
}
clvmd: reuse a vg struct for sequential LV operations After reading a VG, stash it in lvmcache as "saved_vg". Before reading the VG again, try to use the saved_vg. The saved_vg is dropped on VG lock operations.
2018-04-24 21:19:48 +03:00
void lvmcache_drop_saved_vgid(const char *vgid)
{
struct lvmcache_vginfo *vginfo;
if (!(vginfo = lvmcache_vginfo_from_vgid(vgid)))
return;
_saved_vg_free(vginfo, 1, 1);
}
Add possibility to handle precommitted metadata in lvmcache. - Add drop_precommitted flag to force drop precommitted metadata - add lvmcache_commit_metadata() which upgrades precommitted metadata in cache No functional change in this patch - just preparation for following change.
2010-01-05 19:06:42 +03:00
/*
cleanup: spelling
2014-02-22 03:23:59 +04:00
* Remote node uses this to upgrade precommitted metadata to commited state
Add possibility to handle precommitted metadata in lvmcache. - Add drop_precommitted flag to force drop precommitted metadata - add lvmcache_commit_metadata() which upgrades precommitted metadata in cache No functional change in this patch - just preparation for following change.
2010-01-05 19:06:42 +03:00
* when receives vg_commit notification.
cleanup: spelling
2014-02-22 03:23:59 +04:00
* (Note that devices can be suspended here, if so, precommitted metadata are already read.)
Add possibility to handle precommitted metadata in lvmcache. - Add drop_precommitted flag to force drop precommitted metadata - add lvmcache_commit_metadata() which upgrades precommitted metadata in cache No functional change in this patch - just preparation for following change.
2010-01-05 19:06:42 +03:00
*/
void lvmcache_commit_metadata(const char *vgname)
{
struct lvmcache_vginfo *vginfo;
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
if (!(vginfo = lvmcache_vginfo_from_vgname(vgname, NULL)))
Add possibility to handle precommitted metadata in lvmcache. - Add drop_precommitted flag to force drop precommitted metadata - add lvmcache_commit_metadata() which upgrades precommitted metadata in cache No functional change in this patch - just preparation for following change.
2010-01-05 19:06:42 +03:00
return;
lvmcache: rename suspended_vg to saved_vg The copy of the VG which clvmd stashes in lvmcache should not only be used between suspend and resume, but between sequential LV operations in clvmd, so that clvmd does not need to reread the VG for each one. Prepare for that by renaming the stashed VG as "saved_vg".
2018-04-24 20:18:22 +03:00
vginfo->saved_vg_committed = 1;
Add possibility to handle precommitted metadata in lvmcache. - Add drop_precommitted flag to force drop precommitted metadata - add lvmcache_commit_metadata() which upgrades precommitted metadata in cache No functional change in this patch - just preparation for following change.
2010-01-05 19:06:42 +03:00
}
void lvmcache_drop_metadata(const char *vgname, int drop_precommitted)
When asked to drop cached committed VG metadata, invalidate cached PV labels.
2008-05-08 22:28:27 +04:00
{
Revert "lvmcache: skip drop when vg_write lock is not held" This reverts e28e22b9e1e4f7243608aa24ddf43ec63afd1751 The problem that that commit was fixing (pytest failure) no longer appears with the current code, so the commit is not needed. That commit is a problem for pvchange, because it prevents lvmcache from retaining VG metadata even while the global lock is held. pvchange holds the global lock to ensure that VG metadata is kept in lvmcache throughout processing. If the cache is not kept, a PV with zero MDAs will appear first in its actual VG and then appear again in the orphan VG. It wrongly appears a second time in the orphan VG only if the actual VG is dropped from lvmcache.
2016-01-14 22:26:15 +03:00
if (lvmcache_vgname_is_locked(VG_GLOBAL))
cache: Retain orphans while global lock held. Fixes segfault when 'pvs' encounters two different PVs sharing the same uuid but one an orphan, the other in a VG. If VG_GLOBAL is held, there seems no point in doing a full scan more than once. If undesirable side-effects show up, we can try restricting this to VG_GLOBAL READ locks. The original code dates back to 2.02.40.
2015-03-19 02:20:09 +03:00
return;
When asked to drop cached committed VG metadata, invalidate cached PV labels.
2008-05-08 22:28:27 +04:00
/* For VG_ORPHANS, we need to invalidate all labels on orphan PVs. */
Add missing mutex around clvmd lvmcache_drop_metadata library call.
2008-05-09 19:13:20 +04:00
if (!strcmp(vgname, VG_ORPHANS)) {
Add possibility to handle precommitted metadata in lvmcache. - Add drop_precommitted flag to force drop precommitted metadata - add lvmcache_commit_metadata() which upgrades precommitted metadata in cache No functional change in this patch - just preparation for following change.
2010-01-05 19:06:42 +03:00
_drop_metadata(FMT_TEXT_ORPHAN_VG_NAME, 0);
cache: Retain orphans while global lock held. Fixes segfault when 'pvs' encounters two different PVs sharing the same uuid but one an orphan, the other in a VG. If VG_GLOBAL is held, there seems no point in doing a full scan more than once. If undesirable side-effects show up, we can try restricting this to VG_GLOBAL READ locks. The original code dates back to 2.02.40.
2015-03-19 02:20:09 +03:00
} else
Add possibility to handle precommitted metadata in lvmcache. - Add drop_precommitted flag to force drop precommitted metadata - add lvmcache_commit_metadata() which upgrades precommitted metadata in cache No functional change in this patch - just preparation for following change.
2010-01-05 19:06:42 +03:00
_drop_metadata(vgname, drop_precommitted);
When asked to drop cached committed VG metadata, invalidate cached PV labels.
2008-05-08 22:28:27 +04:00
}
Enforce an alphabetical lock ordering for vgname locks. Add a new constraint that vgname locks must be obtained in alphabetical order. At this point, we have test coverage for the 3 commands affected - vgsplit, vgmerge, and vgrename. Tests have been updated to cover these commands. Going forward any command or library call that must obtain more than one vgname lock must do so in alphabetical order. Future patches will update lvm2app to enforce this ordering. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-09-03 01:34:11 +04:00
/*
* Ensure vgname2 comes after vgname1 alphabetically.
Validate orphan and VG_GLOBAL lock order too.
2010-05-19 06:08:50 +04:00
* Orphan locks come last.
* VG_GLOBAL comes first.
Enforce an alphabetical lock ordering for vgname locks. Add a new constraint that vgname locks must be obtained in alphabetical order. At this point, we have test coverage for the 3 commands affected - vgsplit, vgmerge, and vgrename. Tests have been updated to cover these commands. Going forward any command or library call that must obtain more than one vgname lock must do so in alphabetical order. Future patches will update lvm2app to enforce this ordering. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-09-03 01:34:11 +04:00
*/
static int _vgname_order_correct(const char *vgname1, const char *vgname2)
{
Validate orphan and VG_GLOBAL lock order too.
2010-05-19 06:08:50 +04:00
if (is_global_vg(vgname1))
return 1;
if (is_global_vg(vgname2))
return 0;
if (is_orphan_vg(vgname1))
return 0;
if (is_orphan_vg(vgname2))
Enforce an alphabetical lock ordering for vgname locks. Add a new constraint that vgname locks must be obtained in alphabetical order. At this point, we have test coverage for the 3 commands affected - vgsplit, vgmerge, and vgrename. Tests have been updated to cover these commands. Going forward any command or library call that must obtain more than one vgname lock must do so in alphabetical order. Future patches will update lvm2app to enforce this ordering. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-09-03 01:34:11 +04:00
return 1;
if (strcmp(vgname1, vgname2) < 0)
return 1;
pre-release cleanup
2009-09-15 17:49:10 +04:00
Enforce an alphabetical lock ordering for vgname locks. Add a new constraint that vgname locks must be obtained in alphabetical order. At this point, we have test coverage for the 3 commands affected - vgsplit, vgmerge, and vgrename. Tests have been updated to cover these commands. Going forward any command or library call that must obtain more than one vgname lock must do so in alphabetical order. Future patches will update lvm2app to enforce this ordering. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-09-03 01:34:11 +04:00
return 0;
}
vgrename: use process_each_vg Use process_each_vg() to lock and read the old VG, and then call the main vgrename code. When real VG names are used (not a UUID in place of the old name), the command still pre-locks the new name (when strcmp wants it locked first), before calling process_each_vg on the old name. In the case where the old name is replaced with a UUID, process_each_vg now translates that UUID into the real VG name, which it locks and reads. In this case, we cannot do pre-locking to maintain lock ordering because the old name is unknown. So, in this case the strcmp based lock ordering is suppressed and the old name is always locked first. This opens a remote chance for lock ordering conflict between racing vgrenames between two names where one or both commands use the UUID.
2015-12-01 23:09:01 +03:00
void lvmcache_lock_ordering(int enable)
{
_suppress_lock_ordering = !enable;
}
Enforce an alphabetical lock ordering for vgname locks. Add a new constraint that vgname locks must be obtained in alphabetical order. At this point, we have test coverage for the 3 commands affected - vgsplit, vgmerge, and vgrename. Tests have been updated to cover these commands. Going forward any command or library call that must obtain more than one vgname lock must do so in alphabetical order. Future patches will update lvm2app to enforce this ordering. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-09-03 01:34:11 +04:00
/*
* Ensure VG locks are acquired in alphabetical order.
*/
int lvmcache_verify_lock_order(const char *vgname)
{
struct dm_hash_node *n;
const char *vgname2;
vgrename: use process_each_vg Use process_each_vg() to lock and read the old VG, and then call the main vgrename code. When real VG names are used (not a UUID in place of the old name), the command still pre-locks the new name (when strcmp wants it locked first), before calling process_each_vg on the old name. In the case where the old name is replaced with a UUID, process_each_vg now translates that UUID into the real VG name, which it locks and reads. In this case, we cannot do pre-locking to maintain lock ordering because the old name is unknown. So, in this case the strcmp based lock ordering is suppressed and the old name is always locked first. This opens a remote chance for lock ordering conflict between racing vgrenames between two names where one or both commands use the UUID.
2015-12-01 23:09:01 +03:00
if (_suppress_lock_ordering)
return 1;
Enforce an alphabetical lock ordering for vgname locks. Add a new constraint that vgname locks must be obtained in alphabetical order. At this point, we have test coverage for the 3 commands affected - vgsplit, vgmerge, and vgrename. Tests have been updated to cover these commands. Going forward any command or library call that must obtain more than one vgname lock must do so in alphabetical order. Future patches will update lvm2app to enforce this ordering. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-09-03 01:34:11 +04:00
if (!_lock_hash)
scan: drop bcache between lvm shell commands A running lvm shell keeps all lvm devices open unless the bcache is dropped.
2018-04-06 21:05:17 +03:00
return 1;
Enforce an alphabetical lock ordering for vgname locks. Add a new constraint that vgname locks must be obtained in alphabetical order. At this point, we have test coverage for the 3 commands affected - vgsplit, vgmerge, and vgrename. Tests have been updated to cover these commands. Going forward any command or library call that must obtain more than one vgname lock must do so in alphabetical order. Future patches will update lvm2app to enforce this ordering. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-09-03 01:34:11 +04:00
dm_hash_iterate(n, _lock_hash) {
if (!dm_hash_get_data(_lock_hash, n))
return_0;
pre-release cleanup
2009-09-15 17:49:10 +04:00
Add internal error to guard vgname2 NULL dereference
2012-02-13 18:26:15 +04:00
if (!(vgname2 = dm_hash_get_key(_lock_hash, n))) {
log_error(INTERNAL_ERROR "VG lock %s hits NULL.",
vgname);
return 0;
}
pre-release cleanup
2009-09-15 17:49:10 +04:00
Enforce an alphabetical lock ordering for vgname locks. Add a new constraint that vgname locks must be obtained in alphabetical order. At this point, we have test coverage for the 3 commands affected - vgsplit, vgmerge, and vgrename. Tests have been updated to cover these commands. Going forward any command or library call that must obtain more than one vgname lock must do so in alphabetical order. Future patches will update lvm2app to enforce this ordering. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-09-03 01:34:11 +04:00
if (!_vgname_order_correct(vgname2, vgname)) {
#define an INTERNAL_ERROR macro and use it throughout LVM.
2009-12-16 22:22:11 +03:00
log_errno(EDEADLK, INTERNAL_ERROR "VG lock %s must "
Enforce an alphabetical lock ordering for vgname locks. Add a new constraint that vgname locks must be obtained in alphabetical order. At this point, we have test coverage for the 3 commands affected - vgsplit, vgmerge, and vgrename. Tests have been updated to cover these commands. Going forward any command or library call that must obtain more than one vgname lock must do so in alphabetical order. Future patches will update lvm2app to enforce this ordering. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-09-03 01:34:11 +04:00
"be requested before %s, not after.",
vgname, vgname2);
Add internal error to guard vgname2 NULL dereference
2012-02-13 18:26:15 +04:00
return 0;
Enforce an alphabetical lock ordering for vgname locks. Add a new constraint that vgname locks must be obtained in alphabetical order. At this point, we have test coverage for the 3 commands affected - vgsplit, vgmerge, and vgrename. Tests have been updated to cover these commands. Going forward any command or library call that must obtain more than one vgname lock must do so in alphabetical order. Future patches will update lvm2app to enforce this ordering. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-09-03 01:34:11 +04:00
}
}
pre-release cleanup
2009-09-15 17:49:10 +04:00
Enforce an alphabetical lock ordering for vgname locks. Add a new constraint that vgname locks must be obtained in alphabetical order. At this point, we have test coverage for the 3 commands affected - vgsplit, vgmerge, and vgrename. Tests have been updated to cover these commands. Going forward any command or library call that must obtain more than one vgname lock must do so in alphabetical order. Future patches will update lvm2app to enforce this ordering. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-09-03 01:34:11 +04:00
return 1;
}
Use __attribute__ consistently throughout.
2010-07-09 19:34:40 +04:00
void lvmcache_lock_vgname(const char *vgname, int read_only __attribute__((unused)))
A new cache.
2002-11-18 16:53:58 +03:00
{
Another sync point - numerous fixes & clean ups.
2003-07-05 02:34:56 +04:00
if (!_lock_hash && !lvmcache_init()) {
log_error("Internal cache initialisation failed");
return;
}
Add some basic internal VG lock validation.
2008-04-03 22:56:40 +04:00
if (dm_hash_lookup(_lock_hash, vgname))
#define an INTERNAL_ERROR macro and use it throughout LVM.
2009-12-16 22:22:11 +03:00
log_error(INTERNAL_ERROR "Nested locking attempted on VG %s.",
Add some basic internal VG lock validation.
2008-04-03 22:56:40 +04:00
vgname);
Enforce an alphabetical lock ordering for vgname locks. Add a new constraint that vgname locks must be obtained in alphabetical order. At this point, we have test coverage for the 3 commands affected - vgsplit, vgmerge, and vgrename. Tests have been updated to cover these commands. Going forward any command or library call that must obtain more than one vgname lock must do so in alphabetical order. Future patches will update lvm2app to enforce this ordering. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-09-03 01:34:11 +04:00
Use hash, bitset, malloc, pool from libdevmapper.
2005-10-17 03:03:59 +04:00
if (!dm_hash_insert(_lock_hash, vgname, (void *) 1))
Another sync point - numerous fixes & clean ups.
2003-07-05 02:34:56 +04:00
log_error("Cache locking failure for %s", vgname);
lvmcache: Skip VG_GLOBAL cache lock state update. Avoids message: Metadata cache has no info for vgname: "#global"
2014-10-07 03:30:28 +04:00
if (strcmp(vgname, VG_GLOBAL)) {
_update_cache_lock_state(vgname, 1);
Exclude VG_GLOBAL from internal concurrent VG lock counter. (Avoids 'device left open' warning messages from vgscan etc.)
2008-04-24 06:22:07 +04:00
_vgs_locked++;
lvmcache: Skip VG_GLOBAL cache lock state update. Avoids message: Metadata cache has no info for vgname: "#global"
2014-10-07 03:30:28 +04:00
}
Another sync point - numerous fixes & clean ups.
2003-07-05 02:34:56 +04:00
}
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
int lvmcache_vgname_is_locked(const char *vgname)
Another sync point - numerous fixes & clean ups.
2003-07-05 02:34:56 +04:00
{
if (!_lock_hash)
return 0;
Accept orphan VG names as parameters to lock_vol() and related functions.
2010-05-19 05:16:40 +04:00
return dm_hash_lookup(_lock_hash, is_orphan_vg(vgname) ? VG_ORPHANS : vgname) ? 1 : 0;
Another sync point - numerous fixes & clean ups.
2003-07-05 02:34:56 +04:00
}
void lvmcache_unlock_vgname(const char *vgname)
{
Add some basic internal VG lock validation.
2008-04-03 22:56:40 +04:00
if (!dm_hash_lookup(_lock_hash, vgname))
#define an INTERNAL_ERROR macro and use it throughout LVM.
2009-12-16 22:22:11 +03:00
log_error(INTERNAL_ERROR "Attempt to unlock unlocked VG %s.",
Add some basic internal VG lock validation.
2008-04-03 22:56:40 +04:00
vgname);
lvmcache: Skip VG_GLOBAL cache lock state update. Avoids message: Metadata cache has no info for vgname: "#global"
2014-10-07 03:30:28 +04:00
if (strcmp(vgname, VG_GLOBAL))
_update_cache_lock_state(vgname, 0);
Rely upon internally-cached PV labels while corresponding VG lock is held.
2008-01-30 02:45:48 +03:00
Use hash, bitset, malloc, pool from libdevmapper.
2005-10-17 03:03:59 +04:00
dm_hash_remove(_lock_hash, vgname);
Another sync point - numerous fixes & clean ups.
2003-07-05 02:34:56 +04:00
/* FIXME Do this per-VG */
lvmcache: invalidate all cached dev sizes if all VGs got unlocked
2016-01-22 13:13:00 +03:00
if (strcmp(vgname, VG_GLOBAL) && !--_vgs_locked) {
Another sync point - numerous fixes & clean ups.
2003-07-05 02:34:56 +04:00
dev_close_all();
lvmcache: invalidate all cached dev sizes if all VGs got unlocked
2016-01-22 13:13:00 +03:00
dev_size_seqno_inc(); /* invalidate all cached dev sizes */
}
Another sync point - numerous fixes & clean ups.
2003-07-05 02:34:56 +04:00
}
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
int lvmcache_vgs_locked(void)
Another sync point - numerous fixes & clean ups.
2003-07-05 02:34:56 +04:00
{
return _vgs_locked;
}
toollib: search for duplicate PVs only when needed A full search for duplicate PVs in the case of pvs -a is only necessary when duplicates have previously been detected in lvmcache. Use a global variable from lvmcache to indicate that duplicate PVs exist, so we can skip the search for duplicates when none exist.
2015-01-14 23:38:05 +03:00
/*
* When lvmcache sees a duplicate PV, this is set.
* process_each_pv() can avoid searching for duplicates
* by checking this and seeing that no duplicate PVs exist.
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
*
*
* found_duplicate_pvs tells the process_each_pv code
* to search the devices list for duplicates, so that
* devices can be processed together with their
* duplicates (while processing the VG, rather than
* reporting pv->dev under the VG, and its duplicate
* outside the VG context.)
toollib: search for duplicate PVs only when needed A full search for duplicate PVs in the case of pvs -a is only necessary when duplicates have previously been detected in lvmcache. Use a global variable from lvmcache to indicate that duplicate PVs exist, so we can skip the search for duplicates when none exist.
2015-01-14 23:38:05 +03:00
*/
int lvmcache_found_duplicate_pvs(void)
{
return _found_duplicate_pvs;
}
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
int lvmcache_get_unused_duplicate_devs(struct cmd_context *cmd, struct dm_list *head)
{
struct device_list *devl, *devl2;
dm_list_iterate_items(devl, &_unused_duplicate_devs) {
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;
}
pvremove: allow clearing a duplicate PV Add a special case to allow modifying a duplicate PV to erase it with pvremove -ff.
2016-05-13 00:19:57 +03:00
void lvmcache_remove_unchosen_duplicate(struct device *dev)
{
struct device_list *devl;
dm_list_iterate_items(devl, &_unused_duplicate_devs) {
if (devl->dev == dev) {
dm_list_del(&devl->list);
return;
}
}
}
lvmcache: fix duplicate handling with multiple scans Some commands scan labels to populate lvmcache multiple times, i.e. lvmcache_init, scan labels to fill lvmcache, lvmcache_destroy, then later repeat Each time labels are scanned, duplicates are detected, and preferred devices are chosen. Each time this is done within a single command, we want to choose the same preferred devices. So, check for existing preferences when choosing preferred devices. This also fixes a problem with the list of unused duplicate devs when run in an lvm shell. The devs had been allocated from cmd memory, resulting in invalid list entries between commands.
2016-06-06 23:20:55 +03:00
static void _destroy_duplicate_device_list(struct dm_list *head)
{
struct device_list *devl, *devl2;
dm_list_iterate_items_safe(devl, devl2, head) {
dm_list_del(&devl->list);
dm_free(devl);
}
dm_list_init(head);
}
pvremove: allow clearing a duplicate PV Add a special case to allow modifying a duplicate PV to erase it with pvremove -ff.
2016-05-13 00:19:57 +03:00
Refactor some vginfo manipulation code.
2008-05-19 23:49:56 +04:00
static void _vginfo_attach_info(struct lvmcache_vginfo *vginfo,
struct lvmcache_info *info)
{
Avoid spurious duplicate VG messages referring to VGs that are gone. (untested)
2008-05-29 02:27:47 +04:00
if (!vginfo)
return;
Refactor some vginfo manipulation code.
2008-05-19 23:49:56 +04:00
info->vginfo = vginfo;
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
dm_list_add(&vginfo->infos, &info->list);
Refactor some vginfo manipulation code.
2008-05-19 23:49:56 +04:00
}
static void _vginfo_detach_info(struct lvmcache_info *info)
{
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
if (!dm_list_empty(&info->list)) {
dm_list_del(&info->list);
dm_list_init(&info->list);
Refactor some vginfo manipulation code.
2008-05-19 23:49:56 +04:00
}
info->vginfo = NULL;
}
If two or more VGs are found with the same name, use one that is not exported.
2006-04-12 21:54:11 +04:00
/* If vgid supplied, require a match. */
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
struct lvmcache_vginfo *lvmcache_vginfo_from_vgname(const char *vgname, const char *vgid)
Another sync point - numerous fixes & clean ups.
2003-07-05 02:34:56 +04:00
{
struct lvmcache_vginfo *vginfo;
A new cache.
2002-11-18 16:53:58 +03:00
cope with volatile vginfo in vg_read
2008-06-06 15:12:50 +04:00
if (!vgname)
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
return lvmcache_vginfo_from_vgid(vgid);
cope with volatile vginfo in vg_read
2008-06-06 15:12:50 +04:00
lvmcache: add mode debug prints Decorate NULL returns with debug_cache output so the debug log doesn't contain spurios <bactrace> line without any reason for it. Add internal errors when cache is misused.
2014-03-18 13:24:32 +04:00
if (!_vgname_hash) {
debug: unify some tracing messages Introduce FMTVGID - although it might be possibly better to ensure vgid is always \0 ended string. Unify some lvmcache reported messages.
2016-04-12 14:06:16 +03:00
log_debug_cache(INTERNAL_ERROR "Internal lvmcache is no yet initialized.");
A new cache.
2002-11-18 16:53:58 +03:00
return NULL;
lvmcache: add mode debug prints Decorate NULL returns with debug_cache output so the debug log doesn't contain spurios <bactrace> line without any reason for it. Add internal errors when cache is misused.
2014-03-18 13:24:32 +04:00
}
A new cache.
2002-11-18 16:53:58 +03:00
lvmcache: add mode debug prints Decorate NULL returns with debug_cache output so the debug log doesn't contain spurios <bactrace> line without any reason for it. Add internal errors when cache is misused.
2014-03-18 13:24:32 +04:00
if (!(vginfo = dm_hash_lookup(_vgname_hash, vgname))) {
debug: unify some tracing messages Introduce FMTVGID - although it might be possibly better to ensure vgid is always \0 ended string. Unify some lvmcache reported messages.
2016-04-12 14:06:16 +03:00
log_debug_cache("lvmcache has no info for vgname \"%s\"%s" FMTVGID ".",
vgname, (vgid) ? " with VGID " : "", (vgid) ? : "");
A new cache.
2002-11-18 16:53:58 +03:00
return NULL;
lvmcache: add mode debug prints Decorate NULL returns with debug_cache output so the debug log doesn't contain spurios <bactrace> line without any reason for it. Add internal errors when cache is misused.
2014-03-18 13:24:32 +04:00
}
A new cache.
2002-11-18 16:53:58 +03:00
If two or more VGs are found with the same name, use one that is not exported.
2006-04-12 21:54:11 +04:00
if (vgid)
Some whitespace tidy-ups.
2008-01-30 17:00:02 +03:00
do
Fix vgid string termination in recent cache code.
2006-04-21 18:44:33 +04:00
if (!strncmp(vgid, vginfo->vgid, ID_LEN))
If two or more VGs are found with the same name, use one that is not exported.
2006-04-12 21:54:11 +04:00
return vginfo;
while ((vginfo = vginfo->next));
lvmcache: add mode debug prints Decorate NULL returns with debug_cache output so the debug log doesn't contain spurios <bactrace> line without any reason for it. Add internal errors when cache is misused.
2014-03-18 13:24:32 +04:00
if (!vginfo)
debug: unify some tracing messages Introduce FMTVGID - although it might be possibly better to ensure vgid is always \0 ended string. Unify some lvmcache reported messages.
2016-04-12 14:06:16 +03:00
log_debug_cache("lvmcache has not found vgname \"%s\"%s" FMTVGID ".",
vgname, (vgid) ? " with VGID " : "", (vgid) ? : "");
lvmcache: add mode debug prints Decorate NULL returns with debug_cache output so the debug log doesn't contain spurios <bactrace> line without any reason for it. Add internal errors when cache is misused.
2014-03-18 13:24:32 +04:00
A new cache.
2002-11-18 16:53:58 +03:00
return vginfo;
}
The lvmetad client-side integration. Only active when use_lvmetad = 1 is set in lvm.conf *and* lvmetad is running.
2012-02-23 17:11:07 +04:00
const struct format_type *lvmcache_fmt_from_vgname(struct cmd_context *cmd,
const char *vgname, const char *vgid,
unsigned revalidate_labels)
A new cache.
2002-11-18 16:53:58 +03:00
{
Another sync point - numerous fixes & clean ups.
2003-07-05 02:34:56 +04:00
struct lvmcache_vginfo *vginfo;
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
struct lvmcache_info *info;
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
struct dm_list *devh, *tmp;
struct dm_list devs;
Improve detection of external changes affecting internal cache.
2005-03-22 01:40:35 +03:00
struct device_list *devl;
Remaing code suffling Move declaration to the front of function to follow coding rules.
2012-02-24 02:23:12 +04:00
struct volume_group *vg;
const struct format_type *fmt;
Use __attribute__ consistently throughout.
2010-07-09 19:34:40 +04:00
char vgid_found[ID_LEN + 1] __attribute__((aligned(8)));
A new cache.
2002-11-18 16:53:58 +03:00
The lvmetad client-side integration. Only active when use_lvmetad = 1 is set in lvm.conf *and* lvmetad is running.
2012-02-23 17:11:07 +04:00
if (!(vginfo = lvmcache_vginfo_from_vgname(vgname, vgid))) {
lvmetad: rework command connection setup and checking The lvmetad connection is created within the init_connections() path during command startup, rather than via the old lvmetad_active() check. The old lvmetad_active() checks are replaced with lvmetad_used() which is a simple check that tests if the command is using/connected to lvmetad. The old lvmetad_set_active(cmd, 0) calls, which stopped the command from using lvmetad (to revert to disk scanning), are replaced with lvmetad_make_unused(cmd).
2016-04-14 01:00:01 +03:00
if (!lvmetad_used())
The lvmetad client-side integration. Only active when use_lvmetad = 1 is set in lvm.conf *and* lvmetad is running.
2012-02-23 17:11:07 +04:00
return NULL; /* too bad */
/* If we don't have the info but we have lvmetad, we can ask
* there before failing. */
Remaing code suffling Move declaration to the front of function to follow coding rules.
2012-02-24 02:23:12 +04:00
if ((vg = lvmetad_vg_lookup(cmd, vgname, vgid))) {
fmt = vg->fid->fmt;
The lvmetad client-side integration. Only active when use_lvmetad = 1 is set in lvm.conf *and* lvmetad is running.
2012-02-23 17:11:07 +04:00
release_vg(vg);
return fmt;
}
A new cache.
2002-11-18 16:53:58 +03:00
return NULL;
The lvmetad client-side integration. Only active when use_lvmetad = 1 is set in lvm.conf *and* lvmetad is running.
2012-02-23 17:11:07 +04:00
}
A new cache.
2002-11-18 16:53:58 +03:00
Fix scanning of VGs without in-PV mdas. Set cmd->independent_metadata_areas if metadata/dirs or disk_areas in use. - Identify and record this state. Don't skip full scan when independent mdas are present even if memlock is set. - Clusters and OOM aren't supported, so no problem doing the proper scans. Avoid revalidating the label cache immediately after scanning. - A simple optimisation. Support scanning for a single VG in independent mdas. - Not used by the fix but I left it in anyway as later patches might use it.
2010-12-11 01:39:52 +03:00
/*
* If this function is called repeatedly, only the first one needs to revalidate.
*/
if (!revalidate_labels)
goto out;
/*
* This function is normally called before reading metadata so
* we check cached labels here. Unfortunately vginfo is volatile.
*/
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
dm_list_init(&devs);
dm_list_iterate_items(info, &vginfo->infos) {
more coverity fixes
2006-05-10 21:49:25 +04:00
if (!(devl = dm_malloc(sizeof(*devl)))) {
log_error("device_list element allocation failed");
return NULL;
}
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
devl->dev = info->dev;
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
dm_list_add(&devs, &devl->list);
Improve detection of external changes affecting internal cache.
2005-03-22 01:40:35 +03:00
}
Fix vgexport/vgimport to set/reset PV exported flag so pv_attr is correct. Add vgid to struct physical_volume and pass with vg_name to some functions.
2006-04-13 01:23:04 +04:00
memcpy(vgid_found, vginfo->vgid, sizeof(vgid_found));
If two or more VGs are found with the same name, use one that is not exported.
2006-04-12 21:54:11 +04:00
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
dm_list_iterate_safe(devh, tmp, &devs) {
devl = dm_list_item(devh, struct device_list);
scan: use new label_scan for lvmcache_label_scan To do label scanning, lvm code calls lvmcache_label_scan(). Change lvmcache_label_scan() to use the new label_scan() based on bcache. Also add lvmcache_label_rescan_vg() which calls the new label_scan_devs() which does label scanning on only the specified devices. This is for a subsequent commit and is not yet used.
2018-02-07 22:14:08 +03:00
label_read(devl->dev, NULL, UINT64_C(0));
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
dm_list_del(&devl->list);
Use hash, bitset, malloc, pool from libdevmapper.
2005-10-17 03:03:59 +04:00
dm_free(devl);
Improve detection of external changes affecting internal cache.
2005-03-22 01:40:35 +03:00
}
If two or more VGs are found with the same name, use one that is not exported.
2006-04-12 21:54:11 +04:00
/* If vginfo changed, caller needs to rescan */
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
if (!(vginfo = lvmcache_vginfo_from_vgname(vgname, vgid_found)) ||
Fix vgid string termination in recent cache code.
2006-04-21 18:44:33 +04:00
strncmp(vginfo->vgid, vgid_found, ID_LEN))
If two or more VGs are found with the same name, use one that is not exported.
2006-04-12 21:54:11 +04:00
return NULL;
Fix scanning of VGs without in-PV mdas. Set cmd->independent_metadata_areas if metadata/dirs or disk_areas in use. - Identify and record this state. Don't skip full scan when independent mdas are present even if memlock is set. - Clusters and OOM aren't supported, so no problem doing the proper scans. Avoid revalidating the label cache immediately after scanning. - A simple optimisation. Support scanning for a single VG in independent mdas. - Not used by the fix but I left it in anyway as later patches might use it.
2010-12-11 01:39:52 +03:00
out:
A new cache.
2002-11-18 16:53:58 +03:00
return vginfo->fmt;
}
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
struct lvmcache_vginfo *lvmcache_vginfo_from_vgid(const char *vgid)
A new cache.
2002-11-18 16:53:58 +03:00
{
Another sync point - numerous fixes & clean ups.
2003-07-05 02:34:56 +04:00
struct lvmcache_vginfo *vginfo;
Use __attribute__ consistently throughout.
2010-07-09 19:34:40 +04:00
char id[ID_LEN + 1] __attribute__((aligned(8)));
A new cache.
2002-11-18 16:53:58 +03:00
lvmcache: add mode debug prints Decorate NULL returns with debug_cache output so the debug log doesn't contain spurios <bactrace> line without any reason for it. Add internal errors when cache is misused.
2014-03-18 13:24:32 +04:00
if (!_vgid_hash || !vgid) {
log_debug_cache(INTERNAL_ERROR "Internal cache cannot lookup vgid.");
A new cache.
2002-11-18 16:53:58 +03:00
return NULL;
lvmcache: add mode debug prints Decorate NULL returns with debug_cache output so the debug log doesn't contain spurios <bactrace> line without any reason for it. Add internal errors when cache is misused.
2014-03-18 13:24:32 +04:00
}
A new cache.
2002-11-18 16:53:58 +03:00
Fix (rare) cache bug on machines with large /dev directories.
2003-01-10 22:14:01 +03:00
/* vgid not necessarily NULL-terminated */
cleanup: more usage of dm_strncpy Use existing wrapper function arournd strncpy + buf[] = 0;
2018-03-02 18:25:37 +03:00
(void) dm_strncpy(id, vgid, sizeof(id));
Fix (rare) cache bug on machines with large /dev directories.
2003-01-10 22:14:01 +03:00
lvmcache: add mode debug prints Decorate NULL returns with debug_cache output so the debug log doesn't contain spurios <bactrace> line without any reason for it. Add internal errors when cache is misused.
2014-03-18 13:24:32 +04:00
if (!(vginfo = dm_hash_lookup(_vgid_hash, id))) {
log: Improve various device-related messages - Use 'lvmcache' consistently instead of 'metadata cache' - Always use 5 characters for source line number - Remember to convert uuids into printable form - Use <no name> rather than (null) when VG has no name.
2017-11-13 17:43:32 +03:00
log_debug_cache("lvmcache has no info for vgid \"%s\"", id);
A new cache.
2002-11-18 16:53:58 +03:00
return NULL;
lvmcache: add mode debug prints Decorate NULL returns with debug_cache output so the debug log doesn't contain spurios <bactrace> line without any reason for it. Add internal errors when cache is misused.
2014-03-18 13:24:32 +04:00
}
A new cache.
2002-11-18 16:53:58 +03:00
return vginfo;
}
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
const char *lvmcache_vgname_from_vgid(struct dm_pool *mem, const char *vgid)
Fix vgexport/vgimport to set/reset PV exported flag so pv_attr is correct. Add vgid to struct physical_volume and pass with vg_name to some functions.
2006-04-13 01:23:04 +04:00
{
struct lvmcache_vginfo *vginfo;
Fix PV tools to include orphaned PVs in default output again.
2006-06-15 00:11:22 +04:00
const char *vgname = NULL;
Fix vgexport/vgimport to set/reset PV exported flag so pv_attr is correct. Add vgid to struct physical_volume and pass with vg_name to some functions.
2006-04-13 01:23:04 +04:00
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
if ((vginfo = lvmcache_vginfo_from_vgid(vgid)))
Fix PV tools to include orphaned PVs in default output again.
2006-06-15 00:11:22 +04:00
vgname = vginfo->vgname;
if (mem && vgname)
return dm_pool_strdup(mem, vgname);
Fix vgexport/vgimport to set/reset PV exported flag so pv_attr is correct. Add vgid to struct physical_volume and pass with vg_name to some functions.
2006-04-13 01:23:04 +04:00
Fix PV tools to include orphaned PVs in default output again.
2006-06-15 00:11:22 +04:00
return vgname;
Fix vgexport/vgimport to set/reset PV exported flag so pv_attr is correct. Add vgid to struct physical_volume and pass with vg_name to some functions.
2006-04-13 01:23:04 +04:00
}
vg_read: look up vgid from name After recent changes to process_each, vg_read() is usually given both the vgname and vgid for the intended VG. However, in some cases vg_read() is given a vgid with no vgname, or is given a vgname with no vgid. When given a vgid with no vgname, vg_read() uses lvmcache to look up the vgname using the vgid. If the vgname is not found, vg_read() fails. When given a vgname with no vgid, vg_read() should also use lvmcache to look up the vgid using the vgname. If the vgid is not found, vg_read() fails. If the lvmcache lookup finds multiple vgids for the vgname, then the lookup fails, causing vg_read() to fail because the intended VG is uncertain. Usually, both vgname and vgid for the intended VG are passed to vg_read(), which means the lvmcache translations between vgname and vgid are not done.
2015-12-01 00:12:01 +03:00
const char *lvmcache_vgid_from_vgname(struct cmd_context *cmd, const char *vgname)
{
struct lvmcache_vginfo *vginfo;
if (!(vginfo = dm_hash_lookup(_vgname_hash, vgname)))
return_NULL;
if (!vginfo->next)
return dm_pool_strdup(cmd->mem, vginfo->vgid);
/*
* There are multiple VGs with this name to choose from.
* Return an error because we don't know which VG is intended.
*/
return NULL;
}
Rely upon internally-cached PV labels while corresponding VG lock is held.
2008-01-30 02:45:48 +03:00
/*
* If valid_only is set, data will only be returned if the cached data is
* known still to be valid.
lvmcache: add optional dev arg to lvmcache_info_from_pvid A number of places are working on a specific dev when they call lvmcache_info_from_pvid() to look up an info struct based on a pvid. In those cases, pass the dev being used to lvmcache_info_from_pvid(). When a dev is specified, lvmcache_info_from_pvid() will verify that the cached info it's using matches the dev being processed before returning the info. Calling code will not mistakenly get info for the wrong dev when duplicate devs exist. This confusion was happening when scanning labels when duplicate devs existed. label_read for the first dev would add an info struct to lvmcache for that dev/pvid. label_read for the second dev would see the pvid in lvmcache from first dev, and mistakenly conclude that the label_read from the second dev can be skipped because it's already been done. By verifying that the dev for the cached pvid matches the dev being read, this mismatch is avoided and the label is actually read from the second duplicate.
2016-06-06 22:04:17 +03:00
*
* When the device being worked with is known, pass that dev as the second arg.
* This ensures that when duplicates exist, the wrong dev isn't used.
Rely upon internally-cached PV labels while corresponding VG lock is held.
2008-01-30 02:45:48 +03:00
*/
lvmcache: add optional dev arg to lvmcache_info_from_pvid A number of places are working on a specific dev when they call lvmcache_info_from_pvid() to look up an info struct based on a pvid. In those cases, pass the dev being used to lvmcache_info_from_pvid(). When a dev is specified, lvmcache_info_from_pvid() will verify that the cached info it's using matches the dev being processed before returning the info. Calling code will not mistakenly get info for the wrong dev when duplicate devs exist. This confusion was happening when scanning labels when duplicate devs existed. label_read for the first dev would add an info struct to lvmcache for that dev/pvid. label_read for the second dev would see the pvid in lvmcache from first dev, and mistakenly conclude that the label_read from the second dev can be skipped because it's already been done. By verifying that the dev for the cached pvid matches the dev being read, this mismatch is avoided and the label is actually read from the second duplicate.
2016-06-06 22:04:17 +03:00
struct lvmcache_info *lvmcache_info_from_pvid(const char *pvid, struct device *dev, int valid_only)
A new cache.
2002-11-18 16:53:58 +03:00
{
Another sync point - numerous fixes & clean ups.
2003-07-05 02:34:56 +04:00
struct lvmcache_info *info;
Use __attribute__ consistently throughout.
2010-07-09 19:34:40 +04:00
char id[ID_LEN + 1] __attribute__((aligned(8)));
A new cache.
2002-11-18 16:53:58 +03:00
if (!_pvid_hash || !pvid)
return NULL;
cleanup: more usage of dm_strncpy Use existing wrapper function arournd strncpy + buf[] = 0;
2018-03-02 18:25:37 +03:00
(void) dm_strncpy(id, pvid, sizeof(id));
Fix (rare) cache bug on machines with large /dev directories.
2003-01-10 22:14:01 +03:00
Use hash, bitset, malloc, pool from libdevmapper.
2005-10-17 03:03:59 +04:00
if (!(info = dm_hash_lookup(_pvid_hash, id)))
A new cache.
2002-11-18 16:53:58 +03:00
return NULL;
lvmcache: add optional dev arg to lvmcache_info_from_pvid A number of places are working on a specific dev when they call lvmcache_info_from_pvid() to look up an info struct based on a pvid. In those cases, pass the dev being used to lvmcache_info_from_pvid(). When a dev is specified, lvmcache_info_from_pvid() will verify that the cached info it's using matches the dev being processed before returning the info. Calling code will not mistakenly get info for the wrong dev when duplicate devs exist. This confusion was happening when scanning labels when duplicate devs existed. label_read for the first dev would add an info struct to lvmcache for that dev/pvid. label_read for the second dev would see the pvid in lvmcache from first dev, and mistakenly conclude that the label_read from the second dev can be skipped because it's already been done. By verifying that the dev for the cached pvid matches the dev being read, this mismatch is avoided and the label is actually read from the second duplicate.
2016-06-06 22:04:17 +03:00
/*
* When handling duplicate PVs, more than one device can have this pvid.
*/
if (dev && info->dev && (info->dev != dev)) {
log_debug_cache("Ignoring lvmcache info for dev %s because dev %s was requested for PVID %s.",
dev_name(info->dev), dev_name(dev), id);
return NULL;
}
A new cache.
2002-11-18 16:53:58 +03:00
return info;
}
lvmcache: process duplicate PVs directly Previously, duplicate PVs were processed as a side effect of processing the "chosen" PV in lvmcache. The duplicate PV would be hacked into lvmcache temporarily in place of the chosen PV. In the old way, we had to always process the "chosen" PV device, even if a duplicate of it was named on the command line. This meant we were processing a different device than was asked for. This could be worked around by naming multiple duplicate devs on the command line in which case they were swapped in and out of lvmcache for processing. Now, the duplicate devs are processed directly in their own processing loop. This means we can remove the old hacks related to processing dups as a side effect of processing the chosen device. We can now simply process the device that was named on the command line. When the same PVID exists on two or more devices, one device is preferred and used in the VG, and the others are duplicates and are not used in the VG. The preferred device exists in lvmcache as usual. The duplicates exist in a specical list of unused duplicate devices. The duplicate devs have the "d" attribute and the "duplicate" reporting field displays "duplicate" for them. 'pvs' warns about duplicates, but the formal output only includes the single preferred PV. 'pvs -a' has the same warnings, and the duplicate devs are included in the output. 'pvs <path>' has the same warnings, and displays the named device, whether it is preferred or a duplicate.
2016-02-11 21:37:36 +03:00
const struct format_type *lvmcache_fmt_from_info(struct lvmcache_info *info)
{
return info->fmt;
}
The lvmetad client-side integration. Only active when use_lvmetad = 1 is set in lvm.conf *and* lvmetad is running.
2012-02-23 17:11:07 +04:00
const char *lvmcache_vgname_from_info(struct lvmcache_info *info)
{
if (info->vginfo)
return info->vginfo->vgname;
return NULL;
}
Add lvmcache_vgname_from_pvid(). Add lvmcache function to lookup a vgname from a pvid.
2010-05-19 15:52:21 +04:00
char *lvmcache_vgname_from_pvid(struct cmd_context *cmd, const char *pvid)
{
struct lvmcache_info *info;
char *vgname;
scan: use new label_scan for lvmcache_label_scan To do label scanning, lvm code calls lvmcache_label_scan(). Change lvmcache_label_scan() to use the new label_scan() based on bcache. Also add lvmcache_label_rescan_vg() which calls the new label_scan_devs() which does label scanning on only the specified devices. This is for a subsequent commit and is not yet used.
2018-02-07 22:14:08 +03:00
if (!lvmcache_device_from_pvid(cmd, (const struct id *)pvid, NULL)) {
Add lvmcache_vgname_from_pvid(). Add lvmcache function to lookup a vgname from a pvid.
2010-05-19 15:52:21 +04:00
log_error("Couldn't find device with uuid %s.", pvid);
return NULL;
}
lvmcache: add optional dev arg to lvmcache_info_from_pvid A number of places are working on a specific dev when they call lvmcache_info_from_pvid() to look up an info struct based on a pvid. In those cases, pass the dev being used to lvmcache_info_from_pvid(). When a dev is specified, lvmcache_info_from_pvid() will verify that the cached info it's using matches the dev being processed before returning the info. Calling code will not mistakenly get info for the wrong dev when duplicate devs exist. This confusion was happening when scanning labels when duplicate devs existed. label_read for the first dev would add an info struct to lvmcache for that dev/pvid. label_read for the second dev would see the pvid in lvmcache from first dev, and mistakenly conclude that the label_read from the second dev can be skipped because it's already been done. By verifying that the dev for the cached pvid matches the dev being read, this mismatch is avoided and the label is actually read from the second duplicate.
2016-06-06 22:04:17 +03:00
info = lvmcache_info_from_pvid(pvid, NULL, 0);
Add lvmcache_vgname_from_pvid(). Add lvmcache function to lookup a vgname from a pvid.
2010-05-19 15:52:21 +04:00
if (!info)
return_NULL;
if (!(vgname = dm_pool_strdup(cmd->mem, info->vginfo->vgname))) {
log_errno(ENOMEM, "vgname allocation failed");
return NULL;
}
return vgname;
}
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
* entries in _unused_duplicate_devices.
*/
int vg_has_duplicate_pvs(struct volume_group *vg)
{
struct pv_list *pvl;
struct device_list *devl;
dm_list_iterate_items(pvl, &vg->pvs) {
dm_list_iterate_items(devl, &_unused_duplicate_devs) {
if (id_equal(&pvl->pv->id, (const struct id *)devl->dev->pvid))
return 1;
}
}
return 0;
}
lvmcache: fix duplicate handling with multiple scans Some commands scan labels to populate lvmcache multiple times, i.e. lvmcache_init, scan labels to fill lvmcache, lvmcache_destroy, then later repeat Each time labels are scanned, duplicates are detected, and preferred devices are chosen. Each time this is done within a single command, we want to choose the same preferred devices. So, check for existing preferences when choosing preferred devices. This also fixes a problem with the list of unused duplicate devs when run in an lvm shell. The devs had been allocated from cmd memory, resulting in invalid list entries between commands.
2016-06-06 23:20:55 +03:00
static int _dev_in_device_list(struct device *dev, struct dm_list *head)
pvs: new attr and field for unchosen duplicate device When there are duplicate devices for a PV, one device is preferred and chosen to exist in the VG. The other devices are not used by lvm, but are displayed by pvs with a new PV attr "d", indicating that they are unchosen duplicate PVs. The "duplicate" reporting field is set to "duplicate" when the PV is an unchosen duplicate, and that field is blank for the chosen PV.
2016-04-29 22:42:14 +03:00
{
struct device_list *devl;
lvmcache: fix duplicate handling with multiple scans Some commands scan labels to populate lvmcache multiple times, i.e. lvmcache_init, scan labels to fill lvmcache, lvmcache_destroy, then later repeat Each time labels are scanned, duplicates are detected, and preferred devices are chosen. Each time this is done within a single command, we want to choose the same preferred devices. So, check for existing preferences when choosing preferred devices. This also fixes a problem with the list of unused duplicate devs when run in an lvm shell. The devs had been allocated from cmd memory, resulting in invalid list entries between commands.
2016-06-06 23:20:55 +03:00
dm_list_iterate_items(devl, head) {
pvs: new attr and field for unchosen duplicate device When there are duplicate devices for a PV, one device is preferred and chosen to exist in the VG. The other devices are not used by lvm, but are displayed by pvs with a new PV attr "d", indicating that they are unchosen duplicate PVs. The "duplicate" reporting field is set to "duplicate" when the PV is an unchosen duplicate, and that field is blank for the chosen PV.
2016-04-29 22:42:14 +03:00
if (devl->dev == dev)
return 1;
}
return 0;
}
lvmcache: fix duplicate handling with multiple scans Some commands scan labels to populate lvmcache multiple times, i.e. lvmcache_init, scan labels to fill lvmcache, lvmcache_destroy, then later repeat Each time labels are scanned, duplicates are detected, and preferred devices are chosen. Each time this is done within a single command, we want to choose the same preferred devices. So, check for existing preferences when choosing preferred devices. This also fixes a problem with the list of unused duplicate devs when run in an lvm shell. The devs had been allocated from cmd memory, resulting in invalid list entries between commands.
2016-06-06 23:20:55 +03:00
int lvmcache_dev_is_unchosen_duplicate(struct device *dev)
{
return _dev_in_device_list(dev, &_unused_duplicate_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
/*
* Compare _found_duplicate_devs entries with the corresponding duplicate dev
* in lvmcache. There may be multiple duplicates in _found_duplicate_devs for
* a given pvid. If a dev from _found_duplicate_devs is preferred over the dev
* in lvmcache, then drop the dev in lvmcache and rescan the preferred dev to
* add it to lvmcache.
*
* _found_duplicate_devs: duplicate devs found during initial scan.
* These are compared to lvmcache devs to see if any are preferred.
*
* _unused_duplicate_devs: duplicate devs not chosen to be used.
* These are _found_duplicate_devs entries that were not chosen,
* or unpreferred lvmcache devs that were dropped.
*
* del_cache_devs: devices to drop from lvmcache
* add_cache_devs: devices to scan to add to lvmcache
*/
static void _choose_preferred_devs(struct cmd_context *cmd,
struct dm_list *del_cache_devs,
struct dm_list *add_cache_devs)
{
char uuid[64] __attribute__((aligned(8)));
cleanup: drop assign before use Drop unneeded assigns singe vars are set later in code before their first use (Coverity).
2016-10-03 14:04:16 +03:00
const char *reason;
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
struct dm_list altdevs;
lvmcache: fix duplicate handling with multiple scans Some commands scan labels to populate lvmcache multiple times, i.e. lvmcache_init, scan labels to fill lvmcache, lvmcache_destroy, then later repeat Each time labels are scanned, duplicates are detected, and preferred devices are chosen. Each time this is done within a single command, we want to choose the same preferred devices. So, check for existing preferences when choosing preferred devices. This also fixes a problem with the list of unused duplicate devs when run in an lvm shell. The devs had been allocated from cmd memory, resulting in invalid list entries between commands.
2016-06-06 23:20:55 +03:00
struct dm_list new_unused;
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
struct dev_types *dt = cmd->dev_types;
struct device_list *devl, *devl_safe, *alt, *del;
struct lvmcache_info *info;
struct device *dev1, *dev2;
uint32_t dev1_major, dev1_minor, dev2_major, dev2_minor;
lvmcache: use active LVs and device sizes to choose between duplicates If duplicate devices exist for a PV, and one device's size matches the PV size, but the other doesn't, then prefer the matching device. If one device is used by an active LV, prefer that device.
2016-03-29 21:29:39 +03:00
uint64_t info_size, dev1_size, dev2_size;
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
int in_subsys1, in_subsys2;
int is_dm1, is_dm2;
int has_fs1, has_fs2;
lvmcache: use active LVs and device sizes to choose between duplicates If duplicate devices exist for a PV, and one device's size matches the PV size, but the other doesn't, then prefer the matching device. If one device is used by an active LV, prefer that device.
2016-03-29 21:29:39 +03:00
int has_lv1, has_lv2;
int same_size1, same_size2;
lvmcache: fix duplicate handling with multiple scans Some commands scan labels to populate lvmcache multiple times, i.e. lvmcache_init, scan labels to fill lvmcache, lvmcache_destroy, then later repeat Each time labels are scanned, duplicates are detected, and preferred devices are chosen. Each time this is done within a single command, we want to choose the same preferred devices. So, check for existing preferences when choosing preferred devices. This also fixes a problem with the list of unused duplicate devs when run in an lvm shell. The devs had been allocated from cmd memory, resulting in invalid list entries between commands.
2016-06-06 23:20:55 +03:00
int prev_unchosen1, prev_unchosen2;
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
int change;
lvmcache: fix duplicate handling with multiple scans Some commands scan labels to populate lvmcache multiple times, i.e. lvmcache_init, scan labels to fill lvmcache, lvmcache_destroy, then later repeat Each time labels are scanned, duplicates are detected, and preferred devices are chosen. Each time this is done within a single command, we want to choose the same preferred devices. So, check for existing preferences when choosing preferred devices. This also fixes a problem with the list of unused duplicate devs when run in an lvm shell. The devs had been allocated from cmd memory, resulting in invalid list entries between commands.
2016-06-06 23:20:55 +03:00
dm_list_init(&new_unused);
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
/*
* Create a list of all alternate devs for the same pvid: altdevs.
*/
next:
dm_list_init(&altdevs);
alt = NULL;
dm_list_iterate_items_safe(devl, devl_safe, &_found_duplicate_devs) {
if (!alt) {
dm_list_move(&altdevs, &devl->list);
alt = devl;
} else {
if (!strcmp(alt->dev->pvid, devl->dev->pvid))
dm_list_move(&altdevs, &devl->list);
}
}
lvmcache: fix duplicate handling with multiple scans Some commands scan labels to populate lvmcache multiple times, i.e. lvmcache_init, scan labels to fill lvmcache, lvmcache_destroy, then later repeat Each time labels are scanned, duplicates are detected, and preferred devices are chosen. Each time this is done within a single command, we want to choose the same preferred devices. So, check for existing preferences when choosing preferred devices. This also fixes a problem with the list of unused duplicate devs when run in an lvm shell. The devs had been allocated from cmd memory, resulting in invalid list entries between commands.
2016-06-06 23:20:55 +03:00
if (!alt) {
_destroy_duplicate_device_list(&_unused_duplicate_devs);
dm_list_splice(&_unused_duplicate_devs, &new_unused);
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
return;
lvmcache: fix duplicate handling with multiple scans Some commands scan labels to populate lvmcache multiple times, i.e. lvmcache_init, scan labels to fill lvmcache, lvmcache_destroy, then later repeat Each time labels are scanned, duplicates are detected, and preferred devices are chosen. Each time this is done within a single command, we want to choose the same preferred devices. So, check for existing preferences when choosing preferred devices. This also fixes a problem with the list of unused duplicate devs when run in an lvm shell. The devs had been allocated from cmd memory, resulting in invalid list entries between commands.
2016-06-06 23:20:55 +03:00
}
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
/*
* Find the device for the pvid that's currently in lvmcache.
*/
lvmcache: add optional dev arg to lvmcache_info_from_pvid A number of places are working on a specific dev when they call lvmcache_info_from_pvid() to look up an info struct based on a pvid. In those cases, pass the dev being used to lvmcache_info_from_pvid(). When a dev is specified, lvmcache_info_from_pvid() will verify that the cached info it's using matches the dev being processed before returning the info. Calling code will not mistakenly get info for the wrong dev when duplicate devs exist. This confusion was happening when scanning labels when duplicate devs existed. label_read for the first dev would add an info struct to lvmcache for that dev/pvid. label_read for the second dev would see the pvid in lvmcache from first dev, and mistakenly conclude that the label_read from the second dev can be skipped because it's already been done. By verifying that the dev for the cached pvid matches the dev being read, this mismatch is avoided and the label is actually read from the second duplicate.
2016-06-06 22:04:17 +03:00
if (!(info = lvmcache_info_from_pvid(alt->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
/* This shouldn't happen */
log_warn("WARNING: PV %s on duplicate device %s not found in cache.",
alt->dev->pvid, dev_name(alt->dev));
goto next;
}
/*
* Compare devices for the given pvid to find one that's preferred.
* "dev1" is the currently preferred device, starting with the device
* currently in lvmcache.
*/
dev1 = info->dev;
dm_list_iterate_items(devl, &altdevs) {
dev2 = devl->dev;
if (dev1 == dev2) {
/* This shouldn't happen */
log_warn("Same duplicate device repeated %s", dev_name(dev1));
continue;
}
lvmcache: fix duplicate handling with multiple scans Some commands scan labels to populate lvmcache multiple times, i.e. lvmcache_init, scan labels to fill lvmcache, lvmcache_destroy, then later repeat Each time labels are scanned, duplicates are detected, and preferred devices are chosen. Each time this is done within a single command, we want to choose the same preferred devices. So, check for existing preferences when choosing preferred devices. This also fixes a problem with the list of unused duplicate devs when run in an lvm shell. The devs had been allocated from cmd memory, resulting in invalid list entries between commands.
2016-06-06 23:20:55 +03:00
prev_unchosen1 = _dev_in_device_list(dev1, &_unused_duplicate_devs);
prev_unchosen2 = _dev_in_device_list(dev2, &_unused_duplicate_devs);
if (!prev_unchosen1 && !prev_unchosen2) {
/*
* The cmd list saves the unchosen preference across
* lvmcache_destroy. Sometimes a single command will
* fill lvmcache, destroy it, and refill it, and we
* want the same duplicate preference to be preserved
* in each instance of lvmcache for a single command.
*/
prev_unchosen1 = _dev_in_device_list(dev1, &cmd->unused_duplicate_devs);
prev_unchosen2 = _dev_in_device_list(dev2, &cmd->unused_duplicate_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
dev1_major = MAJOR(dev1->dev);
dev1_minor = MINOR(dev1->dev);
dev2_major = MAJOR(dev2->dev);
dev2_minor = MINOR(dev2->dev);
lvmcache: use active LVs and device sizes to choose between duplicates If duplicate devices exist for a PV, and one device's size matches the PV size, but the other doesn't, then prefer the matching device. If one device is used by an active LV, prefer that device.
2016-03-29 21:29:39 +03:00
if (!dev_get_size(dev1, &dev1_size))
dev1_size = 0;
if (!dev_get_size(dev2, &dev2_size))
dev2_size = 0;
has_lv1 = (dev1->flags & DEV_USED_FOR_LV) ? 1 : 0;
has_lv2 = (dev2->flags & DEV_USED_FOR_LV) ? 1 : 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
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);
lvmcache: use active LVs and device sizes to choose between duplicates If duplicate devices exist for a PV, and one device's size matches the PV size, but the other doesn't, then prefer the matching device. If one device is used by an active LV, prefer that device.
2016-03-29 21:29:39 +03:00
info_size = info->device_size >> SECTOR_SHIFT;
same_size1 = (dev1_size == info_size);
same_size2 = (dev2_size == info_size);
log_debug_cache("PV %s compare duplicates: %s %u:%u. %s %u:%u.",
devl->dev->pvid,
dev_name(dev1), dev1_major, dev1_minor,
dev_name(dev2), dev2_major, dev2_minor);
log_debug_cache("PV %s: wants size %llu. %s is %llu. %s is %llu.",
devl->dev->pvid,
(unsigned long long)info_size,
dev_name(dev1), (unsigned long long)dev1_size,
dev_name(dev2), (unsigned long long)dev2_size);
lvmcache: fix duplicate handling with multiple scans Some commands scan labels to populate lvmcache multiple times, i.e. lvmcache_init, scan labels to fill lvmcache, lvmcache_destroy, then later repeat Each time labels are scanned, duplicates are detected, and preferred devices are chosen. Each time this is done within a single command, we want to choose the same preferred devices. So, check for existing preferences when choosing preferred devices. This also fixes a problem with the list of unused duplicate devs when run in an lvm shell. The devs had been allocated from cmd memory, resulting in invalid list entries between commands.
2016-06-06 23:20:55 +03:00
log_debug_cache("PV %s: %s was prev %s. %s was prev %s.",
devl->dev->pvid,
dev_name(dev1), prev_unchosen1 ? "not chosen" : "<none>",
dev_name(dev2), prev_unchosen2 ? "not chosen" : "<none>");
lvmcache: use active LVs and device sizes to choose between duplicates If duplicate devices exist for a PV, and one device's size matches the PV size, but the other doesn't, then prefer the matching device. If one device is used by an active LV, prefer that device.
2016-03-29 21:29:39 +03:00
log_debug_cache("PV %s: %s %s subsystem. %s %s subsystem.",
devl->dev->pvid,
dev_name(dev1), in_subsys1 ? "is in" : "is not in",
dev_name(dev2), in_subsys2 ? "is in" : "is not in");
log_debug_cache("PV %s: %s %s dm. %s %s dm.",
devl->dev->pvid,
dev_name(dev1), is_dm1 ? "is" : "is not",
dev_name(dev2), is_dm2 ? "is" : "is not");
log_debug_cache("PV %s: %s %s mounted fs. %s %s mounted fs.",
devl->dev->pvid,
dev_name(dev1), has_fs1 ? "has" : "has no",
dev_name(dev2), has_fs2 ? "has" : "has no");
log_debug_cache("PV %s: %s %s LV. %s %s LV.",
devl->dev->pvid,
dev_name(dev1), has_lv1 ? "is used for" : "is not used for",
dev_name(dev2), has_lv2 ? "is used for" : "is not used for");
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
change = 0;
lvmcache: fix duplicate handling with multiple scans Some commands scan labels to populate lvmcache multiple times, i.e. lvmcache_init, scan labels to fill lvmcache, lvmcache_destroy, then later repeat Each time labels are scanned, duplicates are detected, and preferred devices are chosen. Each time this is done within a single command, we want to choose the same preferred devices. So, check for existing preferences when choosing preferred devices. This also fixes a problem with the list of unused duplicate devs when run in an lvm shell. The devs had been allocated from cmd memory, resulting in invalid list entries between commands.
2016-06-06 23:20:55 +03:00
if (prev_unchosen1 && !prev_unchosen2) {
/* change to 2 (NB when unchosen is set we unprefer) */
change = 1;
reason = "of previous preference";
} else if (prev_unchosen2 && !prev_unchosen1) {
/* keep 1 (NB when unchosen is set we unprefer) */
reason = "of previous preference";
} else if (has_lv1 && !has_lv2) {
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
/* keep 1 */
lvmcache: use active LVs and device sizes to choose between duplicates If duplicate devices exist for a PV, and one device's size matches the PV size, but the other doesn't, then prefer the matching device. If one device is used by an active LV, prefer that device.
2016-03-29 21:29:39 +03:00
reason = "device is used by LV";
} else if (has_lv2 && !has_lv1) {
/* change to 2 */
change = 1;
reason = "device is used by LV";
} 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";
} else if (has_fs1 && !has_fs2) {
/* keep 1 */
reason = "device has fs mounted";
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
} else if (has_fs2 && !has_fs1) {
/* change to 2 */
change = 1;
lvmcache: use active LVs and device sizes to choose between duplicates If duplicate devices exist for a PV, and one device's size matches the PV size, but the other doesn't, then prefer the matching device. If one device is used by an active LV, prefer that device.
2016-03-29 21:29:39 +03:00
reason = "device has fs mounted";
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
} else if (is_dm1 && !is_dm2) {
/* keep 1 */
lvmcache: use active LVs and device sizes to choose between duplicates If duplicate devices exist for a PV, and one device's size matches the PV size, but the other doesn't, then prefer the matching device. If one device is used by an active LV, prefer that device.
2016-03-29 21:29:39 +03:00
reason = "device is in dm subsystem";
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
} else if (is_dm2 && !is_dm1) {
/* change to 2 */
change = 1;
lvmcache: use active LVs and device sizes to choose between duplicates If duplicate devices exist for a PV, and one device's size matches the PV size, but the other doesn't, then prefer the matching device. If one device is used by an active LV, prefer that device.
2016-03-29 21:29:39 +03:00
reason = "device is in dm subsystem";
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
} else if (in_subsys1 && !in_subsys2) {
/* keep 1 */
lvmcache: use active LVs and device sizes to choose between duplicates If duplicate devices exist for a PV, and one device's size matches the PV size, but the other doesn't, then prefer the matching device. If one device is used by an active LV, prefer that device.
2016-03-29 21:29:39 +03:00
reason = "device is in subsystem";
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
} else if (in_subsys2 && !in_subsys1) {
/* change to 2 */
change = 1;
lvmcache: use active LVs and device sizes to choose between duplicates If duplicate devices exist for a PV, and one device's size matches the PV size, but the other doesn't, then prefer the matching device. If one device is used by an active LV, prefer that device.
2016-03-29 21:29:39 +03:00
reason = "device is in subsystem";
} else {
reason = "device was seen first";
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
}
if (change) {
dev1 = dev2;
alt = devl;
}
coverity: missing check for id_write_format return value
2016-05-31 10:56:10 +03:00
if (!id_write_format((const struct id *)dev1->pvid, uuid, sizeof(uuid)))
stack;
lvmcache: use active LVs and device sizes to choose between duplicates If duplicate devices exist for a PV, and one device's size matches the PV size, but the other doesn't, then prefer the matching device. If one device is used by an active LV, prefer that device.
2016-03-29 21:29:39 +03:00
log_warn("WARNING: PV %s prefers device %s because %s.", uuid, dev_name(dev1), reason);
}
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 (dev1 != info->dev) {
lvmcache: use active LVs and device sizes to choose between duplicates If duplicate devices exist for a PV, and one device's size matches the PV size, but the other doesn't, then prefer the matching device. If one device is used by an active LV, prefer that device.
2016-03-29 21:29:39 +03:00
log_debug_cache("PV %s: switching to device %s instead of device %s.",
dev1->pvid, dev_name(dev1), 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
/*
* Move the preferred device from altdevs to add_cache_devs.
* Create a del_cache_devs entry for the current lvmcache
* device to drop.
*/
dm_list_move(add_cache_devs, &alt->list);
lvmcache: fix duplicate handling with multiple scans Some commands scan labels to populate lvmcache multiple times, i.e. lvmcache_init, scan labels to fill lvmcache, lvmcache_destroy, then later repeat Each time labels are scanned, duplicates are detected, and preferred devices are chosen. Each time this is done within a single command, we want to choose the same preferred devices. So, check for existing preferences when choosing preferred devices. This also fixes a problem with the list of unused duplicate devs when run in an lvm shell. The devs had been allocated from cmd memory, resulting in invalid list entries between commands.
2016-06-06 23:20:55 +03:00
if ((del = dm_zalloc(sizeof(*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
del->dev = info->dev;
dm_list_add(del_cache_devs, &del->list);
}
lvmcache: use active LVs and device sizes to choose between duplicates If duplicate devices exist for a PV, and one device's size matches the PV size, but the other doesn't, then prefer the matching device. If one device is used by an active LV, prefer that device.
2016-03-29 21:29:39 +03:00
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
} else {
lvmcache: use active LVs and device sizes to choose between duplicates If duplicate devices exist for a PV, and one device's size matches the PV size, but the other doesn't, then prefer the matching device. If one device is used by an active LV, prefer that device.
2016-03-29 21:29:39 +03:00
log_debug_cache("PV %s: keeping current device %s.", dev1->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
}
/*
* alt devs not chosen are moved to _unused_duplicate_devs.
* del_cache_devs being dropped are moved to _unused_duplicate_devs
* after being dropped. So, _unused_duplicate_devs represents all
* duplicates not being used in lvmcache.
*/
lvmcache: fix duplicate handling with multiple scans Some commands scan labels to populate lvmcache multiple times, i.e. lvmcache_init, scan labels to fill lvmcache, lvmcache_destroy, then later repeat Each time labels are scanned, duplicates are detected, and preferred devices are chosen. Each time this is done within a single command, we want to choose the same preferred devices. So, check for existing preferences when choosing preferred devices. This also fixes a problem with the list of unused duplicate devs when run in an lvm shell. The devs had been allocated from cmd memory, resulting in invalid list entries between commands.
2016-06-06 23:20:55 +03:00
dm_list_splice(&new_unused, &altdevs);
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
goto next;
}
scan: use new label_scan for lvmcache_label_scan To do label scanning, lvm code calls lvmcache_label_scan(). Change lvmcache_label_scan() to use the new label_scan() based on bcache. Also add lvmcache_label_rescan_vg() which calls the new label_scan_devs() which does label scanning on only the specified devices. This is for a subsequent commit and is not yet used.
2018-02-07 22:14:08 +03:00
/*
* The initial label_scan at the start of the command is done without
* holding VG locks. Then for each VG identified during the label_scan,
* vg_read(vgname) is called while holding the VG lock. The labels
* and metadata on this VG's devices could have changed between the
* initial unlocked label_scan and the current vg_read(). So, we reread
* the labels/metadata for each device in the VG now that we hold the
* lock, and use this for processing the VG.
*
* A label scan is ultimately creating associations between devices
* and VGs so that when vg_read wants to get VG metadata, it knows
scan: skip device rescan in vg_read For reporting commands (pvs,vgs,lvs,pvdisplay,vgdisplay,lvdisplay) we do not need to repeat the label scan of devices in vg_read if they all had matching metadata in the initial label scan. The data read by label scan can just be reused for the vg_read. This cuts the amount of device i/o in half, from two reads of each device to one. We have to be careful to avoid repairing the VG if we've skipped rescanning. (The VG repair code is very poor, and will be redone soon.)
2018-04-19 00:29:42 +03:00
* which devices to read.
*
* It's possible that a VG is being modified during the first label
* scan, causing the scan to see inconsistent metadata on different
* devs in the VG. It's possible that those modifications are
* adding/removing devs from the VG, in which case the device/VG
* associations in lvmcache after the scan are not correct.
* NB. It's even possible the VG was removed completely between
* label scan and here, in which case we'd not find the VG in
* lvmcache after this rescan.
*
* A scan will also create in incorrect/incomplete picture of a VG
* when devices have no metadata areas. The scan does not use
* VG metadata to figure out that a dev with no metadata belongs
* to a particular VG, so a device with no mdas will not be linked
* to that VG after a scan.
*
* (In the special case where VG metadata is stored in files on the
* file system (configured in lvm.conf), the
scan: use new label_scan for lvmcache_label_scan To do label scanning, lvm code calls lvmcache_label_scan(). Change lvmcache_label_scan() to use the new label_scan() based on bcache. Also add lvmcache_label_rescan_vg() which calls the new label_scan_devs() which does label scanning on only the specified devices. This is for a subsequent commit and is not yet used.
2018-02-07 22:14:08 +03:00
* vginfo->independent_metadata_location flag is set during label scan.
* When we get here to rescan, we are revalidating the device to VG
* mapping from label scan by repeating the label scan on a subset of
* devices. If we see independent_metadata_location is set from the
* initial label scan, we know that there is nothing to do because
* there is no device to VG mapping to revalidate, since the VG metadata
scan: skip device rescan in vg_read For reporting commands (pvs,vgs,lvs,pvdisplay,vgdisplay,lvdisplay) we do not need to repeat the label scan of devices in vg_read if they all had matching metadata in the initial label scan. The data read by label scan can just be reused for the vg_read. This cuts the amount of device i/o in half, from two reads of each device to one. We have to be careful to avoid repairing the VG if we've skipped rescanning. (The VG repair code is very poor, and will be redone soon.)
2018-04-19 00:29:42 +03:00
* comes directly from files.)
scan: use new label_scan for lvmcache_label_scan To do label scanning, lvm code calls lvmcache_label_scan(). Change lvmcache_label_scan() to use the new label_scan() based on bcache. Also add lvmcache_label_rescan_vg() which calls the new label_scan_devs() which does label scanning on only the specified devices. This is for a subsequent commit and is not yet used.
2018-02-07 22:14:08 +03:00
*/
int lvmcache_label_rescan_vg(struct cmd_context *cmd, const char *vgname, const char *vgid)
{
struct dm_list devs;
struct device_list *devl;
struct lvmcache_vginfo *vginfo;
scan: skip device rescan in vg_read For reporting commands (pvs,vgs,lvs,pvdisplay,vgdisplay,lvdisplay) we do not need to repeat the label scan of devices in vg_read if they all had matching metadata in the initial label scan. The data read by label scan can just be reused for the vg_read. This cuts the amount of device i/o in half, from two reads of each device to one. We have to be careful to avoid repairing the VG if we've skipped rescanning. (The VG repair code is very poor, and will be redone soon.)
2018-04-19 00:29:42 +03:00
struct lvmcache_info *info, *info2;
scan: use new label_scan for lvmcache_label_scan To do label scanning, lvm code calls lvmcache_label_scan(). Change lvmcache_label_scan() to use the new label_scan() based on bcache. Also add lvmcache_label_rescan_vg() which calls the new label_scan_devs() which does label scanning on only the specified devices. This is for a subsequent commit and is not yet used.
2018-02-07 22:14:08 +03:00
if (lvmetad_used())
return 1;
dm_list_init(&devs);
if (!(vginfo = lvmcache_vginfo_from_vgname(vgname, vgid)))
return_0;
/*
* When the VG metadata is from an independent location,
* then rescanning the devices in the VG won't find the
* metadata, and will destroy the vginfo/info associations
* that were created during label scan when the
* independent locations were read.
*/
if (vginfo->independent_metadata_location)
return 1;
dm_list_iterate_items(info, &vginfo->infos) {
if (!(devl = dm_malloc(sizeof(*devl)))) {
log_error("device_list element allocation failed");
return 0;
}
devl->dev = info->dev;
dm_list_add(&devs, &devl->list);
}
scan: skip device rescan in vg_read For reporting commands (pvs,vgs,lvs,pvdisplay,vgdisplay,lvdisplay) we do not need to repeat the label scan of devices in vg_read if they all had matching metadata in the initial label scan. The data read by label scan can just be reused for the vg_read. This cuts the amount of device i/o in half, from two reads of each device to one. We have to be careful to avoid repairing the VG if we've skipped rescanning. (The VG repair code is very poor, and will be redone soon.)
2018-04-19 00:29:42 +03:00
dm_list_iterate_items_safe(info, info2, &vginfo->infos)
lvmcache_del(info);
scan: use new label_scan for lvmcache_label_scan To do label scanning, lvm code calls lvmcache_label_scan(). Change lvmcache_label_scan() to use the new label_scan() based on bcache. Also add lvmcache_label_rescan_vg() which calls the new label_scan_devs() which does label scanning on only the specified devices. This is for a subsequent commit and is not yet used.
2018-02-07 22:14:08 +03:00
scan: skip device rescan in vg_read For reporting commands (pvs,vgs,lvs,pvdisplay,vgdisplay,lvdisplay) we do not need to repeat the label scan of devices in vg_read if they all had matching metadata in the initial label scan. The data read by label scan can just be reused for the vg_read. This cuts the amount of device i/o in half, from two reads of each device to one. We have to be careful to avoid repairing the VG if we've skipped rescanning. (The VG repair code is very poor, and will be redone soon.)
2018-04-19 00:29:42 +03:00
/* Dropping the last info struct is supposed to drop vginfo. */
if ((vginfo = lvmcache_vginfo_from_vgname(vgname, vgid)))
log_warn("VG info not dropped before rescan of %s", vgname);
/* FIXME: should we also rescan unused_duplicate_devs for devs
being rescanned here and then repeat resolving the duplicates? */
label_scan_devs(cmd, &devs);
scan: use new label_scan for lvmcache_label_scan To do label scanning, lvm code calls lvmcache_label_scan(). Change lvmcache_label_scan() to use the new label_scan() based on bcache. Also add lvmcache_label_rescan_vg() which calls the new label_scan_devs() which does label scanning on only the specified devices. This is for a subsequent commit and is not yet used.
2018-02-07 22:14:08 +03:00
return 1;
}
lvmcache: simplify Recent changes allow some major simplification of the way lvmcache works and is used. lvmcache_label_scan is now called in a controlled fashion at the start of commands, and not via various unpredictable side effects. Remove various calls to it from other places. lvmcache_label_scan should not be called from anywhere during a command, because it produces an incorrect representation of PVs with no MDAs, and misclassifies them as orphans. This has been a long standing problem. The invalid flag and rescanning based on that is no longer used and removed. The 'force' variation is no longer needed and removed.
2018-04-09 21:40:49 +03:00
/*
* Uses label_scan to populate lvmcache with 'vginfo' struct for each VG
* and associated 'info' structs for those VGs. Only VG summary information
* is used to assemble the vginfo/info during the scan, so the resulting
* representation of VG/PV state is incomplete and even incorrect.
* Specifically, PVs with no MDAs are considered orphans and placed in the
* orphan vginfo by lvmcache_label_scan. This is corrected during the
* processing phase as each vg_read() uses VG metadata for each VG to correct
* the lvmcache state, i.e. it moves no-MDA PVs from the orphan vginfo onto
* the correct vginfo. Once vg_read() is finished for all VGs, all of the
* incorrectly placed PVs should have been moved from the orphan vginfo
* onto their correct vginfo's, and the orphan vginfo should (in theory)
* represent only real orphan PVs. (Note: if lvmcache_label_scan is run
* after vg_read udpates to lvmcache state, then the lvmcache will be
* incorrect again, so do not run lvmcache_label_scan during the
* processing phase.)
*
* TODO: in this label scan phase, don't stash no-MDA PVs into the
* orphan VG. We know that's a fiction, and it can have harmful/damaging
* results. Instead, put them into a temporary list where they can be
* pulled from later when vg_read uses metadata to resolve which VG
* they actually belong to.
*/
vgrename: use process_each_vg Use process_each_vg() to lock and read the old VG, and then call the main vgrename code. When real VG names are used (not a UUID in place of the old name), the command still pre-locks the new name (when strcmp wants it locked first), before calling process_each_vg on the old name. In the case where the old name is replaced with a UUID, process_each_vg now translates that UUID into the real VG name, which it locks and reads. In this case, we cannot do pre-locking to maintain lock ordering because the old name is unknown. So, in this case the strcmp based lock ordering is suppressed and the old name is always locked first. This opens a remote chance for lock ordering conflict between racing vgrenames between two names where one or both commands use the UUID.
2015-12-01 23:09:01 +03:00
int lvmcache_label_scan(struct cmd_context *cmd)
A new cache.
2002-11-18 16:53:58 +03:00
{
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
struct dm_list del_cache_devs;
struct dm_list add_cache_devs;
struct lvmcache_info *info;
scan: drop bcache between lvm shell commands A running lvm shell keeps all lvm devices open unless the bcache is dropped.
2018-04-06 21:05:17 +03:00
struct lvmcache_vginfo *vginfo;
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 device_list *devl;
A new cache.
2002-11-18 16:53:58 +03:00
struct format_type *fmt;
scan: drop bcache between lvm shell commands A running lvm shell keeps all lvm devices open unless the bcache is dropped.
2018-04-06 21:05:17 +03:00
int vginfo_count = 0;
A new cache.
2002-11-18 16:53:58 +03:00
int r = 0;
scan: always setup bcache for commands using lvmetad Do this at the start of the command so that it doesn't need to be checked and set up in every function that could need it.
2018-02-15 01:21:27 +03:00
if (lvmetad_used()) {
if (!label_scan_setup_bcache())
return 0;
The lvmetad client-side integration. Only active when use_lvmetad = 1 is set in lvm.conf *and* lvmetad is running.
2012-02-23 17:11:07 +04:00
return 1;
scan: always setup bcache for commands using lvmetad Do this at the start of the command so that it doesn't need to be checked and set up in every function that could need it.
2018-02-15 01:21:27 +03:00
}
The lvmetad client-side integration. Only active when use_lvmetad = 1 is set in lvm.conf *and* lvmetad is running.
2012-02-23 17:11:07 +04:00
scan: drop bcache between lvm shell commands A running lvm shell keeps all lvm devices open unless the bcache is dropped.
2018-04-06 21:05:17 +03:00
log_debug_cache("Finding VG info");
A new cache.
2002-11-18 16:53:58 +03:00
/* Avoid recursion when a PVID can't be found! */
if (_scanning_in_progress)
return 0;
_scanning_in_progress = 1;
Another sync point - numerous fixes & clean ups.
2003-07-05 02:34:56 +04:00
if (!_vgname_hash && !lvmcache_init()) {
A new cache.
2002-11-18 16:53:58 +03:00
log_error("Internal cache initialisation failed");
goto out;
}
clvmd: drop old saved_vg when returning new saved_vg In some pvmove tests, clvmd uses the new (precommitted) saved_vg, but then requests the old saved_vg, and expects that the new saved_vg be returned instead of the old. So, when returning the new saved_vg, forget the old one so we don't return it again.
2018-04-26 22:41:57 +03:00
/* FIXME: can this happen? */
scan: use new label_scan for lvmcache_label_scan To do label scanning, lvm code calls lvmcache_label_scan(). Change lvmcache_label_scan() to use the new label_scan() based on bcache. Also add lvmcache_label_rescan_vg() which calls the new label_scan_devs() which does label scanning on only the specified devices. This is for a subsequent commit and is not yet used.
2018-02-07 22:14:08 +03:00
if (!cmd->full_filter) {
log_error("label scan is missing full filter");
A new cache.
2002-11-18 16:53:58 +03:00
goto out;
}
scan: refresh filters before scan The filters save information about devices that should be ignored, so if we need to repeat a scan (unusual, but happens in clvmd), we need to update the filters.
2018-04-26 22:48:13 +03:00
if (!refresh_filters(cmd))
log_error("Scan failed to refresh device filter.");
lvmcache: fix duplicate handling with multiple scans Some commands scan labels to populate lvmcache multiple times, i.e. lvmcache_init, scan labels to fill lvmcache, lvmcache_destroy, then later repeat Each time labels are scanned, duplicates are detected, and preferred devices are chosen. Each time this is done within a single command, we want to choose the same preferred devices. So, check for existing preferences when choosing preferred devices. This also fixes a problem with the list of unused duplicate devs when run in an lvm shell. The devs had been allocated from cmd memory, resulting in invalid list entries between commands.
2016-06-06 23:20:55 +03:00
/*
* Duplicates found during this label scan are added to _found_duplicate_devs().
*/
_destroy_duplicate_device_list(&_found_duplicate_devs);
scan: use new label_scan for lvmcache_label_scan To do label scanning, lvm code calls lvmcache_label_scan(). Change lvmcache_label_scan() to use the new label_scan() based on bcache. Also add lvmcache_label_rescan_vg() which calls the new label_scan_devs() which does label scanning on only the specified devices. This is for a subsequent commit and is not yet used.
2018-02-07 22:14:08 +03:00
/*
* Do the actual scanning. This populates lvmcache
* with infos/vginfos based on reading headers from
* each device, and a vg summary from each mda.
*
* Note that this will *skip* scanning a device if
* an info struct already exists in lvmcache for
* the device.
*/
label_scan(cmd);
process_each_pv: do full scan earlier to find new devices Before commit c1f246fedfc349c25749da501e68a7f70bd122b0, _get_all_devices() did a full device scan before get_vgnameids() was called. The full scan in _get_all_devices() is from calling dev_iter_create(f, 1). The '1' arg forces a full scan. By doing a full scan in _get_all_devices(), new devices were added to dev-cache before get_vgnameids() began scanning labels. So, labels would be read from new devices. (e.g. by the first 'pvs' command after the new device appeared.) After that commit, _get_all_devices() was called after get_vgnameids() was finished scanning labels. So, new devices would be missed while scanning labels. When _get_all_devices() saw the new devices (after labels were scanned), those devices were added to the .cache file. This meant that the second 'pvs' command would see the devices because they would be in .cache. Now, the full device scan is factored out of _get_all_devices() and called by itself at the start of the command so that new devices will be known before get_vgnameids() scans labels.
2015-12-11 23:02:36 +03:00
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
/*
* _choose_preferred_devs() returns:
*
* . 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
* del_cache_devs onto _unused_duplicate_devs.
*/
if (!dm_list_empty(&_found_duplicate_devs)) {
dm_list_init(&del_cache_devs);
dm_list_init(&add_cache_devs);
scan: drop bcache between lvm shell commands A running lvm shell keeps all lvm devices open unless the bcache is dropped.
2018-04-06 21:05:17 +03:00
log_debug_cache("Resolving duplicate devices");
lvmcache: 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
_choose_preferred_devs(cmd, &del_cache_devs, &add_cache_devs);
dm_list_iterate_items(devl, &del_cache_devs) {
log_debug_cache("Drop duplicate device %s in lvmcache", dev_name(devl->dev));
lvmcache: add optional dev arg to lvmcache_info_from_pvid A number of places are working on a specific dev when they call lvmcache_info_from_pvid() to look up an info struct based on a pvid. In those cases, pass the dev being used to lvmcache_info_from_pvid(). When a dev is specified, lvmcache_info_from_pvid() will verify that the cached info it's using matches the dev being processed before returning the info. Calling code will not mistakenly get info for the wrong dev when duplicate devs exist. This confusion was happening when scanning labels when duplicate devs existed. label_read for the first dev would add an info struct to lvmcache for that dev/pvid. label_read for the second dev would see the pvid in lvmcache from first dev, and mistakenly conclude that the label_read from the second dev can be skipped because it's already been done. By verifying that the dev for the cached pvid matches the dev being read, this mismatch is avoided and the label is actually read from the second duplicate.
2016-06-06 22:04:17 +03:00
if ((info = lvmcache_info_from_pvid(devl->dev->pvid, NULL, 0)))
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
lvmcache_del(info);
}
dm_list_iterate_items(devl, &add_cache_devs) {
log_debug_cache("Rescan preferred device %s for lvmcache", dev_name(devl->dev));
scan: use new label_scan for lvmcache_label_scan To do label scanning, lvm code calls lvmcache_label_scan(). Change lvmcache_label_scan() to use the new label_scan() based on bcache. Also add lvmcache_label_rescan_vg() which calls the new label_scan_devs() which does label scanning on only the specified devices. This is for a subsequent commit and is not yet used.
2018-02-07 22:14:08 +03:00
label_read(devl->dev, NULL, UINT64_C(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
}
dm_list_splice(&_unused_duplicate_devs, &del_cache_devs);
}
A new cache.
2002-11-18 16:53:58 +03:00
/* Perform any format-specific scanning e.g. text files */
Fix scanning of VGs without in-PV mdas. Set cmd->independent_metadata_areas if metadata/dirs or disk_areas in use. - Identify and record this state. Don't skip full scan when independent mdas are present even if memlock is set. - Clusters and OOM aren't supported, so no problem doing the proper scans. Avoid revalidating the label cache immediately after scanning. - A simple optimisation. Support scanning for a single VG in independent mdas. - Not used by the fix but I left it in anyway as later patches might use it.
2010-12-11 01:39:52 +03:00
if (cmd->independent_metadata_areas)
dm_list_iterate_items(fmt, &cmd->formats)
if (fmt->ops->scan && !fmt->ops->scan(fmt, NULL))
goto out;
A new cache.
2002-11-18 16:53:58 +03:00
r = 1;
out:
_scanning_in_progress = 0;
scan: drop bcache between lvm shell commands A running lvm shell keeps all lvm devices open unless the bcache is dropped.
2018-04-06 21:05:17 +03:00
dm_list_iterate_items(vginfo, &_vginfos) {
if (is_orphan_vg(vginfo->vgname))
continue;
vginfo_count++;
}
log_debug_cache("Found VG info for %d VGs", vginfo_count);
A new cache.
2002-11-18 16:53:58 +03:00
return r;
}
toollib: avoid repeated lvmetad vg_lookup In process_each_{vg,lv,pv} when no vgname args are given, the first step is to get a list of all vgid/vgname on the system. This is exactly what lvmetad returns from a vg_list request. The current code is doing a vg_lookup on each VG after the vg_list and populating lvmcache with the info for each VG. These preliminary vg_lookup's are unnecessary, because they will be done again when the processing functions call vg_read. This patch eliminates the initial round of vg_lookup's, which can roughly cut in half the number of lvmetad requests and save a lot of extra work.
2015-05-06 00:24:50 +03:00
int lvmcache_get_vgnameids(struct cmd_context *cmd, int include_internal,
struct dm_list *vgnameids)
{
struct vgnameid_list *vgnl;
struct lvmcache_vginfo *vginfo;
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;
}
Remove unnecessary full_scan parameter from get_vgids and get_vgnames calls.
2010-03-16 19:57:03 +03:00
struct dm_list *lvmcache_get_vgids(struct cmd_context *cmd,
int include_internal)
Fix vgexport/vgimport to set/reset PV exported flag so pv_attr is correct. Add vgid to struct physical_volume and pass with vg_name to some functions.
2006-04-13 01:23:04 +04:00
{
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
struct dm_list *vgids;
Fix vgexport/vgimport to set/reset PV exported flag so pv_attr is correct. Add vgid to struct physical_volume and pass with vg_name to some functions.
2006-04-13 01:23:04 +04:00
struct lvmcache_vginfo *vginfo;
The lvmetad client-side integration. Only active when use_lvmetad = 1 is set in lvm.conf *and* lvmetad is running.
2012-02-23 17:11:07 +04:00
// TODO plug into lvmetad here automagically?
vgrename: use process_each_vg Use process_each_vg() to lock and read the old VG, and then call the main vgrename code. When real VG names are used (not a UUID in place of the old name), the command still pre-locks the new name (when strcmp wants it locked first), before calling process_each_vg on the old name. In the case where the old name is replaced with a UUID, process_each_vg now translates that UUID into the real VG name, which it locks and reads. In this case, we cannot do pre-locking to maintain lock ordering because the old name is unknown. So, in this case the strcmp based lock ordering is suppressed and the old name is always locked first. This opens a remote chance for lock ordering conflict between racing vgrenames between two names where one or both commands use the UUID.
2015-12-01 23:09:01 +03:00
lvmcache_label_scan(cmd);
Fix vgexport/vgimport to set/reset PV exported flag so pv_attr is correct. Add vgid to struct physical_volume and pass with vg_name to some functions.
2006-04-13 01:23:04 +04:00
if (!(vgids = str_list_create(cmd->mem))) {
log_error("vgids list allocation failed");
return NULL;
}
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
dm_list_iterate_items(vginfo, &_vginfos) {
This is related to liblvm and its lvm_list_vg_names() and lvm_list_vg_uuids() functions where we should not expose internal VG names/uuids (the ones with "#" prefix )through the interface. Otherwise, we could end up with library users opening internal VGs which will initiate locking mechanism that won't be cleaned up properly. "#orphans_{lvm1, lvm2, pool}" names are treated in a special way, they are truncated first to "orphans" and this is used as a part of the lock name then (e.g. while calling lvm_vg_open()). When library user calls lvm_vg_close(), the original name "orphans_{lvm1, lvm2, pool}" is used directly and therefore no unlock occurs. We should exclude internal VG names and uuids in the lists provided by lvmcache: lvmcache_get_vgids() and lvmcache_get_vgnames().
2010-02-03 17:08:39 +03:00
if (!include_internal && is_orphan_vg(vginfo->vgname))
continue;
Some whitespace tidy-ups.
2008-01-30 17:00:02 +03:00
if (!str_list_add(cmd->mem, vgids,
Fix vgexport/vgimport to set/reset PV exported flag so pv_attr is correct. Add vgid to struct physical_volume and pass with vg_name to some functions.
2006-04-13 01:23:04 +04:00
dm_pool_strdup(cmd->mem, vginfo->vgid))) {
log_error("strlist allocation failed");
return NULL;
}
}
return vgids;
}
Remove unnecessary full_scan parameter from get_vgids and get_vgnames calls.
2010-03-16 19:57:03 +03:00
struct dm_list *lvmcache_get_vgnames(struct cmd_context *cmd,
int include_internal)
A new cache.
2002-11-18 16:53:58 +03:00
{
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
struct dm_list *vgnames;
tidy
2006-04-11 23:09:55 +04:00
struct lvmcache_vginfo *vginfo;
A new cache.
2002-11-18 16:53:58 +03:00
vgrename: use process_each_vg Use process_each_vg() to lock and read the old VG, and then call the main vgrename code. When real VG names are used (not a UUID in place of the old name), the command still pre-locks the new name (when strcmp wants it locked first), before calling process_each_vg on the old name. In the case where the old name is replaced with a UUID, process_each_vg now translates that UUID into the real VG name, which it locks and reads. In this case, we cannot do pre-locking to maintain lock ordering because the old name is unknown. So, in this case the strcmp based lock ordering is suppressed and the old name is always locked first. This opens a remote chance for lock ordering conflict between racing vgrenames between two names where one or both commands use the UUID.
2015-12-01 23:09:01 +03:00
lvmcache_label_scan(cmd);
A new cache.
2002-11-18 16:53:58 +03:00
more str_list fns
2003-10-16 00:04:29 +04:00
if (!(vgnames = str_list_create(cmd->mem))) {
Update error return and comments for lvm_list_vg_names/uuids. The two liblvm functions that return a list of vgnames and vguuids use cmd->mem to allocate the list. Make it clear to the caller that this memory will be freed when the LVM handle is freed. Clean up and clarify the return value of the functions. In the case of a memory allocation error, add a couple log_errnos to the internal code, and make it clear that memory allocation returns a NULL pointer. If there are no VGs in the system, the list returned is an empty list. Make a note of the fact that currently we return hidden VG names, how these can be detected (always start with "#"), and that they should not be used. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-07-27 15:00:17 +04:00
log_errno(ENOMEM, "vgnames list allocation failed");
A new cache.
2002-11-18 16:53:58 +03:00
return NULL;
}
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
dm_list_iterate_items(vginfo, &_vginfos) {
This is related to liblvm and its lvm_list_vg_names() and lvm_list_vg_uuids() functions where we should not expose internal VG names/uuids (the ones with "#" prefix )through the interface. Otherwise, we could end up with library users opening internal VGs which will initiate locking mechanism that won't be cleaned up properly. "#orphans_{lvm1, lvm2, pool}" names are treated in a special way, they are truncated first to "orphans" and this is used as a part of the lock name then (e.g. while calling lvm_vg_open()). When library user calls lvm_vg_close(), the original name "orphans_{lvm1, lvm2, pool}" is used directly and therefore no unlock occurs. We should exclude internal VG names and uuids in the lists provided by lvmcache: lvmcache_get_vgids() and lvmcache_get_vgnames().
2010-02-03 17:08:39 +03:00
if (!include_internal && is_orphan_vg(vginfo->vgname))
continue;
Some whitespace tidy-ups.
2008-01-30 17:00:02 +03:00
if (!str_list_add(cmd->mem, vgnames,
tidy
2006-04-11 23:09:55 +04:00
dm_pool_strdup(cmd->mem, vginfo->vgname))) {
Update error return and comments for lvm_list_vg_names/uuids. The two liblvm functions that return a list of vgnames and vguuids use cmd->mem to allocate the list. Make it clear to the caller that this memory will be freed when the LVM handle is freed. Clean up and clarify the return value of the functions. In the case of a memory allocation error, add a couple log_errnos to the internal code, and make it clear that memory allocation returns a NULL pointer. If there are no VGs in the system, the list returned is an empty list. Make a note of the fact that currently we return hidden VG names, how these can be detected (always start with "#"), and that they should not be used. Author: Dave Wysochanski <dwysocha@redhat.com>
2009-07-27 15:00:17 +04:00
log_errno(ENOMEM, "strlist allocation failed");
A new cache.
2002-11-18 16:53:58 +03:00
return NULL;
}
}
return vgnames;
}
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
struct dm_list *lvmcache_get_pvids(struct cmd_context *cmd, const char *vgname,
Invalidate cache if composition of VG changed externally.
2006-04-21 23:12:41 +04:00
const char *vgid)
{
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
struct dm_list *pvids;
Invalidate cache if composition of VG changed externally.
2006-04-21 23:12:41 +04:00
struct lvmcache_vginfo *vginfo;
struct lvmcache_info *info;
if (!(pvids = str_list_create(cmd->mem))) {
log_error("pvids list allocation failed");
return NULL;
}
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
if (!(vginfo = lvmcache_vginfo_from_vgname(vgname, vgid)))
Invalidate cache if composition of VG changed externally.
2006-04-21 23:12:41 +04:00
return pvids;
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
dm_list_iterate_items(info, &vginfo->infos) {
Some whitespace tidy-ups.
2008-01-30 17:00:02 +03:00
if (!str_list_add(cmd->mem, pvids,
Invalidate cache if composition of VG changed externally.
2006-04-21 23:12:41 +04:00
dm_pool_strdup(cmd->mem, info->dev->pvid))) {
log_error("strlist allocation failed");
return NULL;
}
}
return pvids;
}
scan: use new label_scan for lvmcache_label_scan To do label scanning, lvm code calls lvmcache_label_scan(). Change lvmcache_label_scan() to use the new label_scan() based on bcache. Also add lvmcache_label_rescan_vg() which calls the new label_scan_devs() which does label scanning on only the specified devices. This is for a subsequent commit and is not yet used.
2018-02-07 22:14:08 +03:00
int lvmcache_get_vg_devs(struct cmd_context *cmd,
struct lvmcache_vginfo *vginfo,
struct dm_list *devs)
A new cache.
2002-11-18 16:53:58 +03:00
{
Another sync point - numerous fixes & clean ups.
2003-07-05 02:34:56 +04:00
struct lvmcache_info *info;
scan: use new label_scan for lvmcache_label_scan To do label scanning, lvm code calls lvmcache_label_scan(). Change lvmcache_label_scan() to use the new label_scan() based on bcache. Also add lvmcache_label_rescan_vg() which calls the new label_scan_devs() which does label scanning on only the specified devices. This is for a subsequent commit and is not yet used.
2018-02-07 22:14:08 +03:00
struct device_list *devl;
A new cache.
2002-11-18 16:53:58 +03:00
scan: use new label_scan for lvmcache_label_scan To do label scanning, lvm code calls lvmcache_label_scan(). Change lvmcache_label_scan() to use the new label_scan() based on bcache. Also add lvmcache_label_rescan_vg() which calls the new label_scan_devs() which does label scanning on only the specified devices. This is for a subsequent commit and is not yet used.
2018-02-07 22:14:08 +03:00
dm_list_iterate_items(info, &vginfo->infos) {
if (!(devl = dm_pool_zalloc(cmd->mem, sizeof(*devl))))
return_0;
The lvmetad client-side integration. Only active when use_lvmetad = 1 is set in lvm.conf *and* lvmetad is running.
2012-02-23 17:11:07 +04:00
scan: use new label_scan for lvmcache_label_scan To do label scanning, lvm code calls lvmcache_label_scan(). Change lvmcache_label_scan() to use the new label_scan() based on bcache. Also add lvmcache_label_rescan_vg() which calls the new label_scan_devs() which does label scanning on only the specified devices. This is for a subsequent commit and is not yet used.
2018-02-07 22:14:08 +03:00
devl->dev = info->dev;
dm_list_add(devs, &devl->list);
A new cache.
2002-11-18 16:53:58 +03:00
}
scan: use new label_scan for lvmcache_label_scan To do label scanning, lvm code calls lvmcache_label_scan(). Change lvmcache_label_scan() to use the new label_scan() based on bcache. Also add lvmcache_label_rescan_vg() which calls the new label_scan_devs() which does label scanning on only the specified devices. This is for a subsequent commit and is not yet used.
2018-02-07 22:14:08 +03:00
return 1;
Defer writing PV labels to vg_write. Store label_sector only in struct physical_volume.
2011-06-01 23:29:31 +04:00
}
scan: use new label_scan for lvmcache_label_scan To do label scanning, lvm code calls lvmcache_label_scan(). Change lvmcache_label_scan() to use the new label_scan() based on bcache. Also add lvmcache_label_rescan_vg() which calls the new label_scan_devs() which does label scanning on only the specified devices. This is for a subsequent commit and is not yet used.
2018-02-07 22:14:08 +03:00
static struct device *_device_from_pvid(const struct id *pvid, uint64_t *label_sector)
Defer writing PV labels to vg_write. Store label_sector only in struct physical_volume.
2011-06-01 23:29:31 +04:00
{
scan: use new label_scan for lvmcache_label_scan To do label scanning, lvm code calls lvmcache_label_scan(). Change lvmcache_label_scan() to use the new label_scan() based on bcache. Also add lvmcache_label_rescan_vg() which calls the new label_scan_devs() which does label scanning on only the specified devices. This is for a subsequent commit and is not yet used.
2018-02-07 22:14:08 +03:00
struct lvmcache_info *info;
A new cache.
2002-11-18 16:53:58 +03:00
scan: use new label_scan for lvmcache_label_scan To do label scanning, lvm code calls lvmcache_label_scan(). Change lvmcache_label_scan() to use the new label_scan() based on bcache. Also add lvmcache_label_rescan_vg() which calls the new label_scan_devs() which does label scanning on only the specified devices. This is for a subsequent commit and is not yet used.
2018-02-07 22:14:08 +03:00
if ((info = lvmcache_info_from_pvid((const char *) pvid, NULL, 0))) {
if (info->label && label_sector)
*label_sector = info->label->sector;
return info->dev;
}
A new cache.
2002-11-18 16:53:58 +03:00
scan: use new label_scan for lvmcache_label_scan To do label scanning, lvm code calls lvmcache_label_scan(). Change lvmcache_label_scan() to use the new label_scan() based on bcache. Also add lvmcache_label_rescan_vg() which calls the new label_scan_devs() which does label scanning on only the specified devices. This is for a subsequent commit and is not yet used.
2018-02-07 22:14:08 +03:00
return NULL;
}
Another sync point - numerous fixes & clean ups.
2003-07-05 02:34:56 +04:00
scan: use new label_scan for lvmcache_label_scan To do label scanning, lvm code calls lvmcache_label_scan(). Change lvmcache_label_scan() to use the new label_scan() based on bcache. Also add lvmcache_label_rescan_vg() which calls the new label_scan_devs() which does label scanning on only the specified devices. This is for a subsequent commit and is not yet used.
2018-02-07 22:14:08 +03:00
struct device *lvmcache_device_from_pvid(struct cmd_context *cmd, const struct id *pvid, uint64_t *label_sector)
{
struct device *dev;
A new cache.
2002-11-18 16:53:58 +03:00
Defer writing PV labels to vg_write. Store label_sector only in struct physical_volume.
2011-06-01 23:29:31 +04:00
dev = _device_from_pvid(pvid, label_sector);
if (dev)
return dev;
A new cache.
2002-11-18 16:53:58 +03:00
scan: use new label_scan for lvmcache_label_scan To do label scanning, lvm code calls lvmcache_label_scan(). Change lvmcache_label_scan() to use the new label_scan() based on bcache. Also add lvmcache_label_rescan_vg() which calls the new label_scan_devs() which does label scanning on only the specified devices. This is for a subsequent commit and is not yet used.
2018-02-07 22:14:08 +03:00
log_debug_devs("No device with uuid %s.", (const char *)pvid);
A new cache.
2002-11-18 16:53:58 +03:00
return NULL;
}
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
const char *lvmcache_pvid_from_devname(struct cmd_context *cmd,
cleanup: avoid gcc warns Some older systems may had global declaration to cause gcc warning. Rename for cases we don't care...
2016-04-08 12:36:02 +03:00
const char *devname)
Add pvid_from_devname() lvmcache function. Add supporting function for mappings from devname -> pvid -> vgname.
2010-05-19 15:52:07 +04:00
{
struct device *dev;
if (!(dev = dev_cache_get(devname, cmd->filter))) {
log_error("%s: Couldn't find device. Check your filters?",
devname);
return NULL;
}
scan: use new label_scan for lvmcache_label_scan To do label scanning, lvm code calls lvmcache_label_scan(). Change lvmcache_label_scan() to use the new label_scan() based on bcache. Also add lvmcache_label_rescan_vg() which calls the new label_scan_devs() which does label scanning on only the specified devices. This is for a subsequent commit and is not yet used.
2018-02-07 22:14:08 +03:00
if (!(label_read(dev, NULL, UINT64_C(0))))
Add pvid_from_devname() lvmcache function. Add supporting function for mappings from devname -> pvid -> vgname.
2010-05-19 15:52:07 +04:00
return NULL;
return dev->pvid;
}
vgcreate, pvcreate, vgextend: don't use a device with duplicates If duplicate orphan PVs exist, don't allow one of them to be used for vgcreate/pvcreate/vgextend.
2016-06-06 23:39:51 +03:00
int lvmcache_pvid_in_unchosen_duplicates(const char *pvid)
{
struct device_list *devl;
dm_list_iterate_items(devl, &_unused_duplicate_devs) {
if (!strncmp(devl->dev->pvid, pvid, ID_LEN))
return 1;
}
return 0;
}
Add pvid_from_devname() lvmcache function. Add supporting function for mappings from devname -> pvid -> vgname.
2010-05-19 15:52:07 +04:00
Refactor some vginfo manipulation code.
2008-05-19 23:49:56 +04:00
static int _free_vginfo(struct lvmcache_vginfo *vginfo)
{
Fix segfault after _free_vginfo by remembering to remove vginfo from list.
2008-06-09 20:22:33 +04:00
struct lvmcache_vginfo *primary_vginfo, *vginfo2;
Refactor some vginfo manipulation code.
2008-05-19 23:49:56 +04:00
int r = 1;
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
vginfo2 = primary_vginfo = lvmcache_vginfo_from_vgname(vginfo->vgname, NULL);
Fix segfault after _free_vginfo by remembering to remove vginfo from list.
2008-06-09 20:22:33 +04:00
if (vginfo == primary_vginfo) {
Avoid spurious duplicate VG messages referring to VGs that are gone. (untested)
2008-05-29 02:27:47 +04:00
dm_hash_remove(_vgname_hash, vginfo->vgname);
if (vginfo->next && !dm_hash_insert(_vgname_hash, vginfo->vgname,
vginfo->next)) {
log_error("_vgname_hash re-insertion for %s failed",
vginfo->vgname);
r = 0;
}
check: add internal errors for unexpected paths Adding couple INTERNAL_ERROR reports for unwanted parameters: Ensure the 'top' metadata node cannot be NULL for lvmetad. Make obvious vginfo2 cannot be NULL. Report internal error if handler and vg is undefined. Check for handle in poll_vg(). Ensure seg is not NULL in dev_manager_transient(). Report missing read_ahead for _lv_read_ahead_single(). Check for report handler in dm_report_object(). Check missing VG in _vgreduce_single().
2012-06-21 14:43:31 +04:00
} else
while (vginfo2) {
if (vginfo2->next == vginfo) {
vginfo2->next = vginfo->next;
break;
}
vginfo2 = vginfo2->next;
Fix segfault after _free_vginfo by remembering to remove vginfo from list.
2008-06-09 20:22:33 +04:00
}
Refactor some vginfo manipulation code.
2008-05-19 23:49:56 +04:00
cleanup: drop unneeded test dmfree tests for NULL
2016-02-25 18:51:14 +03:00
dm_free(vginfo->system_id);
Skip check for NULL before dm_free dm_free makes this test itself.
2011-04-21 17:15:26 +04:00
dm_free(vginfo->vgname);
dm_free(vginfo->creation_host);
lvmcache: rename suspended_vg to saved_vg The copy of the VG which clvmd stashes in lvmcache should not only be used between suspend and resume, but between sequential LV operations in clvmd, so that clvmd does not need to reread the VG for each one. Prepare for that by renaming the stashed VG as "saved_vg".
2018-04-24 20:18:22 +03:00
_saved_vg_free(vginfo, 1, 1);
Refactor some vginfo manipulation code.
2008-05-19 23:49:56 +04:00
fix _free_vginfo not to remove a ref to a *different* vginfo from the vgid cache
2008-06-06 16:43:40 +04:00
if (*vginfo->vgid && _vgid_hash &&
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
lvmcache_vginfo_from_vgid(vginfo->vgid) == vginfo)
Refactor some vginfo manipulation code.
2008-05-19 23:49:56 +04:00
dm_hash_remove(_vgid_hash, vginfo->vgid);
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
dm_list_del(&vginfo->list);
Refactor some vginfo manipulation code.
2008-05-19 23:49:56 +04:00
dm_free(vginfo);
return r;
}
Fix vgreduce to use vg_split_mdas to check sufficient mdas remain. Add (empty) orphan VGs to lvmcache during initialisation. Fix orphan VG name used for format_pool.
2008-04-08 16:49:21 +04:00
/*
* vginfo must be info->vginfo unless info is NULL
*/
static int _drop_vginfo(struct lvmcache_info *info, struct lvmcache_vginfo *vginfo)
A new cache.
2002-11-18 16:53:58 +03:00
{
Refactor some vginfo manipulation code.
2008-05-19 23:49:56 +04:00
if (info)
_vginfo_detach_info(info);
If two or more VGs are found with the same name, use one that is not exported.
2006-04-12 21:54:11 +04:00
Refactor some vginfo manipulation code.
2008-05-19 23:49:56 +04:00
/* vginfo still referenced? */
if (!vginfo || is_orphan_vg(vginfo->vgname) ||
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
!dm_list_empty(&vginfo->infos))
Refactor some vginfo manipulation code.
2008-05-19 23:49:56 +04:00
return 1;
A new cache.
2002-11-18 16:53:58 +03:00
Refactor some vginfo manipulation code.
2008-05-19 23:49:56 +04:00
if (!_free_vginfo(vginfo))
return_0;
If two or more VGs are found with the same name, use one that is not exported.
2006-04-12 21:54:11 +04:00
return 1;
A new cache.
2002-11-18 16:53:58 +03:00
}
Another sync point - numerous fixes & clean ups.
2003-07-05 02:34:56 +04:00
void lvmcache_del(struct lvmcache_info *info)
A new cache.
2002-11-18 16:53:58 +03:00
{
if (info->dev->pvid[0] && _pvid_hash)
Use hash, bitset, malloc, pool from libdevmapper.
2005-10-17 03:03:59 +04:00
dm_hash_remove(_pvid_hash, info->dev->pvid);
A new cache.
2002-11-18 16:53:58 +03:00
Fix vgreduce to use vg_split_mdas to check sufficient mdas remain. Add (empty) orphan VGs to lvmcache during initialisation. Fix orphan VG name used for format_pool.
2008-04-08 16:49:21 +04:00
_drop_vginfo(info, info->vginfo);
A new cache.
2002-11-18 16:53:58 +03:00
info->label->labeller->ops->destroy_label(info->label->labeller,
pvremove: Update lvmcache => avoid spurious error messages.
2014-06-09 00:57:04 +04:00
info->label);
Use hash, bitset, malloc, pool from libdevmapper.
2005-10-17 03:03:59 +04:00
dm_free(info);
pvremove: Update lvmcache => avoid spurious error messages.
2014-06-09 00:57:04 +04:00
}
A new cache.
2002-11-18 16:53:58 +03:00
lvmcache: add shorter way to delete dev info Don't make the caller look up the info first.
2018-03-01 19:20:34 +03:00
void lvmcache_del_dev(struct device *dev)
{
struct lvmcache_info *info;
if ((info = lvmcache_info_from_pvid((const char *)dev->pvid, dev, 0)))
lvmcache_del(info);
}
Fix vgreduce to use vg_split_mdas to check sufficient mdas remain. Add (empty) orphan VGs to lvmcache during initialisation. Fix orphan VG name used for format_pool.
2008-04-08 16:49:21 +04:00
/*
* vginfo must be info->vginfo unless info is NULL (orphans)
*/
static int _lvmcache_update_vgid(struct lvmcache_info *info,
struct lvmcache_vginfo *vginfo,
const char *vgid)
A new cache.
2002-11-18 16:53:58 +03:00
{
Fix vgreduce to use vg_split_mdas to check sufficient mdas remain. Add (empty) orphan VGs to lvmcache during initialisation. Fix orphan VG name used for format_pool.
2008-04-08 16:49:21 +04:00
if (!vgid || !vginfo ||
!strncmp(vginfo->vgid, vgid, ID_LEN))
A new cache.
2002-11-18 16:53:58 +03:00
return 1;
Fix vgreduce to use vg_split_mdas to check sufficient mdas remain. Add (empty) orphan VGs to lvmcache during initialisation. Fix orphan VG name used for format_pool.
2008-04-08 16:49:21 +04:00
if (vginfo && *vginfo->vgid)
dm_hash_remove(_vgid_hash, vginfo->vgid);
Capture vgid in more places.
2006-04-11 02:09:00 +04:00
if (!vgid) {
Some fixmes 'len' calculation is unused ? Unreachable code could be removed or moved upward ?
2012-02-08 16:57:15 +04:00
/* FIXME: unreachable code path */
logging: classify log_debug messages Place most log_debug() messages into a class.
2013-01-08 02:30:29 +04:00
log_debug_cache("lvmcache: %s: clearing VGID", info ? dev_name(info->dev) : vginfo->vgname);
A new cache.
2002-11-18 16:53:58 +03:00
return 1;
Capture vgid in more places.
2006-04-11 02:09:00 +04:00
}
A new cache.
2002-11-18 16:53:58 +03:00
cleanup: more usage of dm_strncpy Use existing wrapper function arournd strncpy + buf[] = 0;
2018-03-02 18:25:37 +03:00
(void) dm_strncpy(vginfo->vgid, vgid, sizeof(vginfo->vgid));
Fix vgreduce to use vg_split_mdas to check sufficient mdas remain. Add (empty) orphan VGs to lvmcache during initialisation. Fix orphan VG name used for format_pool.
2008-04-08 16:49:21 +04:00
if (!dm_hash_insert(_vgid_hash, vginfo->vgid, vginfo)) {
Another sync point - numerous fixes & clean ups.
2003-07-05 02:34:56 +04:00
log_error("_lvmcache_update: vgid hash insertion failed: %s",
Fix vgreduce to use vg_split_mdas to check sufficient mdas remain. Add (empty) orphan VGs to lvmcache during initialisation. Fix orphan VG name used for format_pool.
2008-04-08 16:49:21 +04:00
vginfo->vgid);
A new cache.
2002-11-18 16:53:58 +03:00
return 0;
}
Fix vgreduce to use vg_split_mdas to check sufficient mdas remain. Add (empty) orphan VGs to lvmcache during initialisation. Fix orphan VG name used for format_pool.
2008-04-08 16:49:21 +04:00
if (!is_orphan_vg(vginfo->vgname))
debug: unify some tracing messages Introduce FMTVGID - although it might be possibly better to ensure vgid is always \0 ended string. Unify some lvmcache reported messages.
2016-04-12 14:06:16 +03:00
log_debug_cache("lvmcache %s: VG %s: set VGID to " FMTVGID ".",
logging: classify log_debug messages Place most log_debug() messages into a class.
2013-01-08 02:30:29 +04:00
(info) ? dev_name(info->dev) : "",
vginfo->vgname, vginfo->vgid);
Capture vgid in more places.
2006-04-11 02:09:00 +04:00
A new cache.
2002-11-18 16:53:58 +03:00
return 1;
}
If two or more VGs are found with the same name, use one that is not exported.
2006-04-12 21:54:11 +04:00
static int _insert_vginfo(struct lvmcache_vginfo *new_vginfo, const char *vgid,
When choosing between identically-named VGs, also consider creation_host.
2006-04-13 21:32:24 +04:00
uint32_t vgstatus, const char *creation_host,
If two or more VGs are found with the same name, use one that is not exported.
2006-04-12 21:54:11 +04:00
struct lvmcache_vginfo *primary_vginfo)
{
struct lvmcache_vginfo *last_vginfo = primary_vginfo;
Use __attribute__ consistently throughout.
2010-07-09 19:34:40 +04:00
char uuid_primary[64] __attribute__((aligned(8)));
char uuid_new[64] __attribute__((aligned(8)));
When choosing between identically-named VGs, also consider creation_host.
2006-04-13 21:32:24 +04:00
int use_new = 0;
Use vg_is_exported(vg) macro everywhere. This patch is all just cleanup and no other patch depends on it. Replace explicit dereference and check with vg_is_exported(). Update a few copyrights and remove unnecessary whitespace. Should be no functional change.
2009-09-14 23:44:15 +04:00
If two or more VGs are found with the same name, use one that is not exported.
2006-04-12 21:54:11 +04:00
/* Pre-existing VG takes precedence. Unexported VG takes precedence. */
if (primary_vginfo) {
Make SIZE_SHORT the default for display_size(). Fix some memory leaks in error paths found by coverity. Use C99 struct initialisers. Move DEFS into configure.h. Clean-ups to remove miscellaneous compiler warnings.
2006-05-10 01:23:51 +04:00
if (!id_write_format((const struct id *)vgid, uuid_new, sizeof(uuid_new)))
Fix vgexport/vgimport to set/reset PV exported flag so pv_attr is correct. Add vgid to struct physical_volume and pass with vg_name to some functions.
2006-04-13 01:23:04 +04:00
return_0;
Make SIZE_SHORT the default for display_size(). Fix some memory leaks in error paths found by coverity. Use C99 struct initialisers. Move DEFS into configure.h. Clean-ups to remove miscellaneous compiler warnings.
2006-05-10 01:23:51 +04:00
if (!id_write_format((const struct id *)&primary_vginfo->vgid, uuid_primary,
Fix vgexport/vgimport to set/reset PV exported flag so pv_attr is correct. Add vgid to struct physical_volume and pass with vg_name to some functions.
2006-04-13 01:23:04 +04:00
sizeof(uuid_primary)))
return_0;
When choosing between identically-named VGs, also consider creation_host.
2006-04-13 21:32:24 +04:00
/*
lvmcache: change duplicate VG name warnings to verbose When two different VGs with the same name exist, they are both stored in lvmcache using the vginfo->next list. Previously, the code would print warnings (sometimes) when adding VGs to this list. Now the duplicate VG names are handled by higher level code, so this list no longer needs to print warnings about duplicate VG names being found.
2015-12-01 00:28:22 +03:00
* vginfo is kept for each VG with the same name.
* They are saved with the vginfo->next list.
* These checks just decide the ordering of
* that list.
*
* FIXME: it should no longer matter what order
* the vginfo's are kept in, so we can probably
* remove these comparisons and reordering entirely.
*
When choosing between identically-named VGs, also consider creation_host.
2006-04-13 21:32:24 +04:00
* If Primary not exported, new exported => keep
* Else Primary exported, new not exported => change
* Else Primary has hostname for this machine => keep
* Else Primary has no hostname, new has one => change
* Else New has hostname for this machine => change
* Else Keep primary.
*/
if (!(primary_vginfo->status & EXPORTED_VG) &&
(vgstatus & EXPORTED_VG))
lvmcache: change duplicate VG name warnings to verbose When two different VGs with the same name exist, they are both stored in lvmcache using the vginfo->next list. Previously, the code would print warnings (sometimes) when adding VGs to this list. Now the duplicate VG names are handled by higher level code, so this list no longer needs to print warnings about duplicate VG names being found.
2015-12-01 00:28:22 +03:00
log_verbose("Cache: Duplicate VG name %s: "
"Existing %s takes precedence over "
"exported %s", new_vginfo->vgname,
uuid_primary, uuid_new);
When choosing between identically-named VGs, also consider creation_host.
2006-04-13 21:32:24 +04:00
else if ((primary_vginfo->status & EXPORTED_VG) &&
!(vgstatus & EXPORTED_VG)) {
lvmcache: change duplicate VG name warnings to verbose When two different VGs with the same name exist, they are both stored in lvmcache using the vginfo->next list. Previously, the code would print warnings (sometimes) when adding VGs to this list. Now the duplicate VG names are handled by higher level code, so this list no longer needs to print warnings about duplicate VG names being found.
2015-12-01 00:28:22 +03:00
log_verbose("Cache: Duplicate VG name %s: "
"%s takes precedence over exported %s",
new_vginfo->vgname, uuid_new,
uuid_primary);
When choosing between identically-named VGs, also consider creation_host.
2006-04-13 21:32:24 +04:00
use_new = 1;
} else if (primary_vginfo->creation_host &&
!strcmp(primary_vginfo->creation_host,
primary_vginfo->fmt->cmd->hostname))
lvmcache: change duplicate VG name warnings to verbose When two different VGs with the same name exist, they are both stored in lvmcache using the vginfo->next list. Previously, the code would print warnings (sometimes) when adding VGs to this list. Now the duplicate VG names are handled by higher level code, so this list no longer needs to print warnings about duplicate VG names being found.
2015-12-01 00:28:22 +03:00
log_verbose("Cache: Duplicate VG name %s: "
"Existing %s (created here) takes precedence "
"over %s", new_vginfo->vgname, uuid_primary,
uuid_new);
When choosing between identically-named VGs, also consider creation_host.
2006-04-13 21:32:24 +04:00
else if (!primary_vginfo->creation_host && creation_host) {
lvmcache: change duplicate VG name warnings to verbose When two different VGs with the same name exist, they are both stored in lvmcache using the vginfo->next list. Previously, the code would print warnings (sometimes) when adding VGs to this list. Now the duplicate VG names are handled by higher level code, so this list no longer needs to print warnings about duplicate VG names being found.
2015-12-01 00:28:22 +03:00
log_verbose("Cache: Duplicate VG name %s: "
"%s (with creation_host) takes precedence over %s",
new_vginfo->vgname, uuid_new,
uuid_primary);
When choosing between identically-named VGs, also consider creation_host.
2006-04-13 21:32:24 +04:00
use_new = 1;
} else if (creation_host &&
!strcmp(creation_host,
primary_vginfo->fmt->cmd->hostname)) {
lvmcache: change duplicate VG name warnings to verbose When two different VGs with the same name exist, they are both stored in lvmcache using the vginfo->next list. Previously, the code would print warnings (sometimes) when adding VGs to this list. Now the duplicate VG names are handled by higher level code, so this list no longer needs to print warnings about duplicate VG names being found.
2015-12-01 00:28:22 +03:00
log_verbose("Cache: Duplicate VG name %s: "
"%s (created here) takes precedence over %s",
new_vginfo->vgname, uuid_new,
uuid_primary);
When choosing between identically-named VGs, also consider creation_host.
2006-04-13 21:32:24 +04:00
use_new = 1;
lvmcache: change duplicate VG name warnings to verbose When two different VGs with the same name exist, they are both stored in lvmcache using the vginfo->next list. Previously, the code would print warnings (sometimes) when adding VGs to this list. Now the duplicate VG names are handled by higher level code, so this list no longer needs to print warnings about duplicate VG names being found.
2015-12-01 00:28:22 +03:00
} else {
log_verbose("Cache: Duplicate VG name %s: "
"Prefer existing %s vs new %s",
new_vginfo->vgname, uuid_primary, uuid_new);
When choosing between identically-named VGs, also consider creation_host.
2006-04-13 21:32:24 +04:00
}
if (!use_new) {
while (last_vginfo->next)
last_vginfo = last_vginfo->next;
last_vginfo->next = new_vginfo;
return 1;
}
If two or more VGs are found with the same name, use one that is not exported.
2006-04-12 21:54:11 +04:00
dm_hash_remove(_vgname_hash, primary_vginfo->vgname);
}
if (!dm_hash_insert(_vgname_hash, new_vginfo->vgname, new_vginfo)) {
log_error("cache_update: vg hash insertion failed: %s",
new_vginfo->vgname);
return 0;
}
if (primary_vginfo)
new_vginfo->next = primary_vginfo;
return 1;
}
Use lvmcache_update_vgname_and_id throughout.
2006-04-11 20:00:26 +04:00
static int _lvmcache_update_vgname(struct lvmcache_info *info,
Fix vgexport/vgimport to set/reset PV exported flag so pv_attr is correct. Add vgid to struct physical_volume and pass with vg_name to some functions.
2006-04-13 01:23:04 +04:00
const char *vgname, const char *vgid,
Fix vgreduce to use vg_split_mdas to check sufficient mdas remain. Add (empty) orphan VGs to lvmcache during initialisation. Fix orphan VG name used for format_pool.
2008-04-08 16:49:21 +04:00
uint32_t vgstatus, const char *creation_host,
const struct format_type *fmt)
A new cache.
2002-11-18 16:53:58 +03:00
{
lvmcache: simplify Recent changes allow some major simplification of the way lvmcache works and is used. lvmcache_label_scan is now called in a controlled fashion at the start of commands, and not via various unpredictable side effects. Remove various calls to it from other places. lvmcache_label_scan should not be called from anywhere during a command, because it produces an incorrect representation of PVs with no MDAs, and misclassifies them as orphans. This has been a long standing problem. The invalid flag and rescanning based on that is no longer used and removed. The 'force' variation is no longer needed and removed.
2018-04-09 21:40:49 +03:00
struct lvmcache_vginfo *vginfo, *primary_vginfo;
Fix up cache for PVs without mdas after consistent VG metadata is processed.
2008-06-27 19:18:31 +04:00
char mdabuf[32];
A new cache.
2002-11-18 16:53:58 +03:00
Fix vgreduce to use vg_split_mdas to check sufficient mdas remain. Add (empty) orphan VGs to lvmcache during initialisation. Fix orphan VG name used for format_pool.
2008-04-08 16:49:21 +04:00
if (!vgname || (info && info->vginfo && !strcmp(info->vginfo->vgname, vgname)))
A new cache.
2002-11-18 16:53:58 +03:00
return 1;
/* Remove existing vginfo entry */
Fix vgreduce to use vg_split_mdas to check sufficient mdas remain. Add (empty) orphan VGs to lvmcache during initialisation. Fix orphan VG name used for format_pool.
2008-04-08 16:49:21 +04:00
if (info)
_drop_vginfo(info, info->vginfo);
A new cache.
2002-11-18 16:53:58 +03:00
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
if (!(vginfo = lvmcache_vginfo_from_vgname(vgname, vgid))) {
lvmcache: simplify Recent changes allow some major simplification of the way lvmcache works and is used. lvmcache_label_scan is now called in a controlled fashion at the start of commands, and not via various unpredictable side effects. Remove various calls to it from other places. lvmcache_label_scan should not be called from anywhere during a command, because it produces an incorrect representation of PVs with no MDAs, and misclassifies them as orphans. This has been a long standing problem. The invalid flag and rescanning based on that is no longer used and removed. The 'force' variation is no longer needed and removed.
2018-04-09 21:40:49 +03:00
/*
* Create a vginfo struct for this VG and put the vginfo
* into the hash table.
*/
vgrename accepts vgid and exported VG.
2006-04-14 01:08:29 +04:00
Add dm_zalloc and use it and dm_pool_zalloc throughout.
2010-10-01 01:06:50 +04:00
if (!(vginfo = dm_zalloc(sizeof(*vginfo)))) {
Another sync point - numerous fixes & clean ups.
2003-07-05 02:34:56 +04:00
log_error("lvmcache_update_vgname: list alloc failed");
A new cache.
2002-11-18 16:53:58 +03:00
return 0;
}
Use hash, bitset, malloc, pool from libdevmapper.
2005-10-17 03:03:59 +04:00
if (!(vginfo->vgname = dm_strdup(vgname))) {
dm_free(vginfo);
A new cache.
2002-11-18 16:53:58 +03:00
log_error("cache vgname alloc failed for %s", vgname);
return 0;
}
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
dm_list_init(&vginfo->infos);
Avoid spurious duplicate VG messages referring to VGs that are gone. (untested)
2008-05-29 02:27:47 +04:00
/*
lvmcache: simplify Recent changes allow some major simplification of the way lvmcache works and is used. lvmcache_label_scan is now called in a controlled fashion at the start of commands, and not via various unpredictable side effects. Remove various calls to it from other places. lvmcache_label_scan should not be called from anywhere during a command, because it produces an incorrect representation of PVs with no MDAs, and misclassifies them as orphans. This has been a long standing problem. The invalid flag and rescanning based on that is no longer used and removed. The 'force' variation is no longer needed and removed.
2018-04-09 21:40:49 +03:00
* A different VG (different uuid) can exist with the same name.
* In this case, the two VGs will have separate vginfo structs,
* but the second will be linked onto the existing vginfo->next,
* not in the hash.
Avoid spurious duplicate VG messages referring to VGs that are gone. (untested)
2008-05-29 02:27:47 +04:00
*/
lvmcache: simplify Recent changes allow some major simplification of the way lvmcache works and is used. lvmcache_label_scan is now called in a controlled fashion at the start of commands, and not via various unpredictable side effects. Remove various calls to it from other places. lvmcache_label_scan should not be called from anywhere during a command, because it produces an incorrect representation of PVs with no MDAs, and misclassifies them as orphans. This has been a long standing problem. The invalid flag and rescanning based on that is no longer used and removed. The 'force' variation is no longer needed and removed.
2018-04-09 21:40:49 +03:00
primary_vginfo = lvmcache_vginfo_from_vgname(vgname, NULL);
Avoid spurious duplicate VG messages referring to VGs that are gone. (untested)
2008-05-29 02:27:47 +04:00
lvmcache: simplify Recent changes allow some major simplification of the way lvmcache works and is used. lvmcache_label_scan is now called in a controlled fashion at the start of commands, and not via various unpredictable side effects. Remove various calls to it from other places. lvmcache_label_scan should not be called from anywhere during a command, because it produces an incorrect representation of PVs with no MDAs, and misclassifies them as orphans. This has been a long standing problem. The invalid flag and rescanning based on that is no longer used and removed. The 'force' variation is no longer needed and removed.
2018-04-09 21:40:49 +03:00
if (!_insert_vginfo(vginfo, vgid, vgstatus, creation_host, primary_vginfo)) {
Use hash, bitset, malloc, pool from libdevmapper.
2005-10-17 03:03:59 +04:00
dm_free(vginfo->vgname);
dm_free(vginfo);
A new cache.
2002-11-18 16:53:58 +03:00
return 0;
}
lvmcache: simplify Recent changes allow some major simplification of the way lvmcache works and is used. lvmcache_label_scan is now called in a controlled fashion at the start of commands, and not via various unpredictable side effects. Remove various calls to it from other places. lvmcache_label_scan should not be called from anywhere during a command, because it produces an incorrect representation of PVs with no MDAs, and misclassifies them as orphans. This has been a long standing problem. The invalid flag and rescanning based on that is no longer used and removed. The 'force' variation is no longer needed and removed.
2018-04-09 21:40:49 +03:00
A new cache.
2002-11-18 16:53:58 +03:00
/* Ensure orphans appear last on list_iterate */
Add is_orphan_vg() and change all hardcoded checks to use it.
2007-11-02 16:06:42 +03:00
if (is_orphan_vg(vgname))
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
dm_list_add(&_vginfos, &vginfo->list);
A new cache.
2002-11-18 16:53:58 +03:00
else
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
dm_list_add_h(&_vginfos, &vginfo->list);
A new cache.
2002-11-18 16:53:58 +03:00
}
Refactor some vginfo manipulation code.
2008-05-19 23:49:56 +04:00
if (info)
_vginfo_attach_info(vginfo, info);
else if (!_lvmcache_update_vgid(NULL, vginfo, vgid)) /* Orphans */
Fix vgreduce to use vg_split_mdas to check sufficient mdas remain. Add (empty) orphan VGs to lvmcache during initialisation. Fix orphan VG name used for format_pool.
2008-04-08 16:49:21 +04:00
return_0;
A new cache.
2002-11-18 16:53:58 +03:00
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
_update_cache_vginfo_lock_state(vginfo, lvmcache_vgname_is_locked(vgname));
Rely upon internally-cached PV labels while corresponding VG lock is held.
2008-01-30 02:45:48 +03:00
A new cache.
2002-11-18 16:53:58 +03:00
/* FIXME Check consistency of list! */
Fix vgreduce to use vg_split_mdas to check sufficient mdas remain. Add (empty) orphan VGs to lvmcache during initialisation. Fix orphan VG name used for format_pool.
2008-04-08 16:49:21 +04:00
vginfo->fmt = fmt;
Fix up cache for PVs without mdas after consistent VG metadata is processed.
2008-06-27 19:18:31 +04:00
if (info) {
if (info->mdas.n)
debug: unify some tracing messages Introduce FMTVGID - although it might be possibly better to ensure vgid is always \0 ended string. Unify some lvmcache reported messages.
2016-04-12 14:06:16 +03:00
sprintf(mdabuf, " with %u mda(s)", dm_list_size(&info->mdas));
Fix up cache for PVs without mdas after consistent VG metadata is processed.
2008-06-27 19:18:31 +04:00
else
mdabuf[0] = '\0';
debug: unify some tracing messages Introduce FMTVGID - although it might be possibly better to ensure vgid is always \0 ended string. Unify some lvmcache reported messages.
2016-04-12 14:06:16 +03:00
log_debug_cache("lvmcache %s: now in VG %s%s%s%s%s.",
logging: classify log_debug messages Place most log_debug() messages into a class.
2013-01-08 02:30:29 +04:00
dev_name(info->dev),
vgname, vginfo->vgid[0] ? " (" : "",
vginfo->vgid[0] ? vginfo->vgid : "",
vginfo->vgid[0] ? ")" : "", mdabuf);
Fix up cache for PVs without mdas after consistent VG metadata is processed.
2008-06-27 19:18:31 +04:00
} else
log: Improve various device-related messages - Use 'lvmcache' consistently instead of 'metadata cache' - Always use 5 characters for source line number - Remember to convert uuids into printable form - Use <no name> rather than (null) when VG has no name.
2017-11-13 17:43:32 +03:00
log_debug_cache("lvmcache: Initialised VG %s.", vgname);
Improve detection of external changes affecting internal cache.
2005-03-22 01:40:35 +03:00
A new cache.
2002-11-18 16:53:58 +03:00
return 1;
}
When choosing between identically-named VGs, also consider creation_host.
2006-04-13 21:32:24 +04:00
static int _lvmcache_update_vgstatus(struct lvmcache_info *info, uint32_t vgstatus,
lvmcache: include system_id in vginfo cache Save system_id just like creation_host and lock_type strings in vginfo cache.
2015-11-30 20:32:17 +03:00
const char *creation_host, const char *lock_type,
const char *system_id)
When scanning, also record whether or not VG is exported.
2006-04-11 21:42:15 +04:00
{
if (!info || !info->vginfo)
return 1;
if ((info->vginfo->status & EXPORTED_VG) != (vgstatus & EXPORTED_VG))
debug: unify some tracing messages Introduce FMTVGID - although it might be possibly better to ensure vgid is always \0 ended string. Unify some lvmcache reported messages.
2016-04-12 14:06:16 +03:00
log_debug_cache("lvmcache %s: VG %s %s exported.",
logging: classify log_debug messages Place most log_debug() messages into a class.
2013-01-08 02:30:29 +04:00
dev_name(info->dev), info->vginfo->vgname,
vgstatus & EXPORTED_VG ? "now" : "no longer");
When scanning, also record whether or not VG is exported.
2006-04-11 21:42:15 +04:00
info->vginfo->status = vgstatus;
When choosing between identically-named VGs, also consider creation_host.
2006-04-13 21:32:24 +04:00
if (!creation_host)
lvmcache: add lock_type to VG summary and info structs vgsummary information contains provisional VG information that is obtained without holding the VG lock. This info can be used to lock the VG, and then read it with vg_read(). After the VG is read properly, the vgsummary info should be verified. Add the VG lock_type to the vgsummary. It needs to be known before the VG can be locked and read.
2015-07-24 23:20:37 +03:00
goto set_lock_type;
When choosing between identically-named VGs, also consider creation_host.
2006-04-13 21:32:24 +04:00
if (info->vginfo->creation_host && !strcmp(creation_host,
info->vginfo->creation_host))
lvmcache: add lock_type to VG summary and info structs vgsummary information contains provisional VG information that is obtained without holding the VG lock. This info can be used to lock the VG, and then read it with vg_read(). After the VG is read properly, the vgsummary info should be verified. Add the VG lock_type to the vgsummary. It needs to be known before the VG can be locked and read.
2015-07-24 23:20:37 +03:00
goto set_lock_type;
When choosing between identically-named VGs, also consider creation_host.
2006-04-13 21:32:24 +04:00
cleanup: drop extra compare dm_free() already validates for NULL itself.
2017-07-16 11:22:20 +03:00
dm_free(info->vginfo->creation_host);
When choosing between identically-named VGs, also consider creation_host.
2006-04-13 21:32:24 +04:00
if (!(info->vginfo->creation_host = dm_strdup(creation_host))) {
debug: unify some tracing messages Introduce FMTVGID - although it might be possibly better to ensure vgid is always \0 ended string. Unify some lvmcache reported messages.
2016-04-12 14:06:16 +03:00
log_error("cache creation host alloc failed for %s.",
When choosing between identically-named VGs, also consider creation_host.
2006-04-13 21:32:24 +04:00
creation_host);
return 0;
}
debug: unify some tracing messages Introduce FMTVGID - although it might be possibly better to ensure vgid is always \0 ended string. Unify some lvmcache reported messages.
2016-04-12 14:06:16 +03:00
log_debug_cache("lvmcache %s: VG %s: set creation host to %s.",
logging: classify log_debug messages Place most log_debug() messages into a class.
2013-01-08 02:30:29 +04:00
dev_name(info->dev), info->vginfo->vgname, creation_host);
When choosing between identically-named VGs, also consider creation_host.
2006-04-13 21:32:24 +04:00
lvmcache: add lock_type to VG summary and info structs vgsummary information contains provisional VG information that is obtained without holding the VG lock. This info can be used to lock the VG, and then read it with vg_read(). After the VG is read properly, the vgsummary info should be verified. Add the VG lock_type to the vgsummary. It needs to be known before the VG can be locked and read.
2015-07-24 23:20:37 +03:00
set_lock_type:
if (!lock_type)
lvmcache: include system_id in vginfo cache Save system_id just like creation_host and lock_type strings in vginfo cache.
2015-11-30 20:32:17 +03:00
goto set_system_id;
lvmcache: add lock_type to VG summary and info structs vgsummary information contains provisional VG information that is obtained without holding the VG lock. This info can be used to lock the VG, and then read it with vg_read(). After the VG is read properly, the vgsummary info should be verified. Add the VG lock_type to the vgsummary. It needs to be known before the VG can be locked and read.
2015-07-24 23:20:37 +03:00
if (info->vginfo->lock_type && !strcmp(lock_type, info->vginfo->lock_type))
lvmcache: include system_id in vginfo cache Save system_id just like creation_host and lock_type strings in vginfo cache.
2015-11-30 20:32:17 +03:00
goto set_system_id;
lvmcache: add lock_type to VG summary and info structs vgsummary information contains provisional VG information that is obtained without holding the VG lock. This info can be used to lock the VG, and then read it with vg_read(). After the VG is read properly, the vgsummary info should be verified. Add the VG lock_type to the vgsummary. It needs to be known before the VG can be locked and read.
2015-07-24 23:20:37 +03:00
cleanup: drop extra compare dm_free() already validates for NULL itself.
2017-07-16 11:22:20 +03:00
dm_free(info->vginfo->lock_type);
lvmcache: add lock_type to VG summary and info structs vgsummary information contains provisional VG information that is obtained without holding the VG lock. This info can be used to lock the VG, and then read it with vg_read(). After the VG is read properly, the vgsummary info should be verified. Add the VG lock_type to the vgsummary. It needs to be known before the VG can be locked and read.
2015-07-24 23:20:37 +03:00
if (!(info->vginfo->lock_type = dm_strdup(lock_type))) {
lvmcache: include system_id in vginfo cache Save system_id just like creation_host and lock_type strings in vginfo cache.
2015-11-30 20:32:17 +03:00
log_error("cache lock_type alloc failed for %s", lock_type);
return 0;
}
debug: unify some tracing messages Introduce FMTVGID - although it might be possibly better to ensure vgid is always \0 ended string. Unify some lvmcache reported messages.
2016-04-12 14:06:16 +03:00
log_debug_cache("lvmcache %s: VG %s: set lock_type to %s.",
lvmcache: include system_id in vginfo cache Save system_id just like creation_host and lock_type strings in vginfo cache.
2015-11-30 20:32:17 +03:00
dev_name(info->dev), info->vginfo->vgname, lock_type);
set_system_id:
if (!system_id)
goto out;
if (info->vginfo->system_id && !strcmp(system_id, info->vginfo->system_id))
goto out;
cleanup: drop extra compare dm_free() already validates for NULL itself.
2017-07-16 11:22:20 +03:00
dm_free(info->vginfo->system_id);
lvmcache: include system_id in vginfo cache Save system_id just like creation_host and lock_type strings in vginfo cache.
2015-11-30 20:32:17 +03:00
if (!(info->vginfo->system_id = dm_strdup(system_id))) {
log_error("cache system_id alloc failed for %s", system_id);
lvmcache: add lock_type to VG summary and info structs vgsummary information contains provisional VG information that is obtained without holding the VG lock. This info can be used to lock the VG, and then read it with vg_read(). After the VG is read properly, the vgsummary info should be verified. Add the VG lock_type to the vgsummary. It needs to be known before the VG can be locked and read.
2015-07-24 23:20:37 +03:00
return 0;
}
debug: unify some tracing messages Introduce FMTVGID - although it might be possibly better to ensure vgid is always \0 ended string. Unify some lvmcache reported messages.
2016-04-12 14:06:16 +03:00
log_debug_cache("lvmcache %s: VG %s: set system_id to %s.",
lvmcache: include system_id in vginfo cache Save system_id just like creation_host and lock_type strings in vginfo cache.
2015-11-30 20:32:17 +03:00
dev_name(info->dev), info->vginfo->vgname, system_id);
lvmcache: add lock_type to VG summary and info structs vgsummary information contains provisional VG information that is obtained without holding the VG lock. This info can be used to lock the VG, and then read it with vg_read(). After the VG is read properly, the vgsummary info should be verified. Add the VG lock_type to the vgsummary. It needs to be known before the VG can be locked and read.
2015-07-24 23:20:37 +03:00
out:
When scanning, also record whether or not VG is exported.
2006-04-11 21:42:15 +04:00
return 1;
}
Fix vgreduce to use vg_split_mdas to check sufficient mdas remain. Add (empty) orphan VGs to lvmcache during initialisation. Fix orphan VG name used for format_pool.
2008-04-08 16:49:21 +04:00
int lvmcache_add_orphan_vginfo(const char *vgname, struct format_type *fmt)
{
if (!_lock_hash && !lvmcache_init()) {
log_error("Internal cache initialisation failed");
return 0;
}
return _lvmcache_update_vgname(NULL, vgname, vgname, 0, "", fmt);
}
scan: skip device rescan in vg_read For reporting commands (pvs,vgs,lvs,pvdisplay,vgdisplay,lvdisplay) we do not need to repeat the label scan of devices in vg_read if they all had matching metadata in the initial label scan. The data read by label scan can just be reused for the vg_read. This cuts the amount of device i/o in half, from two reads of each device to one. We have to be careful to avoid repairing the VG if we've skipped rescanning. (The VG repair code is very poor, and will be redone soon.)
2018-04-19 00:29:42 +03:00
/*
* FIXME: get rid of other callers of this function which call it
* in odd cases to "fix up" some bit of lvmcache state. Make those
* callers fix up what they need to directly, and leave this function
* with one purpose and caller.
*/
[io paths] Unpick agk's aio stuff
2018-04-20 18:43:50 +03:00
int lvmcache_update_vgname_and_id(struct lvmcache_info *info, struct lvmcache_vgsummary *vgsummary)
Use lvmcache_update_vgname_and_id throughout.
2006-04-11 20:00:26 +04:00
{
cache: Store metadata size and checksum. Refactor the recent metadata-reading optimisation patches. Remove the recently-added cache fields from struct labeller and struct format_instance. Instead, introduce struct lvmcache_vgsummary to wrap the VG information that lvmcache holds and add the metadata size and checksum to it. Allow this VG summary information to be looked up by metadata size + checksum. Adjust the debug log messages to make it clear when this shortcut has been successful. (This changes the optimisation slightly, and might be extendable further.) Add struct cached_vg_fmtdata to format-specific vg_read calls to preserve state alongside the VG across separate calls and indicate if the details supplied match, avoiding the need to read and process the VG metadata again.
2015-03-19 02:43:02 +03:00
const char *vgname = vgsummary->vgname;
const char *vgid = (char *)&vgsummary->vgid;
scan: skip device rescan in vg_read For reporting commands (pvs,vgs,lvs,pvdisplay,vgdisplay,lvdisplay) we do not need to repeat the label scan of devices in vg_read if they all had matching metadata in the initial label scan. The data read by label scan can just be reused for the vg_read. This cuts the amount of device i/o in half, from two reads of each device to one. We have to be careful to avoid repairing the VG if we've skipped rescanning. (The VG repair code is very poor, and will be redone soon.)
2018-04-19 00:29:42 +03:00
struct lvmcache_vginfo *vginfo;
cache: Store metadata size and checksum. Refactor the recent metadata-reading optimisation patches. Remove the recently-added cache fields from struct labeller and struct format_instance. Instead, introduce struct lvmcache_vgsummary to wrap the VG information that lvmcache holds and add the metadata size and checksum to it. Allow this VG summary information to be looked up by metadata size + checksum. Adjust the debug log messages to make it clear when this shortcut has been successful. (This changes the optimisation slightly, and might be extendable further.) Add struct cached_vg_fmtdata to format-specific vg_read calls to preserve state alongside the VG across separate calls and indicate if the details supplied match, avoiding the need to read and process the VG metadata again.
2015-03-19 02:43:02 +03:00
split orphan VG by format type
2008-02-06 18:47:28 +03:00
if (!vgname && !info->vginfo) {
#define an INTERNAL_ERROR macro and use it throughout LVM.
2009-12-16 22:22:11 +03:00
log_error(INTERNAL_ERROR "NULL vgname handed to cache");
split orphan VG by format type
2008-02-06 18:47:28 +03:00
/* FIXME Remove this */
vgname = info->fmt->orphan_vg_name;
vgid = vgname;
}
Fix vgreduce to use vg_split_mdas to check sufficient mdas remain. Add (empty) orphan VGs to lvmcache during initialisation. Fix orphan VG name used for format_pool.
2008-04-08 16:49:21 +04:00
Fix tracking of validity of PVs with no mdas in lvmcache.
2008-06-11 15:02:05 +04:00
/* If PV without mdas is already in a real VG, don't make it orphan */
Use mdas_empty_or_ignored() in place of checks for empty mda list. With the addition of ignored mdas, we replace all checks for an empty mda list with a new function to look for either an empty mda list or ignored mdas. Signed-off-by: Dave Wysochanski <dwysocha@redhat.com>
2010-06-29 00:34:58 +04:00
if (is_orphan_vg(vgname) && info->vginfo &&
mdas_empty_or_ignored(&info->mdas) &&
Critical section New strategy for memory locking to decrease the number of call to to un/lock memory when processing critical lvm functions. Introducing functions for critical section. Inside the critical section - memory is always locked. When leaving the critical section, the memory stays locked until memlock_unlock() is called - this happens with sync_local_dev_names() and sync_dev_names() function call. memlock_reset() is needed to reset locking numbers after fork (polldaemon). The patch itself is mostly rename: memlock_inc -> critical_section_inc memlock_dec -> critical_section_dec memlock -> critical_section Daemons (clmvd, dmevent) are using memlock_daemon_inc&dec (mlockall()) thus they will never release or relock memory they've already locked memory. Macros sync_local_dev_names() and sync_dev_names() are functions. It's better for debugging - and also we do not need to add memlock.h to locking.h header (for memlock_unlock() prototyp).
2011-02-18 17:16:11 +03:00
!is_orphan_vg(info->vginfo->vgname) && critical_section())
Fix tracking of validity of PVs with no mdas in lvmcache.
2008-06-11 15:02:05 +04:00
return 1;
scan: skip device rescan in vg_read For reporting commands (pvs,vgs,lvs,pvdisplay,vgdisplay,lvdisplay) we do not need to repeat the label scan of devices in vg_read if they all had matching metadata in the initial label scan. The data read by label scan can just be reused for the vg_read. This cuts the amount of device i/o in half, from two reads of each device to one. We have to be careful to avoid repairing the VG if we've skipped rescanning. (The VG repair code is very poor, and will be redone soon.)
2018-04-19 00:29:42 +03:00
/*
* Creates a new vginfo struct for this vgname/vgid if none exists,
* and attaches the info struct for the dev to the vginfo.
* Puts the vginfo into the vgname hash table.
*/
if (!_lvmcache_update_vgname(info, vgname, vgid, vgsummary->vgstatus, vgsummary->creation_host, info->fmt)) {
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)) {
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;
if (!(vginfo = info->vginfo))
return 1;
if (!vginfo->seqno) {
vginfo->seqno = vgsummary->seqno;
log_debug_cache("lvmcache %s: VG %s: set seqno to %d",
dev_name(info->dev), vginfo->vgname, vginfo->seqno);
} else if (vgsummary->seqno != vginfo->seqno) {
log_warn("Scan of VG %s from %s found metadata seqno %d vs previous %d.",
vgname, dev_name(info->dev), vgsummary->seqno, vginfo->seqno);
vginfo->scan_summary_mismatch = 1;
/* If we don't return success, this dev info will be removed from lvmcache,
and then we won't be able to rescan it or repair it. */
return 1;
}
if (!vginfo->mda_size) {
vginfo->mda_checksum = vgsummary->mda_checksum;
vginfo->mda_size = vgsummary->mda_size;
log_debug_cache("lvmcache %s: VG %s: set mda_checksum to %x mda_size to %zu",
dev_name(info->dev), vginfo->vgname,
vginfo->mda_checksum, vginfo->mda_size);
} else if ((vginfo->mda_size != vgsummary->mda_size) || (vginfo->mda_checksum != vgsummary->mda_checksum)) {
log_warn("Scan of VG %s from %s found mda_checksum %x mda_size %zu vs previous %x %zu",
vgname, dev_name(info->dev), vgsummary->mda_checksum, vgsummary->mda_size,
vginfo->mda_checksum, vginfo->mda_size);
vginfo->scan_summary_mismatch = 1;
/* If we don't return success, this dev info will be removed from lvmcache,
and then we won't be able to rescan it or repair it. */
return 1;
}
/*
* If a dev has an unmatching checksum, ignore the other
* info from it, keeping the info we already saved.
*/
if (!_lvmcache_update_vgstatus(info, vgsummary->vgstatus, vgsummary->creation_host,
vgsummary->lock_type, vgsummary->system_id)) {
log_error("Failed to update VG %s info in lvmcache.", vgname);
return 0;
}
Use lvmcache_update_vgname_and_id throughout.
2006-04-11 20:00:26 +04:00
return 1;
}
preparation for vg cache
2008-03-17 19:51:31 +03:00
int lvmcache_update_vg(struct volume_group *vg, unsigned precommitted)
A new cache.
2002-11-18 16:53:58 +03:00
{
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
struct pv_list *pvl;
Another sync point - numerous fixes & clean ups.
2003-07-05 02:34:56 +04:00
struct lvmcache_info *info;
Use __attribute__ consistently throughout.
2010-07-09 19:34:40 +04:00
char pvid_s[ID_LEN + 1] __attribute__((aligned(8)));
cache: Store metadata size and checksum. Refactor the recent metadata-reading optimisation patches. Remove the recently-added cache fields from struct labeller and struct format_instance. Instead, introduce struct lvmcache_vgsummary to wrap the VG information that lvmcache holds and add the metadata size and checksum to it. Allow this VG summary information to be looked up by metadata size + checksum. Adjust the debug log messages to make it clear when this shortcut has been successful. (This changes the optimisation slightly, and might be extendable further.) Add struct cached_vg_fmtdata to format-specific vg_read calls to preserve state alongside the VG across separate calls and indicate if the details supplied match, avoiding the need to read and process the VG metadata again.
2015-03-19 02:43:02 +03:00
struct lvmcache_vgsummary vgsummary = {
.vgname = vg->name,
.vgstatus = vg->status,
lvmcache: add lock_type to VG summary and info structs vgsummary information contains provisional VG information that is obtained without holding the VG lock. This info can be used to lock the VG, and then read it with vg_read(). After the VG is read properly, the vgsummary info should be verified. Add the VG lock_type to the vgsummary. It needs to be known before the VG can be locked and read.
2015-07-24 23:20:37 +03:00
.vgid = vg->id,
lvmcache: include system_id in vginfo cache Save system_id just like creation_host and lock_type strings in vginfo cache.
2015-11-30 20:32:17 +03:00
.system_id = vg->system_id,
lvmcache: add lock_type to VG summary and info structs vgsummary information contains provisional VG information that is obtained without holding the VG lock. This info can be used to lock the VG, and then read it with vg_read(). After the VG is read properly, the vgsummary info should be verified. Add the VG lock_type to the vgsummary. It needs to be known before the VG can be locked and read.
2015-07-24 23:20:37 +03:00
.lock_type = vg->lock_type
cache: Store metadata size and checksum. Refactor the recent metadata-reading optimisation patches. Remove the recently-added cache fields from struct labeller and struct format_instance. Instead, introduce struct lvmcache_vgsummary to wrap the VG information that lvmcache holds and add the metadata size and checksum to it. Allow this VG summary information to be looked up by metadata size + checksum. Adjust the debug log messages to make it clear when this shortcut has been successful. (This changes the optimisation slightly, and might be extendable further.) Add struct cached_vg_fmtdata to format-specific vg_read calls to preserve state alongside the VG across separate calls and indicate if the details supplied match, avoiding the need to read and process the VG metadata again.
2015-03-19 02:43:02 +03:00
};
A new cache.
2002-11-18 16:53:58 +03:00
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
dm_list_iterate_items(pvl, &vg->pvs) {
cleanup: more usage of dm_strncpy Use existing wrapper function arournd strncpy + buf[] = 0;
2018-03-02 18:25:37 +03:00
(void) dm_strncpy(pvid_s, (char *) &pvl->pv->id, sizeof(pvid_s));
Basic support for mirrors.
2005-06-01 20:51:55 +04:00
/* FIXME Could pvl->pv->dev->pvid ever be different? */
lvmcache: add optional dev arg to lvmcache_info_from_pvid A number of places are working on a specific dev when they call lvmcache_info_from_pvid() to look up an info struct based on a pvid. In those cases, pass the dev being used to lvmcache_info_from_pvid(). When a dev is specified, lvmcache_info_from_pvid() will verify that the cached info it's using matches the dev being processed before returning the info. Calling code will not mistakenly get info for the wrong dev when duplicate devs exist. This confusion was happening when scanning labels when duplicate devs existed. label_read for the first dev would add an info struct to lvmcache for that dev/pvid. label_read for the second dev would see the pvid in lvmcache from first dev, and mistakenly conclude that the label_read from the second dev can be skipped because it's already been done. By verifying that the dev for the cached pvid matches the dev being read, this mismatch is avoided and the label is actually read from the second duplicate.
2016-06-06 22:04:17 +03:00
if ((info = lvmcache_info_from_pvid(pvid_s, pvl->pv->dev, 0)) &&
cache: Store metadata size and checksum. Refactor the recent metadata-reading optimisation patches. Remove the recently-added cache fields from struct labeller and struct format_instance. Instead, introduce struct lvmcache_vgsummary to wrap the VG information that lvmcache holds and add the metadata size and checksum to it. Allow this VG summary information to be looked up by metadata size + checksum. Adjust the debug log messages to make it clear when this shortcut has been successful. (This changes the optimisation slightly, and might be extendable further.) Add struct cached_vg_fmtdata to format-specific vg_read calls to preserve state alongside the VG across separate calls and indicate if the details supplied match, avoiding the need to read and process the VG metadata again.
2015-03-19 02:43:02 +03:00
!lvmcache_update_vgname_and_id(info, &vgsummary))
Use lvmcache_update_vgname_and_id throughout.
2006-04-11 20:00:26 +04:00
return_0;
A new cache.
2002-11-18 16:53:58 +03:00
}
return 1;
}
devices: improve handling of duplicate PVs Example: /dev/loop0 and /dev/loop1 are duplicates, created by copying one backing file to the other. 'identity /dev/loopX' creates an identity mapping for loopX named idmloopX, which adds a duplicate for the named device. The duplicate selection code for lvmetad is incomplete, and lvmetad is disabled for this example. [~]# losetup -f loopfile0 [~]# pvs PV VG Fmt Attr PSize PFree /dev/loop0 foo lvm2 a-- 308.00m 296.00m [~]# losetup -f loopfile1 [~]# pvs Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/loop1 not /dev/loop0 Using duplicate PV /dev/loop1 which is more recent, replacing /dev/loop0 PV VG Fmt Attr PSize PFree /dev/loop1 foo lvm2 a-- 308.00m 308.00m [~]# ./identity /dev/loop0 [~]# pvs Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/loop1 not /dev/loop0 Using duplicate PV /dev/loop1 without holders, replacing /dev/loop0 Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/mapper/idmloop0 not /dev/loop1 Using duplicate PV /dev/mapper/idmloop0 from subsystem DM, replacing /dev/loop1 PV VG Fmt Attr PSize PFree /dev/mapper/idmloop0 foo lvm2 a-- 308.00m 296.00m [~]# ./identity /dev/loop1 [~]# pvs WARNING: duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV is being used from both devices /dev/loop0 and /dev/loop1 Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/loop1 not /dev/loop0 Using duplicate PV /dev/loop1 which is more recent, replacing /dev/loop0 Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/mapper/idmloop0 not /dev/loop1 Using duplicate PV /dev/mapper/idmloop0 from subsystem DM, replacing /dev/loop1 Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/mapper/idmloop1 not /dev/mapper/idmloop0 Using duplicate PV /dev/mapper/idmloop1 which is more recent, replacing /dev/mapper/idmloop0 PV VG Fmt Attr PSize PFree /dev/mapper/idmloop1 foo lvm2 a-- 308.00m 308.00m
2015-04-24 22:58:58 +03:00
/*
* We can see multiple different devices with the
* same pvid, i.e. duplicates.
*
* There may be different reasons for seeing two
* devices with the same pvid:
* - multipath showing two paths to the same thing
* - one device copied to another, e.g. with dd,
* also referred to as cloned devices.
* - a "subsystem" taking a device and creating
* another device of its own that represents the
* underlying device it is using, e.g. using dm
* to create an identity mapping of a PV.
*
* Given duplicate devices, we have to choose one
* of them to be the "preferred" dev, i.e. the one
* that will be referenced in lvmcache, by pv->dev.
* We can keep the existing dev, that's currently
* used in lvmcache, or we can replace the existing
* dev with the new duplicate.
*
* Regardless of which device is preferred, we need
* to print messages explaining which devices were
* found so that a user can sort out for themselves
* what has happened if the preferred device is not
* the one they are interested in.
*
* If a user wants to use the non-preferred device,
* they will need to filter out the device that
* lvm is preferring.
*
* The dev_subsystem calls check if the major number
* of the dev is part of a subsystem like DM/MD/DRBD.
* A dev that's part of a subsystem is preferred over a
* duplicate of that dev that is not part of a
* subsystem.
*
* FIXME: there may be other reasons to prefer one
* device over another:
*
* . are there other use/open counts we could check
* beyond the holders?
*
* . check if either is bad/usable and prefer
* the good one?
*
* . prefer the one with smaller minor number?
* Might avoid disturbing things due to a new
* transient duplicate?
*/
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
static struct lvmcache_info * _create_info(struct labeller *labeller, struct device *dev)
A new cache.
2002-11-18 16:53:58 +03:00
{
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
struct lvmcache_info *info;
A new cache.
2002-11-18 16:53:58 +03:00
struct label *label;
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
if (!(label = label_create(labeller)))
return_NULL;
if (!(info = dm_zalloc(sizeof(*info)))) {
log_error("lvmcache_info allocation failed");
label_destroy(label);
A new cache.
2002-11-18 16:53:58 +03:00
return NULL;
}
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
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;
}
struct lvmcache_info *lvmcache_add(struct labeller *labeller,
const char *pvid, struct device *dev,
const char *vgname, const char *vgid, uint32_t vgstatus)
{
char pvid_s[ID_LEN + 1] __attribute__((aligned(8)));
char uuid[64] __attribute__((aligned(8)));
struct lvmcache_vgsummary vgsummary = { 0 };
struct lvmcache_info *info;
struct lvmcache_info *info_lookup;
struct device_list *devl;
int created = 0;
cleanup: more usage of dm_strncpy Use existing wrapper function arournd strncpy + buf[] = 0;
2018-03-02 18:25:37 +03:00
(void) dm_strncpy(pvid_s, pvid, sizeof(pvid_s));
coverity: missing check for id_write_format return value
2016-05-31 10:56:10 +03:00
if (!id_write_format((const struct id *)&pvid_s, uuid, sizeof(uuid)))
stack;
A new cache.
2002-11-18 16:53:58 +03:00
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
/*
* Find existing info struct in _pvid_hash or create a new one.
lvmcache: add optional dev arg to lvmcache_info_from_pvid A number of places are working on a specific dev when they call lvmcache_info_from_pvid() to look up an info struct based on a pvid. In those cases, pass the dev being used to lvmcache_info_from_pvid(). When a dev is specified, lvmcache_info_from_pvid() will verify that the cached info it's using matches the dev being processed before returning the info. Calling code will not mistakenly get info for the wrong dev when duplicate devs exist. This confusion was happening when scanning labels when duplicate devs existed. label_read for the first dev would add an info struct to lvmcache for that dev/pvid. label_read for the second dev would see the pvid in lvmcache from first dev, and mistakenly conclude that the label_read from the second dev can be skipped because it's already been done. By verifying that the dev for the cached pvid matches the dev being read, this mismatch is avoided and the label is actually read from the second duplicate.
2016-06-06 22:04:17 +03:00
*
* Don't pass the known "dev" as an arg here. The mismatching
* devs for the duplicate case is checked below.
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
*/
A new cache.
2002-11-18 16:53:58 +03:00
lvmcache: add optional dev arg to lvmcache_info_from_pvid A number of places are working on a specific dev when they call lvmcache_info_from_pvid() to look up an info struct based on a pvid. In those cases, pass the dev being used to lvmcache_info_from_pvid(). When a dev is specified, lvmcache_info_from_pvid() will verify that the cached info it's using matches the dev being processed before returning the info. Calling code will not mistakenly get info for the wrong dev when duplicate devs exist. This confusion was happening when scanning labels when duplicate devs existed. label_read for the first dev would add an info struct to lvmcache for that dev/pvid. label_read for the second dev would see the pvid in lvmcache from first dev, and mistakenly conclude that the label_read from the second dev can be skipped because it's already been done. By verifying that the dev for the cached pvid matches the dev being read, this mismatch is avoided and the label is actually read from the second duplicate.
2016-06-06 22:04:17 +03:00
info = lvmcache_info_from_pvid(pvid_s, NULL, 0);
The lvmetad client-side integration. Only active when use_lvmetad = 1 is set in lvm.conf *and* lvmetad is running.
2012-02-23 17:11:07 +04:00
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
if (!info)
lvmcache: add optional dev arg to lvmcache_info_from_pvid A number of places are working on a specific dev when they call lvmcache_info_from_pvid() to look up an info struct based on a pvid. In those cases, pass the dev being used to lvmcache_info_from_pvid(). When a dev is specified, lvmcache_info_from_pvid() will verify that the cached info it's using matches the dev being processed before returning the info. Calling code will not mistakenly get info for the wrong dev when duplicate devs exist. This confusion was happening when scanning labels when duplicate devs existed. label_read for the first dev would add an info struct to lvmcache for that dev/pvid. label_read for the second dev would see the pvid in lvmcache from first dev, and mistakenly conclude that the label_read from the second dev can be skipped because it's already been done. By verifying that the dev for the cached pvid matches the dev being read, this mismatch is avoided and the label is actually read from the second duplicate.
2016-06-06 22:04:17 +03:00
info = lvmcache_info_from_pvid(dev->pvid, NULL, 0);
devices: improve handling of duplicate PVs Example: /dev/loop0 and /dev/loop1 are duplicates, created by copying one backing file to the other. 'identity /dev/loopX' creates an identity mapping for loopX named idmloopX, which adds a duplicate for the named device. The duplicate selection code for lvmetad is incomplete, and lvmetad is disabled for this example. [~]# losetup -f loopfile0 [~]# pvs PV VG Fmt Attr PSize PFree /dev/loop0 foo lvm2 a-- 308.00m 296.00m [~]# losetup -f loopfile1 [~]# pvs Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/loop1 not /dev/loop0 Using duplicate PV /dev/loop1 which is more recent, replacing /dev/loop0 PV VG Fmt Attr PSize PFree /dev/loop1 foo lvm2 a-- 308.00m 308.00m [~]# ./identity /dev/loop0 [~]# pvs Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/loop1 not /dev/loop0 Using duplicate PV /dev/loop1 without holders, replacing /dev/loop0 Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/mapper/idmloop0 not /dev/loop1 Using duplicate PV /dev/mapper/idmloop0 from subsystem DM, replacing /dev/loop1 PV VG Fmt Attr PSize PFree /dev/mapper/idmloop0 foo lvm2 a-- 308.00m 296.00m [~]# ./identity /dev/loop1 [~]# pvs WARNING: duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV is being used from both devices /dev/loop0 and /dev/loop1 Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/loop1 not /dev/loop0 Using duplicate PV /dev/loop1 which is more recent, replacing /dev/loop0 Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/mapper/idmloop0 not /dev/loop1 Using duplicate PV /dev/mapper/idmloop0 from subsystem DM, replacing /dev/loop1 Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/mapper/idmloop1 not /dev/mapper/idmloop0 Using duplicate PV /dev/mapper/idmloop1 which is more recent, replacing /dev/mapper/idmloop0 PV VG Fmt Attr PSize PFree /dev/mapper/idmloop1 foo lvm2 a-- 308.00m 308.00m
2015-04-24 22:58:58 +03:00
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
if (!info) {
info = _create_info(labeller, dev);
created = 1;
}
devices: improve handling of duplicate PVs Example: /dev/loop0 and /dev/loop1 are duplicates, created by copying one backing file to the other. 'identity /dev/loopX' creates an identity mapping for loopX named idmloopX, which adds a duplicate for the named device. The duplicate selection code for lvmetad is incomplete, and lvmetad is disabled for this example. [~]# losetup -f loopfile0 [~]# pvs PV VG Fmt Attr PSize PFree /dev/loop0 foo lvm2 a-- 308.00m 296.00m [~]# losetup -f loopfile1 [~]# pvs Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/loop1 not /dev/loop0 Using duplicate PV /dev/loop1 which is more recent, replacing /dev/loop0 PV VG Fmt Attr PSize PFree /dev/loop1 foo lvm2 a-- 308.00m 308.00m [~]# ./identity /dev/loop0 [~]# pvs Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/loop1 not /dev/loop0 Using duplicate PV /dev/loop1 without holders, replacing /dev/loop0 Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/mapper/idmloop0 not /dev/loop1 Using duplicate PV /dev/mapper/idmloop0 from subsystem DM, replacing /dev/loop1 PV VG Fmt Attr PSize PFree /dev/mapper/idmloop0 foo lvm2 a-- 308.00m 296.00m [~]# ./identity /dev/loop1 [~]# pvs WARNING: duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV is being used from both devices /dev/loop0 and /dev/loop1 Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/loop1 not /dev/loop0 Using duplicate PV /dev/loop1 which is more recent, replacing /dev/loop0 Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/mapper/idmloop0 not /dev/loop1 Using duplicate PV /dev/mapper/idmloop0 from subsystem DM, replacing /dev/loop1 Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/mapper/idmloop1 not /dev/mapper/idmloop0 Using duplicate PV /dev/mapper/idmloop1 which is more recent, replacing /dev/mapper/idmloop0 PV VG Fmt Attr PSize PFree /dev/mapper/idmloop1 foo lvm2 a-- 308.00m 308.00m
2015-04-24 22:58:58 +03:00
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
if (!info)
return_NULL;
/*
* If an existing info struct was found, check if any values are new.
*/
if (!created) {
if (info->dev != dev) {
log_warn("WARNING: PV %s on %s was already found on %s.",
uuid, dev_name(dev), dev_name(info->dev));
lvmetad: set disabled flag in lvmetad if duplicate PVs are found When devices are being scanned, if duplicate PVs are seen, tell lvmetad to set its disabled flag because of duplicate PVs.
2016-01-29 21:25:20 +03:00
if (!_found_duplicate_pvs && lvmetad_used()) {
log_warn("WARNING: Disabling lvmetad cache which does not support duplicate PVs.");
cleanup: warns from older gcc
2016-06-27 12:13:43 +03:00
lvmetad_set_disabled(labeller->fmt->cmd, LVMETAD_DISABLE_REASON_DUPLICATES);
lvmetad: set disabled flag in lvmetad if duplicate PVs are found When devices are being scanned, if duplicate PVs are seen, tell lvmetad to set its disabled flag because of duplicate PVs.
2016-01-29 21:25:20 +03:00
}
devices: improve handling of duplicate PVs Example: /dev/loop0 and /dev/loop1 are duplicates, created by copying one backing file to the other. 'identity /dev/loopX' creates an identity mapping for loopX named idmloopX, which adds a duplicate for the named device. The duplicate selection code for lvmetad is incomplete, and lvmetad is disabled for this example. [~]# losetup -f loopfile0 [~]# pvs PV VG Fmt Attr PSize PFree /dev/loop0 foo lvm2 a-- 308.00m 296.00m [~]# losetup -f loopfile1 [~]# pvs Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/loop1 not /dev/loop0 Using duplicate PV /dev/loop1 which is more recent, replacing /dev/loop0 PV VG Fmt Attr PSize PFree /dev/loop1 foo lvm2 a-- 308.00m 308.00m [~]# ./identity /dev/loop0 [~]# pvs Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/loop1 not /dev/loop0 Using duplicate PV /dev/loop1 without holders, replacing /dev/loop0 Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/mapper/idmloop0 not /dev/loop1 Using duplicate PV /dev/mapper/idmloop0 from subsystem DM, replacing /dev/loop1 PV VG Fmt Attr PSize PFree /dev/mapper/idmloop0 foo lvm2 a-- 308.00m 296.00m [~]# ./identity /dev/loop1 [~]# pvs WARNING: duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV is being used from both devices /dev/loop0 and /dev/loop1 Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/loop1 not /dev/loop0 Using duplicate PV /dev/loop1 which is more recent, replacing /dev/loop0 Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/mapper/idmloop0 not /dev/loop1 Using duplicate PV /dev/mapper/idmloop0 from subsystem DM, replacing /dev/loop1 Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/mapper/idmloop1 not /dev/mapper/idmloop0 Using duplicate PV /dev/mapper/idmloop1 which is more recent, replacing /dev/mapper/idmloop0 PV VG Fmt Attr PSize PFree /dev/mapper/idmloop1 foo lvm2 a-- 308.00m 308.00m
2015-04-24 22:58:58 +03:00
_found_duplicate_pvs = 1;
strncpy(dev->pvid, pvid_s, sizeof(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
* 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.
devices: improve handling of duplicate PVs Example: /dev/loop0 and /dev/loop1 are duplicates, created by copying one backing file to the other. 'identity /dev/loopX' creates an identity mapping for loopX named idmloopX, which adds a duplicate for the named device. The duplicate selection code for lvmetad is incomplete, and lvmetad is disabled for this example. [~]# losetup -f loopfile0 [~]# pvs PV VG Fmt Attr PSize PFree /dev/loop0 foo lvm2 a-- 308.00m 296.00m [~]# losetup -f loopfile1 [~]# pvs Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/loop1 not /dev/loop0 Using duplicate PV /dev/loop1 which is more recent, replacing /dev/loop0 PV VG Fmt Attr PSize PFree /dev/loop1 foo lvm2 a-- 308.00m 308.00m [~]# ./identity /dev/loop0 [~]# pvs Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/loop1 not /dev/loop0 Using duplicate PV /dev/loop1 without holders, replacing /dev/loop0 Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/mapper/idmloop0 not /dev/loop1 Using duplicate PV /dev/mapper/idmloop0 from subsystem DM, replacing /dev/loop1 PV VG Fmt Attr PSize PFree /dev/mapper/idmloop0 foo lvm2 a-- 308.00m 296.00m [~]# ./identity /dev/loop1 [~]# pvs WARNING: duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV is being used from both devices /dev/loop0 and /dev/loop1 Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/loop1 not /dev/loop0 Using duplicate PV /dev/loop1 which is more recent, replacing /dev/loop0 Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/mapper/idmloop0 not /dev/loop1 Using duplicate PV /dev/mapper/idmloop0 from subsystem DM, replacing /dev/loop1 Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/mapper/idmloop1 not /dev/mapper/idmloop0 Using duplicate PV /dev/mapper/idmloop1 which is more recent, replacing /dev/mapper/idmloop0 PV VG Fmt Attr PSize PFree /dev/mapper/idmloop1 foo lvm2 a-- 308.00m 308.00m
2015-04-24 22:58:58 +03:00
*/
lvmcache: fix duplicate handling with multiple scans Some commands scan labels to populate lvmcache multiple times, i.e. lvmcache_init, scan labels to fill lvmcache, lvmcache_destroy, then later repeat Each time labels are scanned, duplicates are detected, and preferred devices are chosen. Each time this is done within a single command, we want to choose the same preferred devices. So, check for existing preferences when choosing preferred devices. This also fixes a problem with the list of unused duplicate devs when run in an lvm shell. The devs had been allocated from cmd memory, resulting in invalid list entries between commands.
2016-06-06 23:20:55 +03:00
if (!(devl = dm_zalloc(sizeof(*devl))))
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;
devl->dev = dev;
lvmcache: choose preferred device once Once the preferred duplicate devices have been set in lvmcache, don't attempt to pick preferred duplicates again.
2015-05-06 22:49:44 +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
dm_list_add(&_found_duplicate_devs, &devl->list);
return NULL;
Detect duplicate PV uuids - select the one on an md device if appropriate.
2003-01-07 00:10:43 +03:00
}
devices: improve handling of duplicate PVs Example: /dev/loop0 and /dev/loop1 are duplicates, created by copying one backing file to the other. 'identity /dev/loopX' creates an identity mapping for loopX named idmloopX, which adds a duplicate for the named device. The duplicate selection code for lvmetad is incomplete, and lvmetad is disabled for this example. [~]# losetup -f loopfile0 [~]# pvs PV VG Fmt Attr PSize PFree /dev/loop0 foo lvm2 a-- 308.00m 296.00m [~]# losetup -f loopfile1 [~]# pvs Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/loop1 not /dev/loop0 Using duplicate PV /dev/loop1 which is more recent, replacing /dev/loop0 PV VG Fmt Attr PSize PFree /dev/loop1 foo lvm2 a-- 308.00m 308.00m [~]# ./identity /dev/loop0 [~]# pvs Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/loop1 not /dev/loop0 Using duplicate PV /dev/loop1 without holders, replacing /dev/loop0 Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/mapper/idmloop0 not /dev/loop1 Using duplicate PV /dev/mapper/idmloop0 from subsystem DM, replacing /dev/loop1 PV VG Fmt Attr PSize PFree /dev/mapper/idmloop0 foo lvm2 a-- 308.00m 296.00m [~]# ./identity /dev/loop1 [~]# pvs WARNING: duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV is being used from both devices /dev/loop0 and /dev/loop1 Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/loop1 not /dev/loop0 Using duplicate PV /dev/loop1 which is more recent, replacing /dev/loop0 Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/mapper/idmloop0 not /dev/loop1 Using duplicate PV /dev/mapper/idmloop0 from subsystem DM, replacing /dev/loop1 Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/mapper/idmloop1 not /dev/mapper/idmloop0 Using duplicate PV /dev/mapper/idmloop1 which is more recent, replacing /dev/mapper/idmloop0 PV VG Fmt Attr PSize PFree /dev/mapper/idmloop1 foo lvm2 a-- 308.00m 308.00m
2015-04-24 22:58:58 +03:00
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
if (info->dev->pvid[0] && pvid[0] && strcmp(pvid_s, info->dev->pvid)) {
/* This happens when running pvcreate on an existing PV. */
log_verbose("Changing pvid on dev %s from %s to %s",
dev_name(info->dev), info->dev->pvid, pvid_s);
devices: improve handling of duplicate PVs Example: /dev/loop0 and /dev/loop1 are duplicates, created by copying one backing file to the other. 'identity /dev/loopX' creates an identity mapping for loopX named idmloopX, which adds a duplicate for the named device. The duplicate selection code for lvmetad is incomplete, and lvmetad is disabled for this example. [~]# losetup -f loopfile0 [~]# pvs PV VG Fmt Attr PSize PFree /dev/loop0 foo lvm2 a-- 308.00m 296.00m [~]# losetup -f loopfile1 [~]# pvs Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/loop1 not /dev/loop0 Using duplicate PV /dev/loop1 which is more recent, replacing /dev/loop0 PV VG Fmt Attr PSize PFree /dev/loop1 foo lvm2 a-- 308.00m 308.00m [~]# ./identity /dev/loop0 [~]# pvs Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/loop1 not /dev/loop0 Using duplicate PV /dev/loop1 without holders, replacing /dev/loop0 Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/mapper/idmloop0 not /dev/loop1 Using duplicate PV /dev/mapper/idmloop0 from subsystem DM, replacing /dev/loop1 PV VG Fmt Attr PSize PFree /dev/mapper/idmloop0 foo lvm2 a-- 308.00m 296.00m [~]# ./identity /dev/loop1 [~]# pvs WARNING: duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV is being used from both devices /dev/loop0 and /dev/loop1 Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/loop1 not /dev/loop0 Using duplicate PV /dev/loop1 which is more recent, replacing /dev/loop0 Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/mapper/idmloop0 not /dev/loop1 Using duplicate PV /dev/mapper/idmloop0 from subsystem DM, replacing /dev/loop1 Found duplicate PV LnSOEqzEYED3RvIOa5PZP2s7uyuBLmAV: using /dev/mapper/idmloop1 not /dev/mapper/idmloop0 Using duplicate PV /dev/mapper/idmloop1 which is more recent, replacing /dev/mapper/idmloop0 PV VG Fmt Attr PSize PFree /dev/mapper/idmloop1 foo lvm2 a-- 308.00m 308.00m
2015-04-24 22:58:58 +03:00
}
A new cache.
2002-11-18 16:53:58 +03:00
if (info->label->labeller != labeller) {
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
log_verbose("Changing labeller on dev %s from %s to %s",
dev_name(info->dev),
info->label->labeller->fmt->name,
labeller->fmt->name);
A new cache.
2002-11-18 16:53:58 +03:00
label_destroy(info->label);
Use stack return macros throughout.
2008-01-30 16:19:47 +03:00
if (!(info->label = label_create(labeller)))
return_NULL;
A new cache.
2002-11-18 16:53:58 +03:00
info->label->info = info;
}
}
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
/*
* Add or update the _pvid_hash mapping, pvid to info.
*/
info_lookup = dm_hash_lookup(_pvid_hash, pvid_s);
if ((info_lookup == info) && !strcmp(info->dev->pvid, pvid_s))
goto update_vginfo;
if (info->dev->pvid[0])
dm_hash_remove(_pvid_hash, info->dev->pvid);
strncpy(info->dev->pvid, pvid_s, sizeof(info->dev->pvid));
if (!dm_hash_insert(_pvid_hash, pvid_s, info)) {
log_error("Adding pvid to hash failed %s", pvid_s);
A new cache.
2002-11-18 16:53:58 +03:00
return NULL;
}
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
update_vginfo:
vgsummary.vgstatus = vgstatus;
vgsummary.vgname = vgname;
if (vgid)
strncpy((char *)&vgsummary.vgid, vgid, sizeof(vgsummary.vgid));
cache: Store metadata size and checksum. Refactor the recent metadata-reading optimisation patches. Remove the recently-added cache fields from struct labeller and struct format_instance. Instead, introduce struct lvmcache_vgsummary to wrap the VG information that lvmcache holds and add the metadata size and checksum to it. Allow this VG summary information to be looked up by metadata size + checksum. Adjust the debug log messages to make it clear when this shortcut has been successful. (This changes the optimisation slightly, and might be extendable further.) Add struct cached_vg_fmtdata to format-specific vg_read calls to preserve state alongside the VG across separate calls and indicate if the details supplied match, avoiding the need to read and process the VG metadata again.
2015-03-19 02:43:02 +03:00
if (!lvmcache_update_vgname_and_id(info, &vgsummary)) {
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
if (created) {
Use hash, bitset, malloc, pool from libdevmapper.
2005-10-17 03:03:59 +04:00
dm_hash_remove(_pvid_hash, pvid_s);
A new cache.
2002-11-18 16:53:58 +03:00
strcpy(info->dev->pvid, "");
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_free(info->label);
Use hash, bitset, malloc, pool from libdevmapper.
2005-10-17 03:03:59 +04:00
dm_free(info);
A new cache.
2002-11-18 16:53:58 +03:00
}
return NULL;
}
return info;
}
Another sync point - numerous fixes & clean ups.
2003-07-05 02:34:56 +04:00
static void _lvmcache_destroy_entry(struct lvmcache_info *info)
A new cache.
2002-11-18 16:53:58 +03:00
{
Refactor some vginfo manipulation code.
2008-05-19 23:49:56 +04:00
_vginfo_detach_info(info);
cleanup: simplier string reset
2013-07-19 17:32:49 +04:00
info->dev->pvid[0] = 0;
A new cache.
2002-11-18 16:53:58 +03:00
label_destroy(info->label);
Use hash, bitset, malloc, pool from libdevmapper.
2005-10-17 03:03:59 +04:00
dm_free(info);
A new cache.
2002-11-18 16:53:58 +03:00
}
Another sync point - numerous fixes & clean ups.
2003-07-05 02:34:56 +04:00
static void _lvmcache_destroy_vgnamelist(struct lvmcache_vginfo *vginfo)
A new cache.
2002-11-18 16:53:58 +03:00
{
If two or more VGs are found with the same name, use one that is not exported.
2006-04-12 21:54:11 +04:00
struct lvmcache_vginfo *next;
do {
next = vginfo->next;
Refactor some vginfo manipulation code.
2008-05-19 23:49:56 +04:00
if (!_free_vginfo(vginfo))
stack;
If two or more VGs are found with the same name, use one that is not exported.
2006-04-12 21:54:11 +04:00
} while ((vginfo = next));
A new cache.
2002-11-18 16:53:58 +03:00
}
Add some basic internal VG lock validation.
2008-04-03 22:56:40 +04:00
static void _lvmcache_destroy_lockname(struct dm_hash_node *n)
Another sync point - numerous fixes & clean ups.
2003-07-05 02:34:56 +04:00
{
Add some basic internal VG lock validation.
2008-04-03 22:56:40 +04:00
char *vgname;
if (!dm_hash_get_data(_lock_hash, n))
return;
vgname = dm_hash_get_key(_lock_hash, n);
if (!strcmp(vgname, VG_GLOBAL))
_vg_global_lock_held = 1;
else
#define an INTERNAL_ERROR macro and use it throughout LVM.
2009-12-16 22:22:11 +03:00
log_error(INTERNAL_ERROR "Volume Group %s was not unlocked",
Add some basic internal VG lock validation.
2008-04-03 22:56:40 +04:00
dm_hash_get_key(_lock_hash, n));
Another sync point - numerous fixes & clean ups.
2003-07-05 02:34:56 +04:00
}
lvmcache: handle reinit without error Since commit f12ee43f2eaba5d38b1925a5a34b1746c1d66985 call destroy, it start to check all VGs are unlocked. However when we become_daemon, we simply reset locking (since lock is still kept by parent process). So implement a simple 'reset' flag.
2014-03-22 01:26:39 +04:00
void lvmcache_destroy(struct cmd_context *cmd, int retain_orphans, int reset)
A new cache.
2002-11-18 16:53:58 +03:00
{
Add some basic internal VG lock validation.
2008-04-03 22:56:40 +04:00
struct dm_hash_node *n;
scan: drop bcache between lvm shell commands A running lvm shell keeps all lvm devices open unless the bcache is dropped.
2018-04-06 21:05:17 +03:00
log_debug_cache("Dropping VG info");
Improve detection of external changes affecting internal cache.
2005-03-22 01:40:35 +03:00
A new cache.
2002-11-18 16:53:58 +03:00
_has_scanned = 0;
if (_vgid_hash) {
Use hash, bitset, malloc, pool from libdevmapper.
2005-10-17 03:03:59 +04:00
dm_hash_destroy(_vgid_hash);
A new cache.
2002-11-18 16:53:58 +03:00
_vgid_hash = NULL;
}
if (_pvid_hash) {
Use hash, bitset, malloc, pool from libdevmapper.
2005-10-17 03:03:59 +04:00
dm_hash_iter(_pvid_hash, (dm_hash_iterate_fn) _lvmcache_destroy_entry);
dm_hash_destroy(_pvid_hash);
A new cache.
2002-11-18 16:53:58 +03:00
_pvid_hash = NULL;
}
if (_vgname_hash) {
Use hash, bitset, malloc, pool from libdevmapper.
2005-10-17 03:03:59 +04:00
dm_hash_iter(_vgname_hash,
(dm_hash_iterate_fn) _lvmcache_destroy_vgnamelist);
dm_hash_destroy(_vgname_hash);
A new cache.
2002-11-18 16:53:58 +03:00
_vgname_hash = NULL;
}
Another sync point - numerous fixes & clean ups.
2003-07-05 02:34:56 +04:00
if (_lock_hash) {
lvmcache: handle reinit without error Since commit f12ee43f2eaba5d38b1925a5a34b1746c1d66985 call destroy, it start to check all VGs are unlocked. However when we become_daemon, we simply reset locking (since lock is still kept by parent process). So implement a simple 'reset' flag.
2014-03-22 01:26:39 +04:00
if (reset)
_vg_global_lock_held = 0;
else
dm_hash_iterate(n, _lock_hash)
_lvmcache_destroy_lockname(n);
Use hash, bitset, malloc, pool from libdevmapper.
2005-10-17 03:03:59 +04:00
dm_hash_destroy(_lock_hash);
Another sync point - numerous fixes & clean ups.
2003-07-05 02:34:56 +04:00
_lock_hash = NULL;
}
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
if (!dm_list_empty(&_vginfos))
#define an INTERNAL_ERROR macro and use it throughout LVM.
2009-12-16 22:22:11 +03:00
log_error(INTERNAL_ERROR "_vginfos list should be empty");
Right, a simple build (without options) is working again.
2008-11-04 01:14:30 +03:00
dm_list_init(&_vginfos);
Fix vgreduce to use vg_split_mdas to check sufficient mdas remain. Add (empty) orphan VGs to lvmcache during initialisation. Fix orphan VG name used for format_pool.
2008-04-08 16:49:21 +04:00
lvmcache: fix duplicate handling with multiple scans Some commands scan labels to populate lvmcache multiple times, i.e. lvmcache_init, scan labels to fill lvmcache, lvmcache_destroy, then later repeat Each time labels are scanned, duplicates are detected, and preferred devices are chosen. Each time this is done within a single command, we want to choose the same preferred devices. So, check for existing preferences when choosing preferred devices. This also fixes a problem with the list of unused duplicate devs when run in an lvm shell. The devs had been allocated from cmd memory, resulting in invalid list entries between commands.
2016-06-06 23:20:55 +03:00
/*
* Copy the current _unused_duplicate_devs into a cmd list before
* destroying _unused_duplicate_devs.
*
* One command can init/populate/destroy lvmcache multiple times. Each
* time it will encounter duplicates and choose the preferrred devs.
* We want the same preferred devices to be chosen each time, so save
* the unpreferred devs here so that _choose_preferred_devs can use
* this to make the same choice each time.
*/
dm_list_init(&cmd->unused_duplicate_devs);
lvmcache_get_unused_duplicate_devs(cmd, &cmd->unused_duplicate_devs);
_destroy_duplicate_device_list(&_unused_duplicate_devs);
_destroy_duplicate_device_list(&_found_duplicate_devs); /* should be empty anyway */
_found_duplicate_pvs = 0;
Fix vgreduce to use vg_split_mdas to check sufficient mdas remain. Add (empty) orphan VGs to lvmcache during initialisation. Fix orphan VG name used for format_pool.
2008-04-08 16:49:21 +04:00
if (retain_orphans)
Add stacktrace for init_lvmcache_orphans fail path
2012-02-28 15:08:04 +04:00
if (!init_lvmcache_orphans(cmd))
stack;
A new cache.
2002-11-18 16:53:58 +03:00
}
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
int lvmcache_pvid_is_locked(const char *pvid) {
struct lvmcache_info *info;
lvmcache: add optional dev arg to lvmcache_info_from_pvid A number of places are working on a specific dev when they call lvmcache_info_from_pvid() to look up an info struct based on a pvid. In those cases, pass the dev being used to lvmcache_info_from_pvid(). When a dev is specified, lvmcache_info_from_pvid() will verify that the cached info it's using matches the dev being processed before returning the info. Calling code will not mistakenly get info for the wrong dev when duplicate devs exist. This confusion was happening when scanning labels when duplicate devs existed. label_read for the first dev would add an info struct to lvmcache for that dev/pvid. label_read for the second dev would see the pvid in lvmcache from first dev, and mistakenly conclude that the label_read from the second dev can be skipped because it's already been done. By verifying that the dev for the cached pvid matches the dev being read, this mismatch is avoided and the label is actually read from the second duplicate.
2016-06-06 22:04:17 +03:00
info = lvmcache_info_from_pvid(pvid, NULL, 0);
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
if (!info || !info->vginfo)
return 0;
return lvmcache_vgname_is_locked(info->vginfo->vgname);
}
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);
}
int lvmcache_fid_add_mdas_vg(struct lvmcache_vginfo *vginfo, struct format_instance *fid)
{
struct lvmcache_info *info;
dm_list_iterate_items(info, &vginfo->infos) {
if (!lvmcache_fid_add_mdas_pv(info, fid))
return_0;
}
return 1;
}
int lvmcache_populate_pv_fields(struct lvmcache_info *info,
label_scan: remove extra label scan and read for orphan PVs When process_each_pv() calls vg_read() on the orphan VG, the internal implementation was doing an unnecessary lvmcache_label_scan() and two unnecessary label_read() calls on each orphan. Some of those unnecessary label scans/reads would sometimes be skipped due to caching, but the code was always doing at least one unnecessary read on each orphan. The common format_text case was also unecessarily calling into the format-specific pv_read() function which actually did nothing. By analyzing each case in which vg_read() was being called on the orphan VG, we can say that all of the label scans/reads in vg_read_orphans are unnecessary: 1. reporting commands: the information saved in lvmcache by the original label scan can be reported. There is no advantage to repeating the label scan on the orphans a second time before reporting it. 2. pvcreate/vgcreate/vgextend: these all share a common implementation in pvcreate_each_device(). That function already rescans labels after acquiring the orphan VG lock, which ensures that the command is using valid lvmcache information.
2017-11-06 21:09:52 +03:00
struct volume_group *vg,
struct physical_volume *pv)
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
{
struct data_area_list *da;
label_scan: remove extra label scan and read for orphan PVs When process_each_pv() calls vg_read() on the orphan VG, the internal implementation was doing an unnecessary lvmcache_label_scan() and two unnecessary label_read() calls on each orphan. Some of those unnecessary label scans/reads would sometimes be skipped due to caching, but the code was always doing at least one unnecessary read on each orphan. The common format_text case was also unecessarily calling into the format-specific pv_read() function which actually did nothing. By analyzing each case in which vg_read() was being called on the orphan VG, we can say that all of the label scans/reads in vg_read_orphans are unnecessary: 1. reporting commands: the information saved in lvmcache by the original label scan can be reported. There is no advantage to repeating the label scan on the orphans a second time before reporting it. 2. pvcreate/vgcreate/vgextend: these all share a common implementation in pvcreate_each_device(). That function already rescans labels after acquiring the orphan VG lock, which ensures that the command is using valid lvmcache information.
2017-11-06 21:09:52 +03:00
if (!info->label) {
log_error("No cached label for orphan PV %s", pv_dev_name(pv));
return 0;
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
}
label_scan: remove extra label scan and read for orphan PVs When process_each_pv() calls vg_read() on the orphan VG, the internal implementation was doing an unnecessary lvmcache_label_scan() and two unnecessary label_read() calls on each orphan. Some of those unnecessary label scans/reads would sometimes be skipped due to caching, but the code was always doing at least one unnecessary read on each orphan. The common format_text case was also unecessarily calling into the format-specific pv_read() function which actually did nothing. By analyzing each case in which vg_read() was being called on the orphan VG, we can say that all of the label scans/reads in vg_read_orphans are unnecessary: 1. reporting commands: the information saved in lvmcache by the original label scan can be reported. There is no advantage to repeating the label scan on the orphans a second time before reporting it. 2. pvcreate/vgcreate/vgextend: these all share a common implementation in pvcreate_each_device(). That function already rescans labels after acquiring the orphan VG lock, which ensures that the command is using valid lvmcache information.
2017-11-06 21:09:52 +03:00
pv->label_sector = info->label->sector;
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
pv->dev = info->dev;
pv->fmt = info->fmt;
pv->size = info->device_size >> SECTOR_SHIFT;
pv->vg_name = FMT_TEXT_ORPHAN_VG_NAME;
memcpy(&pv->id, &info->dev->pvid, sizeof(pv->id));
label_scan: remove extra label scan and read for orphan PVs When process_each_pv() calls vg_read() on the orphan VG, the internal implementation was doing an unnecessary lvmcache_label_scan() and two unnecessary label_read() calls on each orphan. Some of those unnecessary label scans/reads would sometimes be skipped due to caching, but the code was always doing at least one unnecessary read on each orphan. The common format_text case was also unecessarily calling into the format-specific pv_read() function which actually did nothing. By analyzing each case in which vg_read() was being called on the orphan VG, we can say that all of the label scans/reads in vg_read_orphans are unnecessary: 1. reporting commands: the information saved in lvmcache by the original label scan can be reported. There is no advantage to repeating the label scan on the orphans a second time before reporting it. 2. pvcreate/vgcreate/vgextend: these all share a common implementation in pvcreate_each_device(). That function already rescans labels after acquiring the orphan VG lock, which ensures that the command is using valid lvmcache information.
2017-11-06 21:09:52 +03:00
if (!pv->size) {
log_error("PV %s size is zero.", dev_name(info->dev));
return 0;
}
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
/* Currently only support exactly one data area */
if (dm_list_size(&info->das) != 1) {
log_error("Must be exactly one data area (found %d) on PV %s",
dm_list_size(&info->das), dev_name(info->dev));
return 0;
}
refactor: rename embedding area -> bootloader area
2013-05-28 14:37:22 +04:00
/* Currently only support one bootloader area at most */
if (dm_list_size(&info->bas) > 1) {
log_error("Must be at most one bootloader area (found %d) on PV %s",
dm_list_size(&info->bas), dev_name(info->dev));
pv_header_extension: add support for reading PV header extension (flags & Embedding Area) New tools with PV header extension support will read the extension if it exists and it's not an error if it does not exist (so old PVs will still work seamlessly with new tools). Old tools without PV header extension support will just ignore any extension. As for the Embedding Area location information (its start and size), there are actually two places where this is stored: - PV header extension - VG metadata The VG metadata contains a copy of what's written in the PV header extension about the Embedding Area location (NULL value is not copied): physical_volumes { pv0 { id = "AkSSRf-difg-fCCZ-NjAN-qP49-1zzg-S0Fd4T" device = "/dev/sda" # Hint only status = ["ALLOCATABLE"] flags = [] dev_size = 262144 # 128 Megabytes pe_start = 67584 pe_count = 23 # 92 Megabytes ea_start = 2048 ea_size = 65536 # 32 Megabytes } } The new metadata fields are "ea_start" and "ea_size". This is mostly useful when restoring the PV by using existing metadata backups (e.g. pvcreate --restorefile ...). New tools does not require these two fields to exist in VG metadata, they're not compulsory. Therefore, reading old VG metadata which doesn't contain any Embedding Area information will not end up with any kind of error but only a debug message that the ea_start and ea_size values were not found. Old tools just ignore these extra fields in VG metadata.
2013-02-14 19:04:35 +04:00
return 0;
}
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
dm_list_iterate_items(da, &info->das)
pv->pe_start = da->disk_locn.offset >> SECTOR_SHIFT;
refactor: rename embedding area -> bootloader area
2013-05-28 14:37:22 +04:00
dm_list_iterate_items(da, &info->bas) {
pv->ba_start = da->disk_locn.offset >> SECTOR_SHIFT;
pv->ba_size = da->disk_locn.size >> SECTOR_SHIFT;
pv_header_extension: add support for reading PV header extension (flags & Embedding Area) New tools with PV header extension support will read the extension if it exists and it's not an error if it does not exist (so old PVs will still work seamlessly with new tools). Old tools without PV header extension support will just ignore any extension. As for the Embedding Area location information (its start and size), there are actually two places where this is stored: - PV header extension - VG metadata The VG metadata contains a copy of what's written in the PV header extension about the Embedding Area location (NULL value is not copied): physical_volumes { pv0 { id = "AkSSRf-difg-fCCZ-NjAN-qP49-1zzg-S0Fd4T" device = "/dev/sda" # Hint only status = ["ALLOCATABLE"] flags = [] dev_size = 262144 # 128 Megabytes pe_start = 67584 pe_count = 23 # 92 Megabytes ea_start = 2048 ea_size = 65536 # 32 Megabytes } } The new metadata fields are "ea_start" and "ea_size". This is mostly useful when restoring the PV by using existing metadata backups (e.g. pvcreate --restorefile ...). New tools does not require these two fields to exist in VG metadata, they're not compulsory. Therefore, reading old VG metadata which doesn't contain any Embedding Area information will not end up with any kind of error but only a debug message that the ea_start and ea_size values were not found. Old tools just ignore these extra fields in VG metadata.
2013-02-14 19:04:35 +04:00
}
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
return 1;
}
int lvmcache_check_format(struct lvmcache_info *info, const struct format_type *fmt)
{
if (info->fmt != fmt) {
log_error("PV %s is a different format (seqno %s)",
dev_name(info->dev), info->fmt->name);
return 0;
}
return 1;
}
void lvmcache_del_mdas(struct lvmcache_info *info)
{
if (info->mdas.n)
del_mdas(&info->mdas);
dm_list_init(&info->mdas);
}
void lvmcache_del_das(struct lvmcache_info *info)
{
if (info->das.n)
del_das(&info->das);
dm_list_init(&info->das);
}
refactor: rename embedding area -> bootloader area
2013-05-28 14:37:22 +04:00
void lvmcache_del_bas(struct lvmcache_info *info)
pv_header_extension: add supporting infrastructure for PV header extension (flags & Embedding Area) PV header extension comes just beyond the existing PV header base: PV header base (existing): - uuid - device size - null-terminated list of Data Areas - null-terminater list of MetaData Areas PV header extension: - extension version - flags - null-terminated list of Embedding Areas This patch also adds "eas" (Embedding Areas) list to lvmcache (lvmcache_info) and it also adds support for common operations on the list (just like for already existing "das" - Data Areas list): - lvmcache_add_ea - lvmcache_update_eas - lvmcache_foreach_ea - lvmcache_del_eas Also, add ea_start and ea_size to struct physical_volume for processing PV Embedding Area location throughout the code (currently only one Embedding Area is supported, though the definition on disk allows for more if needed in the future...). Also, define FMT_EAS format flag to mark that the format actually supports Embedding Areas (currently format-text only).
2013-02-14 18:35:57 +04:00
{
refactor: rename embedding area -> bootloader area
2013-05-28 14:37:22 +04:00
if (info->bas.n)
del_bas(&info->bas);
dm_list_init(&info->bas);
pv_header_extension: add supporting infrastructure for PV header extension (flags & Embedding Area) PV header extension comes just beyond the existing PV header base: PV header base (existing): - uuid - device size - null-terminated list of Data Areas - null-terminater list of MetaData Areas PV header extension: - extension version - flags - null-terminated list of Embedding Areas This patch also adds "eas" (Embedding Areas) list to lvmcache (lvmcache_info) and it also adds support for common operations on the list (just like for already existing "das" - Data Areas list): - lvmcache_add_ea - lvmcache_update_eas - lvmcache_foreach_ea - lvmcache_del_eas Also, add ea_start and ea_size to struct physical_volume for processing PV Embedding Area location throughout the code (currently only one Embedding Area is supported, though the definition on disk allows for more if needed in the future...). Also, define FMT_EAS format flag to mark that the format actually supports Embedding Areas (currently format-text only).
2013-02-14 18:35:57 +04:00
}
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
int lvmcache_add_mda(struct lvmcache_info *info, struct device *dev,
uint64_t start, uint64_t size, unsigned ignored)
{
return add_mda(info->fmt, NULL, &info->mdas, dev, start, size, ignored);
}
int lvmcache_add_da(struct lvmcache_info *info, uint64_t start, uint64_t size)
{
return add_da(NULL, &info->das, start, size);
}
refactor: rename embedding area -> bootloader area
2013-05-28 14:37:22 +04:00
int lvmcache_add_ba(struct lvmcache_info *info, uint64_t start, uint64_t size)
pv_header_extension: add supporting infrastructure for PV header extension (flags & Embedding Area) PV header extension comes just beyond the existing PV header base: PV header base (existing): - uuid - device size - null-terminated list of Data Areas - null-terminater list of MetaData Areas PV header extension: - extension version - flags - null-terminated list of Embedding Areas This patch also adds "eas" (Embedding Areas) list to lvmcache (lvmcache_info) and it also adds support for common operations on the list (just like for already existing "das" - Data Areas list): - lvmcache_add_ea - lvmcache_update_eas - lvmcache_foreach_ea - lvmcache_del_eas Also, add ea_start and ea_size to struct physical_volume for processing PV Embedding Area location throughout the code (currently only one Embedding Area is supported, though the definition on disk allows for more if needed in the future...). Also, define FMT_EAS format flag to mark that the format actually supports Embedding Areas (currently format-text only).
2013-02-14 18:35:57 +04:00
{
refactor: rename embedding area -> bootloader area
2013-05-28 14:37:22 +04:00
return add_ba(NULL, &info->bas, start, size);
pv_header_extension: add supporting infrastructure for PV header extension (flags & Embedding Area) PV header extension comes just beyond the existing PV header base: PV header base (existing): - uuid - device size - null-terminated list of Data Areas - null-terminater list of MetaData Areas PV header extension: - extension version - flags - null-terminated list of Embedding Areas This patch also adds "eas" (Embedding Areas) list to lvmcache (lvmcache_info) and it also adds support for common operations on the list (just like for already existing "das" - Data Areas list): - lvmcache_add_ea - lvmcache_update_eas - lvmcache_foreach_ea - lvmcache_del_eas Also, add ea_start and ea_size to struct physical_volume for processing PV Embedding Area location throughout the code (currently only one Embedding Area is supported, though the definition on disk allows for more if needed in the future...). Also, define FMT_EAS format flag to mark that the format actually supports Embedding Areas (currently format-text only).
2013-02-14 18:35:57 +04:00
}
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
void lvmcache_update_pv(struct lvmcache_info *info, struct physical_volume *pv,
const struct format_type *fmt)
{
info->device_size = pv->size << SECTOR_SHIFT;
info->fmt = fmt;
}
int lvmcache_update_das(struct lvmcache_info *info, struct physical_volume *pv)
{
struct data_area_list *da;
if (info->das.n) {
if (!pv->pe_start)
dm_list_iterate_items(da, &info->das)
pv->pe_start = da->disk_locn.offset >> SECTOR_SHIFT;
del_das(&info->das);
} else
dm_list_init(&info->das);
The lvmetad client-side integration. Only active when use_lvmetad = 1 is set in lvm.conf *and* lvmetad is running.
2012-02-23 17:11:07 +04:00
if (!add_da(NULL, &info->das, pv->pe_start << SECTOR_SHIFT, 0 /*pv->size << SECTOR_SHIFT*/))
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
return_0;
return 1;
}
refactor: rename embedding area -> bootloader area
2013-05-28 14:37:22 +04:00
int lvmcache_update_bas(struct lvmcache_info *info, struct physical_volume *pv)
pv_header_extension: add supporting infrastructure for PV header extension (flags & Embedding Area) PV header extension comes just beyond the existing PV header base: PV header base (existing): - uuid - device size - null-terminated list of Data Areas - null-terminater list of MetaData Areas PV header extension: - extension version - flags - null-terminated list of Embedding Areas This patch also adds "eas" (Embedding Areas) list to lvmcache (lvmcache_info) and it also adds support for common operations on the list (just like for already existing "das" - Data Areas list): - lvmcache_add_ea - lvmcache_update_eas - lvmcache_foreach_ea - lvmcache_del_eas Also, add ea_start and ea_size to struct physical_volume for processing PV Embedding Area location throughout the code (currently only one Embedding Area is supported, though the definition on disk allows for more if needed in the future...). Also, define FMT_EAS format flag to mark that the format actually supports Embedding Areas (currently format-text only).
2013-02-14 18:35:57 +04:00
{
refactor: rename embedding area -> bootloader area
2013-05-28 14:37:22 +04:00
struct data_area_list *ba;
if (info->bas.n) {
if (!pv->ba_start && !pv->ba_size)
dm_list_iterate_items(ba, &info->bas) {
pv->ba_start = ba->disk_locn.offset >> SECTOR_SHIFT;
pv->ba_size = ba->disk_locn.size >> SECTOR_SHIFT;
pv_header_extension: add supporting infrastructure for PV header extension (flags & Embedding Area) PV header extension comes just beyond the existing PV header base: PV header base (existing): - uuid - device size - null-terminated list of Data Areas - null-terminater list of MetaData Areas PV header extension: - extension version - flags - null-terminated list of Embedding Areas This patch also adds "eas" (Embedding Areas) list to lvmcache (lvmcache_info) and it also adds support for common operations on the list (just like for already existing "das" - Data Areas list): - lvmcache_add_ea - lvmcache_update_eas - lvmcache_foreach_ea - lvmcache_del_eas Also, add ea_start and ea_size to struct physical_volume for processing PV Embedding Area location throughout the code (currently only one Embedding Area is supported, though the definition on disk allows for more if needed in the future...). Also, define FMT_EAS format flag to mark that the format actually supports Embedding Areas (currently format-text only).
2013-02-14 18:35:57 +04:00
}
refactor: rename embedding area -> bootloader area
2013-05-28 14:37:22 +04:00
del_das(&info->bas);
pv_header_extension: add supporting infrastructure for PV header extension (flags & Embedding Area) PV header extension comes just beyond the existing PV header base: PV header base (existing): - uuid - device size - null-terminated list of Data Areas - null-terminater list of MetaData Areas PV header extension: - extension version - flags - null-terminated list of Embedding Areas This patch also adds "eas" (Embedding Areas) list to lvmcache (lvmcache_info) and it also adds support for common operations on the list (just like for already existing "das" - Data Areas list): - lvmcache_add_ea - lvmcache_update_eas - lvmcache_foreach_ea - lvmcache_del_eas Also, add ea_start and ea_size to struct physical_volume for processing PV Embedding Area location throughout the code (currently only one Embedding Area is supported, though the definition on disk allows for more if needed in the future...). Also, define FMT_EAS format flag to mark that the format actually supports Embedding Areas (currently format-text only).
2013-02-14 18:35:57 +04:00
} else
refactor: rename embedding area -> bootloader area
2013-05-28 14:37:22 +04:00
dm_list_init(&info->bas);
pv_header_extension: add supporting infrastructure for PV header extension (flags & Embedding Area) PV header extension comes just beyond the existing PV header base: PV header base (existing): - uuid - device size - null-terminated list of Data Areas - null-terminater list of MetaData Areas PV header extension: - extension version - flags - null-terminated list of Embedding Areas This patch also adds "eas" (Embedding Areas) list to lvmcache (lvmcache_info) and it also adds support for common operations on the list (just like for already existing "das" - Data Areas list): - lvmcache_add_ea - lvmcache_update_eas - lvmcache_foreach_ea - lvmcache_del_eas Also, add ea_start and ea_size to struct physical_volume for processing PV Embedding Area location throughout the code (currently only one Embedding Area is supported, though the definition on disk allows for more if needed in the future...). Also, define FMT_EAS format flag to mark that the format actually supports Embedding Areas (currently format-text only).
2013-02-14 18:35:57 +04:00
refactor: rename embedding area -> bootloader area
2013-05-28 14:37:22 +04:00
if (!add_ba(NULL, &info->bas, pv->ba_start << SECTOR_SHIFT, pv->ba_size << SECTOR_SHIFT))
pv_header_extension: add supporting infrastructure for PV header extension (flags & Embedding Area) PV header extension comes just beyond the existing PV header base: PV header base (existing): - uuid - device size - null-terminated list of Data Areas - null-terminater list of MetaData Areas PV header extension: - extension version - flags - null-terminated list of Embedding Areas This patch also adds "eas" (Embedding Areas) list to lvmcache (lvmcache_info) and it also adds support for common operations on the list (just like for already existing "das" - Data Areas list): - lvmcache_add_ea - lvmcache_update_eas - lvmcache_foreach_ea - lvmcache_del_eas Also, add ea_start and ea_size to struct physical_volume for processing PV Embedding Area location throughout the code (currently only one Embedding Area is supported, though the definition on disk allows for more if needed in the future...). Also, define FMT_EAS format flag to mark that the format actually supports Embedding Areas (currently format-text only).
2013-02-14 18:35:57 +04:00
return_0;
return 1;
}
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
int lvmcache_foreach_pv(struct lvmcache_vginfo *vginfo,
int (*fun)(struct lvmcache_info *, void *),
void *baton)
{
struct lvmcache_info *info;
dm_list_iterate_items(info, &vginfo->infos) {
if (!fun(info, baton))
return_0;
}
return 1;
}
int lvmcache_foreach_mda(struct lvmcache_info *info,
int (*fun)(struct metadata_area *, void *),
void *baton)
{
struct metadata_area *mda;
dm_list_iterate_items(mda, &info->mdas) {
if (!fun(mda, baton))
return_0;
}
return 1;
}
cleanup: preserve signesss and type size on return values
2013-02-05 19:43:16 +04:00
unsigned lvmcache_mda_count(struct lvmcache_info *info)
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
{
return dm_list_size(&info->mdas);
}
int lvmcache_foreach_da(struct lvmcache_info *info,
The lvmetad client-side integration. Only active when use_lvmetad = 1 is set in lvm.conf *and* lvmetad is running.
2012-02-23 17:11:07 +04:00
int (*fun)(struct disk_locn *, void *),
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
void *baton)
{
struct data_area_list *da;
dm_list_iterate_items(da, &info->das) {
The lvmetad client-side integration. Only active when use_lvmetad = 1 is set in lvm.conf *and* lvmetad is running.
2012-02-23 17:11:07 +04:00
if (!fun(&da->disk_locn, baton))
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
return_0;
}
return 1;
}
refactor: rename embedding area -> bootloader area
2013-05-28 14:37:22 +04:00
int lvmcache_foreach_ba(struct lvmcache_info *info,
pv_header_extension: add supporting infrastructure for PV header extension (flags & Embedding Area) PV header extension comes just beyond the existing PV header base: PV header base (existing): - uuid - device size - null-terminated list of Data Areas - null-terminater list of MetaData Areas PV header extension: - extension version - flags - null-terminated list of Embedding Areas This patch also adds "eas" (Embedding Areas) list to lvmcache (lvmcache_info) and it also adds support for common operations on the list (just like for already existing "das" - Data Areas list): - lvmcache_add_ea - lvmcache_update_eas - lvmcache_foreach_ea - lvmcache_del_eas Also, add ea_start and ea_size to struct physical_volume for processing PV Embedding Area location throughout the code (currently only one Embedding Area is supported, though the definition on disk allows for more if needed in the future...). Also, define FMT_EAS format flag to mark that the format actually supports Embedding Areas (currently format-text only).
2013-02-14 18:35:57 +04:00
int (*fun)(struct disk_locn *, void *),
void *baton)
{
refactor: rename embedding area -> bootloader area
2013-05-28 14:37:22 +04:00
struct data_area_list *ba;
dm_list_iterate_items(ba, &info->bas) {
if (!fun(&ba->disk_locn, baton))
pv_header_extension: add supporting infrastructure for PV header extension (flags & Embedding Area) PV header extension comes just beyond the existing PV header base: PV header base (existing): - uuid - device size - null-terminated list of Data Areas - null-terminater list of MetaData Areas PV header extension: - extension version - flags - null-terminated list of Embedding Areas This patch also adds "eas" (Embedding Areas) list to lvmcache (lvmcache_info) and it also adds support for common operations on the list (just like for already existing "das" - Data Areas list): - lvmcache_add_ea - lvmcache_update_eas - lvmcache_foreach_ea - lvmcache_del_eas Also, add ea_start and ea_size to struct physical_volume for processing PV Embedding Area location throughout the code (currently only one Embedding Area is supported, though the definition on disk allows for more if needed in the future...). Also, define FMT_EAS format flag to mark that the format actually supports Embedding Areas (currently format-text only).
2013-02-14 18:35:57 +04:00
return_0;
}
return 1;
}
pvremove: device check doesn't require label_read It just needs to check if the device was found during the scan, which means checking if it exists in lvmcache.
2018-02-09 21:43:12 +03:00
struct label *lvmcache_get_dev_label(struct device *dev)
{
struct lvmcache_info *info;
if ((info = lvmcache_info_from_pvid(dev->pvid, NULL, 0))) {
/* dev would be different for a duplicate */
if (info->dev == dev)
return info->label;
}
return NULL;
}
int lvmcache_has_dev_info(struct device *dev)
{
if (lvmcache_info_from_pvid(dev->pvid, NULL, 0))
return 1;
return 0;
}
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
/*
* The lifetime of the label returned is tied to the lifetime of the
* lvmcache_info which is the same as lvmcache itself.
*/
struct label *lvmcache_get_label(struct lvmcache_info *info) {
return info->label;
}
uint64_t lvmcache_device_size(struct lvmcache_info *info) {
return info->device_size;
}
void lvmcache_set_device_size(struct lvmcache_info *info, uint64_t size) {
info->device_size = size;
}
struct device *lvmcache_device(struct lvmcache_info *info) {
return info->dev;
}
lvmcache/lvmetad: cache PV extension version Store PV extension version in lvmcache/lvmetad for use throughout the code.
2016-02-11 18:25:36 +03:00
void lvmcache_set_ext_version(struct lvmcache_info *info, uint32_t version)
{
info->ext_version = version;
}
uint32_t lvmcache_ext_version(struct lvmcache_info *info) {
return info->ext_version;
}
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
lvmcache/lvmetad: cache PV extension flags Store PV extension flags in lvmcache/lvmetad for use throughout the code.
2015-03-09 14:52:07 +03:00
void lvmcache_set_ext_flags(struct lvmcache_info *info, uint32_t flags) {
info->ext_flags = flags;
}
uint32_t lvmcache_ext_flags(struct lvmcache_info *info) {
return info->ext_flags;
}
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
int lvmcache_is_orphan(struct lvmcache_info *info) {
if (!info->vginfo)
return 1; /* FIXME? */
return is_orphan_vg(info->vginfo->vgname);
}
int lvmcache_vgid_is_cached(const char *vgid) {
struct lvmcache_vginfo *vginfo;
The lvmetad client-side integration. Only active when use_lvmetad = 1 is set in lvm.conf *and* lvmetad is running.
2012-02-23 17:11:07 +04:00
lvmetad: rework command connection setup and checking The lvmetad connection is created within the init_connections() path during command startup, rather than via the old lvmetad_active() check. The old lvmetad_active() checks are replaced with lvmetad_used() which is a simple check that tests if the command is using/connected to lvmetad. The old lvmetad_set_active(cmd, 0) calls, which stopped the command from using lvmetad (to revert to disk scanning), are replaced with lvmetad_make_unused(cmd).
2016-04-14 01:00:01 +03:00
if (lvmetad_used())
The lvmetad client-side integration. Only active when use_lvmetad = 1 is set in lvm.conf *and* lvmetad is running.
2012-02-23 17:11:07 +04:00
return 1;
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
vginfo = lvmcache_vginfo_from_vgid(vgid);
if (!vginfo || !vginfo->vgname)
return 0;
if (is_orphan_vg(vginfo->vgname))
return 0;
return 1;
}
scan: use new label_scan for lvmcache_label_scan To do label scanning, lvm code calls lvmcache_label_scan(). Change lvmcache_label_scan() to use the new label_scan() based on bcache. Also add lvmcache_label_rescan_vg() which calls the new label_scan_devs() which does label scanning on only the specified devices. This is for a subsequent commit and is not yet used.
2018-02-07 22:14:08 +03:00
void lvmcache_set_independent_location(const char *vgname)
{
struct lvmcache_vginfo *vginfo;
if ((vginfo = lvmcache_vginfo_from_vgname(vgname, NULL)))
vginfo->independent_metadata_location = 1;
}
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
/*
* Return true iff it is impossible to find out from this info alone whether the
* PV in question is or is not an orphan.
*/
int lvmcache_uncertain_ownership(struct lvmcache_info *info) {
return mdas_empty_or_ignored(&info->mdas);
}
cleanup: preserve signesss and type size on return values
2013-02-05 19:43:16 +04:00
uint64_t lvmcache_smallest_mda_size(struct lvmcache_info *info)
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
{
pvs: fix segfaults with orphans Several fields used to display 0 if undefined. Recent changes to the way the fields are reported threw away some tests for valid pointers, leading to segfaults with 'pvs -o all'. Reinstate the original behaviour.
2014-01-14 07:17:27 +04:00
if (!info)
return UINT64_C(0);
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
return find_min_mda_size(&info->mdas);
}
const struct format_type *lvmcache_fmt(struct lvmcache_info *info) {
return info->fmt;
}
cache: Store metadata size and checksum. Refactor the recent metadata-reading optimisation patches. Remove the recently-added cache fields from struct labeller and struct format_instance. Instead, introduce struct lvmcache_vgsummary to wrap the VG information that lvmcache holds and add the metadata size and checksum to it. Allow this VG summary information to be looked up by metadata size + checksum. Adjust the debug log messages to make it clear when this shortcut has been successful. (This changes the optimisation slightly, and might be extendable further.) Add struct cached_vg_fmtdata to format-specific vg_read calls to preserve state alongside the VG across separate calls and indicate if the details supplied match, avoiding the need to read and process the VG metadata again.
2015-03-19 02:43:02 +03:00
int lvmcache_lookup_mda(struct lvmcache_vgsummary *vgsummary)
{
struct lvmcache_vginfo *vginfo;
if (!vgsummary->mda_size)
return 0;
/* FIXME Index the checksums */
dm_list_iterate_items(vginfo, &_vginfos) {
if (vgsummary->mda_checksum == vginfo->mda_checksum &&
vgsummary->mda_size == vginfo->mda_size &&
!is_orphan_vg(vginfo->vgname)) {
vgsummary->vgname = vginfo->vgname;
vgsummary->creation_host = vginfo->creation_host;
vgsummary->vgstatus = vginfo->status;
scan: skip device rescan in vg_read For reporting commands (pvs,vgs,lvs,pvdisplay,vgdisplay,lvdisplay) we do not need to repeat the label scan of devices in vg_read if they all had matching metadata in the initial label scan. The data read by label scan can just be reused for the vg_read. This cuts the amount of device i/o in half, from two reads of each device to one. We have to be careful to avoid repairing the VG if we've skipped rescanning. (The VG repair code is very poor, and will be redone soon.)
2018-04-19 00:29:42 +03:00
vgsummary->seqno = vginfo->seqno;
lvmcache: copy just 32bytes Copy only bytes which fits. vginfo->vgid is [ID_LEN + 1] vgsummary->vgid has only [ID_LEN] Reported by Coverity.
2015-05-07 12:28:22 +03:00
/* vginfo->vgid has 1 extra byte then vgsummary->vgid */
memcpy(&vgsummary->vgid, vginfo->vgid, sizeof(vgsummary->vgid));
cache: Store metadata size and checksum. Refactor the recent metadata-reading optimisation patches. Remove the recently-added cache fields from struct labeller and struct format_instance. Instead, introduce struct lvmcache_vgsummary to wrap the VG information that lvmcache holds and add the metadata size and checksum to it. Allow this VG summary information to be looked up by metadata size + checksum. Adjust the debug log messages to make it clear when this shortcut has been successful. (This changes the optimisation slightly, and might be extendable further.) Add struct cached_vg_fmtdata to format-specific vg_read calls to preserve state alongside the VG across separate calls and indicate if the details supplied match, avoiding the need to read and process the VG metadata again.
2015-03-19 02:43:02 +03:00
return 1;
}
}
return 0;
}
vgcreate: improve checks for existing global lock This tries harder to avoid creating duplicate global locks in sanlock VGs by refusing to create a new sanlock VG with a global lock if other sanlock VGs exist that may have a gl.
2015-07-24 18:06:58 +03:00
int lvmcache_contains_lock_type_sanlock(struct cmd_context *cmd)
{
struct lvmcache_vginfo *vginfo;
dm_list_iterate_items(vginfo, &_vginfos) {
if (vginfo->lock_type && !strcmp(vginfo->lock_type, "sanlock"))
return 1;
}
return 0;
}
pvscan: use process_each_pv The old code made two loops through the PVs: in the first loop it found the max PV and VG name lengths, and in the second loop it printed each PV using the name lengths as field widths for aligning columns. The new code uses process_each_pv() which makes one loop through the PVs. In the *first* call to pvscan_single(), the max name lengths are found by looping through the lvmcache entries which have been populated by the generic process_each code prior to calling any _single functions. Subsequent calls to pvscan_single() reuse the max lengths that were found by the first call.
2015-10-19 21:58:43 +03:00
void lvmcache_get_max_name_lengths(struct cmd_context *cmd,
unsigned *pv_max_name_len,
unsigned *vg_max_name_len)
{
struct lvmcache_vginfo *vginfo;
struct lvmcache_info *info;
unsigned len;
*vg_max_name_len = 0;
*pv_max_name_len = 0;
dm_list_iterate_items(vginfo, &_vginfos) {
len = strlen(vginfo->vgname);
if (*vg_max_name_len < len)
*vg_max_name_len = len;
dm_list_iterate_items(info, &vginfo->infos) {
len = strlen(dev_name(info->dev));
if (*pv_max_name_len < len)
*pv_max_name_len = len;
}
}
}
lvmcache: new function to check if VG is foreign When not using lvmetad, this uses the system_id field in the cached vginfo structs that are populated during a scan. When using lvmetad, this requests the VG from lvmetad, and checks the system_id field in the returned metadata.
2015-11-30 20:54:56 +03:00
int lvmcache_vg_is_foreign(struct cmd_context *cmd, const char *vgname, const char *vgid)
{
struct lvmcache_vginfo *vginfo;
int ret = 0;
lvmetad: rework command connection setup and checking The lvmetad connection is created within the init_connections() path during command startup, rather than via the old lvmetad_active() check. The old lvmetad_active() checks are replaced with lvmetad_used() which is a simple check that tests if the command is using/connected to lvmetad. The old lvmetad_set_active(cmd, 0) calls, which stopped the command from using lvmetad (to revert to disk scanning), are replaced with lvmetad_make_unused(cmd).
2016-04-14 01:00:01 +03:00
if (lvmetad_used())
lvmcache: new function to check if VG is foreign When not using lvmetad, this uses the system_id field in the cached vginfo structs that are populated during a scan. When using lvmetad, this requests the VG from lvmetad, and checks the system_id field in the returned metadata.
2015-11-30 20:54:56 +03:00
return lvmetad_vg_is_foreign(cmd, vgname, vgid);
if ((vginfo = lvmcache_vginfo_from_vgid(vgid)))
ret = !is_system_id_allowed(cmd, vginfo->system_id);
return ret;
}
scan: skip device rescan in vg_read For reporting commands (pvs,vgs,lvs,pvdisplay,vgdisplay,lvdisplay) we do not need to repeat the label scan of devices in vg_read if they all had matching metadata in the initial label scan. The data read by label scan can just be reused for the vg_read. This cuts the amount of device i/o in half, from two reads of each device to one. We have to be careful to avoid repairing the VG if we've skipped rescanning. (The VG repair code is very poor, and will be redone soon.)
2018-04-19 00:29:42 +03:00
/*
* Example of reading four devs in sequence from the same VG:
*
* dev1:
* lvmcache: creates vginfo with initial values
*
* dev2: all checksums match.
* mda_header checksum matches vginfo from dev1
* metadata checksum matches vginfo from dev1
* metadata is not parsed, and the vgsummary values copied
* from lvmcache from dev1 and passed back to lvmcache for dev2.
* lvmcache: attach info for dev2 to existing vginfo
*
* dev3: mda_header and metadata have unmatching checksums.
* mda_header checksum matches vginfo from dev1
* metadata checksum doesn't match vginfo from dev1
* produces read error in config.c
* lvmcache: info for dev3 is deleted, FIXME: use a defective state
*
* dev4: mda_header and metadata have matching checksums, but
* does not match checksum in lvmcache from prev dev.
* mda_header checksum doesn't match vginfo from dev1
* lvmcache_lookup_mda returns 0, no vgname, no checksum_only
* lvmcache: update_vgname_and_id sees checksum from dev4 does not
* match vginfo from dev1, so vginfo->scan_summary_mismatch is set.
* attach info for dev4 to existing vginfo
*
* dev5: config parsing error.
* lvmcache: info for dev5 is deleted, FIXME: use a defective state
*/
int lvmcache_scan_mismatch(struct cmd_context *cmd, const char *vgname, const char *vgid)
{
struct lvmcache_vginfo *vginfo;
if (!vgname || !vgid)
return 1;
if ((vginfo = lvmcache_vginfo_from_vgid(vgid)))
return vginfo->scan_summary_mismatch;
return 1;
}
Copy Permalink