shaba/lvm2
1
0
Fork 0
mirror of git://sourceware.org/git/lvm2.git synced 2024-12-22 17:35:59 +03:00
Code Releases Activity
30050769b1
lvm2/lib/cache/lvmcache.h

231 lines
9.5 KiB
C
Raw Normal View History

A new cache.
2002-11-18 16:53:58 +03:00
/*
Update copyright notices.
2004-03-30 23:35:44 +04:00
* Copyright (C) 2001-2004 Sistina Software, Inc. All rights reserved.
preparation for vg cache
2008-03-17 19:51:31 +03:00
* Copyright (C) 2004-2008 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
*/
#ifndef _LVM_CACHE_H
#define _LVM_CACHE_H
build: Don't generate symlinks in include/ dir As we start refactoring the code to break dependencies (see doc/refactoring.txt), I want us to use full paths in the includes (eg, #include "base/data-struct/list.h"). This makes it more obvious when we're breaking abstraction boundaries, eg, including a file in metadata/ from base/
2018-05-14 12:30:20 +03:00
#include "lib/device/dev-cache.h"
#include "lib/device/dev-type.h"
#include "lib/uuid/uuid.h"
#include "lib/label/label.h"
#include "lib/locking/locking.h"
A new cache.
2002-11-18 16:53:58 +03:00
Add is_global_vg and split out from is_orphan_vg.
2010-05-19 06:36:33 +04:00
#define ORPHAN_PREFIX VG_ORPHANS
#define ORPHAN_VG_NAME(fmt) ORPHAN_PREFIX "_" fmt
A new cache.
2002-11-18 16:53:58 +03:00
/* LVM specific per-volume info */
/* Eventual replacement for struct physical_volume perhaps? */
Begin to separate out segment types.
2004-05-05 01:25:57 +04:00
struct cmd_context;
struct format_type;
struct volume_group;
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 physical_volume;
Move the core of the lib/config/config.c functionality into libdevmapper, leaving behind the LVM-specific parts of the code (convenience wrappers that handle `struct device` and `struct cmd_context`, basically). A number of functions have been renamed (in addition to getting a dm_ prefix) -- namely, all of the config interface now has a dm_config_ prefix.
2011-08-30 18:55:15 +04:00
struct dm_config_tree;
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 format_instance;
struct metadata_area;
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
struct disk_locn;
Begin to separate out segment types.
2004-05-05 01:25: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
struct lvmcache_vginfo;
A new cache.
2002-11-18 16:53:58 +03: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
/*
* vgsummary represents a summary of the VG that is read
scan: add PV summary info to lvmcache Expand the lvmcache info that is saved by the scan to include PV info from the metadata.
2019-09-26 19:27:38 +03:00
* without a lock during label scan. It's used to populate
* basic lvmcache vginfo/info during label scan prior to
* vg_read().
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
*/
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 {
const char *vgname;
cov: clean up pvid and vgid usage pvid and vgid are sometimes a null-terminated string, and other times a 'struct id', and the two types were often cast between each other. When a struct id was cast to a char pointer, the resulting string would not necessarily be null terminated. Casting a null-terminated string id to a struct id is fine, but is still avoided when possible. A struct id is: int8_t uuid[ID_LEN] A string id is: char pvid[ID_LEN + 1] A convention is introduced to help distinguish them: - variables and struct fields named "pvid" or "vgid" should be null-terminated strings. - variables and struct fields named "pv_id" or "vg_id" should be struct id's. - examples: char pvid[ID_LEN + 1]; char vgid[ID_LEN + 1]; struct id pv_id; struct id vg_id; Function names also attempt to follow this convention. Avoid casting between the two types as much as possible, with limited exceptions when known to be safe and clearly commented. Avoid using variations of strcpy and strcmp, and instead use memcpy/memcmp with ID_LEN (with similar limited exceptions possible.)
2021-08-03 23:32:33 +03:00
char vgid[ID_LEN + 1];
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
uint64_t vgstatus;
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
const 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
const char *lock_type;
keep track of which mdas have old metadata in lvmcache This will be used for more advanced repair in a subsequent commit.
2019-02-05 22:09:56 +03:00
uint32_t seqno;
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;
keep track of which mdas have old metadata in lvmcache This will be used for more advanced repair in a subsequent commit.
2019-02-05 22:09:56 +03:00
int mda_num; /* 1 = summary from mda1, 2 = summary from mda2 */
unsigned mda_ignored:1;
unsigned zero_offset:1;
vgck: let updatemetadata repair mismatched metadata Let vgck --updatemetadata repair cases where different mdas hold indepedently valid but unmatching copies of the metadata, i.e. different text metadata checksums or text metadata sizes.
2019-10-08 22:44:24 +03:00
unsigned mismatch:1; /* lvmcache sets if this summary differs from previous values */
scan: add PV summary info to lvmcache Expand the lvmcache info that is saved by the scan to include PV info from the metadata.
2019-09-26 19:27:38 +03:00
struct dm_list pvsummaries;
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
};
clvmd: separate saved_vg from vginfo The clvmd saved_vg data is independent from the normal lvm lvmcache vginfo data, so separate saved_vg from vginfo. Normal lvm doesn't need to use save_vg at all, and in clvmd, lvmcache changes on vginfo can be made without worrying about unwanted effects on saved_vg.
2018-05-03 00:58:49 +03:00
int lvmcache_init(struct cmd_context *cmd);
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: 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
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);
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);
scanning: open devs rw when rescanning for write When vg_read rescans devices with the intention of writing the VG, the label rescan can open the devs RW so they do not need to be closed and reopened RW in dev_write_bytes.
2019-06-12 00:17:24 +03:00
int lvmcache_label_rescan_vg_rw(struct cmd_context *cmd, const char *vgname, const char *vgid);
metadata: open rw fd before closing ro fd lvm opens devices readonly to scan them, but needs to open then readwrite to update the metadata. Previously, the ro fd was closed before the rw fd was opened, leaving a small gap where the dev was not held open, and during which the dev could possibly change which storage it referred to. With the bcache_change_fd() interface, lvm opens a rw fd on a device to be written, tells bcache to change to the new rw fd, and closes the ro fd. . open dev ro . read dev with the ro fd (label_scan) . lock vg (ex for writing) . open dev rw . close ro fd . rescan dev to check if the metadata changed between the scan and the lock . if the metadata did change, reread in full . write the metadata
2020-09-18 22:42:23 +03:00
int lvmcache_label_reopen_vg_rw(struct cmd_context *cmd, const char *vgname, const char *vgid);
A new cache.
2002-11-18 16:53:58 +03:00
/* Add/delete a device */
pass cmd struct through more functions no functional change
2020-01-28 19:33:15 +03:00
struct lvmcache_info *lvmcache_add(struct cmd_context *cmd, struct labeller *labeller, const char *pvid,
change args for text label read function Have the caller pass the label_sector to the read function so the read function can set the sector field in the label struct, instead of having the read function return a pointer to the label for the caller to set the sector field. Also have the read function return a flag indicating to the caller that the scanned device was identified as a duplicate pv.
2019-02-05 22:40:34 +03:00
struct device *dev, uint64_t label_sector,
const char *vgname, const char *vgid,
uint32_t vgstatus, int *is_duplicate);
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
int lvmcache_add_orphan_vginfo(struct cmd_context *cmd, const char *vgname, struct format_type *fmt);
Another sync point - numerous fixes & clean ups.
2003-07-05 02:34:56 +04:00
void lvmcache_del(struct lvmcache_info *info);
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);
A new cache.
2002-11-18 16:53:58 +03:00
/* Update things */
pass cmd struct through more functions no functional change
2020-01-28 19:33:15 +03:00
int lvmcache_update_vgname_and_id(struct cmd_context *cmd, struct lvmcache_info *info,
[io paths] Unpick agk's aio stuff
2018-04-20 18:43:50 +03:00
struct lvmcache_vgsummary *vgsummary);
create separate lvmcache update functions for read and write The vg read and vg write cases need to update lvmcache differently, so create separate functions for them. The read case now handles checking for outdated mdas and moves them aside into a new list to be repaired in a subsequent commit.
2019-02-06 21:10:13 +03:00
int lvmcache_update_vg_from_read(struct volume_group *vg, unsigned precommitted);
int lvmcache_update_vg_from_write(struct volume_group *vg);
Another sync point - numerous fixes & clean ups.
2003-07-05 02:34:56 +04:00
void lvmcache_lock_vgname(const char *vgname, int read_only);
void lvmcache_unlock_vgname(const char *vgname);
A new cache.
2002-11-18 16:53:58 +03:00
/* Queries */
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);
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,
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
const char *vgid);
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);
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);
cov: clean up pvid and vgid usage pvid and vgid are sometimes a null-terminated string, and other times a 'struct id', and the two types were often cast between each other. When a struct id was cast to a char pointer, the resulting string would not necessarily be null terminated. Casting a null-terminated string id to a struct id is fine, but is still avoided when possible. A struct id is: int8_t uuid[ID_LEN] A string id is: char pvid[ID_LEN + 1] A convention is introduced to help distinguish them: - variables and struct fields named "pvid" or "vgid" should be null-terminated strings. - variables and struct fields named "pv_id" or "vg_id" should be struct id's. - examples: char pvid[ID_LEN + 1]; char vgid[ID_LEN + 1]; struct id pv_id; struct id vg_id; Function names also attempt to follow this convention. Avoid casting between the two types as much as possible, with limited exceptions when known to be safe and clearly commented. Avoid using variations of strcpy and strcmp, and instead use memcpy/memcmp with ID_LEN (with similar limited exceptions possible.)
2021-08-03 23:32:33 +03:00
struct lvmcache_info *lvmcache_info_from_pv_id(const struct id *pv_id, struct device *dev, int valid_only);
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);
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);
cov: clean up pvid and vgid usage pvid and vgid are sometimes a null-terminated string, and other times a 'struct id', and the two types were often cast between each other. When a struct id was cast to a char pointer, the resulting string would not necessarily be null terminated. Casting a null-terminated string id to a struct id is fine, but is still avoided when possible. A struct id is: int8_t uuid[ID_LEN] A string id is: char pvid[ID_LEN + 1] A convention is introduced to help distinguish them: - variables and struct fields named "pvid" or "vgid" should be null-terminated strings. - variables and struct fields named "pv_id" or "vg_id" should be struct id's. - examples: char pvid[ID_LEN + 1]; char vgid[ID_LEN + 1]; struct id pv_id; struct id vg_id; Function names also attempt to follow this convention. Avoid casting between the two types as much as possible, with limited exceptions when known to be safe and clearly commented. Avoid using variations of strcpy and strcmp, and instead use memcpy/memcmp with ID_LEN (with similar limited exceptions possible.)
2021-08-03 23:32:33 +03:00
struct device *lvmcache_device_from_pv_id(struct cmd_context *cmd, const struct id *pv_id, uint64_t *label_sector);
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);
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);
A new cache.
2002-11-18 16:53:58 +03:00
lvmcache: remove wrapper around lvmcache_get_vgnameids This was left over from when there was an lvmetad version of the function.
2019-06-11 22:09:13 +03:00
int lvmcache_get_vgnameids(struct cmd_context *cmd,
struct dm_list *vgnameids,
const char *only_this_vgname,
int include_internal);
toollib: avoid repeated lvmetad vg_lookup In process_each_{vg,lv,pv} when no vgname args are given, the first step is to get a list of all vgid/vgname on the system. This is exactly what lvmetad returns from a vg_list request. The current code is doing a vg_lookup on each VG after the vg_list and populating lvmcache with the info for each VG. These preliminary vg_lookup's are unnecessary, because they will be done again when the processing functions call vg_read. This patch eliminates the initial round of vg_lookup's, which can roughly cut in half the number of lvmetad requests and save a lot of extra work.
2015-05-06 00:24:50 +03:00
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);
void lvmcache_commit_metadata(const char *vgname);
Cache VG metadata internally while VG lock is held.
2008-04-02 02:40:13 +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_fid_add_mdas(struct lvmcache_info *info, struct format_instance *fid,
const char *id, int id_len);
int lvmcache_fid_add_mdas_pv(struct lvmcache_info *info, struct format_instance *fid);
int lvmcache_fid_add_mdas_vg(struct lvmcache_vginfo *vginfo, struct format_instance *fid);
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
int lvmcache_check_format(struct lvmcache_info *info, const struct format_type *fmt);
void lvmcache_del_mdas(struct lvmcache_info *info);
void lvmcache_del_das(struct lvmcache_info *info);
refactor: rename embedding area -> bootloader area
2013-05-28 14:37:22 +04:00
void lvmcache_del_bas(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
int lvmcache_add_mda(struct lvmcache_info *info, struct device *dev,
add mda arg to add_mda Allow the caller of lvmcache_add_mda() to have the new mda returned.
2019-02-05 22:24:23 +03:00
uint64_t start, uint64_t size, unsigned ignored,
struct metadata_area **mda_new);
Move lvmcache data structures behind an API (making the structures private to lvmcache.c). No functional change.
2012-02-10 05:28:27 +04:00
int lvmcache_add_da(struct lvmcache_info *info, uint64_t start, uint64_t 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);
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 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);
uint32_t lvmcache_ext_version(struct lvmcache_info *info);
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);
uint32_t lvmcache_ext_flags(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
const struct format_type *lvmcache_fmt(struct lvmcache_info *info);
struct label *lvmcache_get_label(struct lvmcache_info *info);
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);
int lvmcache_has_dev_info(struct device *dev);
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);
int lvmcache_update_das(struct lvmcache_info *info, struct physical_volume *pv);
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);
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_mda(struct lvmcache_info *info,
int (*fun)(struct metadata_area *, void *),
void *baton);
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);
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);
tidy: declaration names match implementation Put in sync some naming used for function declaration and actual in-code implementation.
2017-07-20 20:13:32 +03:00
int lvmcache_foreach_pv(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
int (*fun)(struct lvmcache_info *, void *), void * baton);
uint64_t lvmcache_device_size(struct lvmcache_info *info);
void lvmcache_set_device_size(struct lvmcache_info *info, uint64_t size);
struct device *lvmcache_device(struct lvmcache_info *info);
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);
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
lvmcache: renaming functions and variables related to duplicates, no functional changes.
2019-08-01 21:50:04 +03:00
bool lvmcache_has_duplicate_devs(void);
improve duplicate pv handling for md components Eliminate md components at the start so they don't interfere with actual duplicates, and don't need to be removed later. This also allows for choosing no copy of a PVID if they all happen to be md components.
2019-08-01 23:04:10 +03:00
void lvmcache_del_dev_from_duplicates(struct device *dev);
bool lvmcache_dev_is_unused_duplicate(struct device *dev);
int lvmcache_pvid_in_unused_duplicates(const char *pvid);
lvmcache: renaming functions and variables related to duplicates, no functional changes.
2019-08-01 21:50:04 +03:00
int lvmcache_get_unused_duplicates(struct cmd_context *cmd, struct dm_list *head);
lvmcache: improve duplicate PV handling Wait to compare and choose alternate duplicate devices until after all devices are scanned. During scanning, the first duplicate dev is kept in lvmcache, and others are kept in a new list (_found_duplicate_devs). After all devices are scanned, compare all the duplicates available for a given PVID and decide which is best. If the dev used in lvmcache is changed, drop the old dev from lvmcache entirely and rescan the replacement dev. Previously the VG metadata from the old dev was kept in lvmcache and only the dev was replaced. A new config setting devices/allow_changes_with_duplicate_pvs can be set to 0 which disallows modifying a VG or activating LVs in it when the VG contains PVs with duplicate devices. Set to 1 is the old behavior which allowed the VG to be changed. The logic for which of two devs is preferred has changed. The primary goal is to choose a device that is currently in use if the other isn't, e.g. by an active LV. . prefer dev with fs mounted if the other doesn't, else . prefer dev that is dm if the other isn't, else . prefer dev in subsystem if the other isn't If neither device is preferred by these rules, then don't change devices in lvmcache, leaving the one that was found first. The previous logic for preferring a device was: . prefer dev in subsystem if the other isn't, else . prefer dev without holders if the other has holders, else . prefer dev that is dm if the other isn't
2016-02-09 22:06:27 +03:00
int vg_has_duplicate_pvs(struct volume_group *vg);
improve duplicate pv handling for md components Eliminate md components at the start so they don't interfere with actual duplicates, and don't need to be removed later. This also allows for choosing no copy of a PVID if they all happen to be md components.
2019-08-01 23:04:10 +03:00
int lvmcache_found_duplicate_vgnames(void);
lvmcache: rework handling of VGs with duplicate vgnames The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
2020-01-28 20:47:37 +03:00
bool lvmcache_has_duplicate_local_vgname(const char *vgid, const char *vgname);
improve duplicate pv handling for md components Eliminate md components at the start so they don't interfere with actual duplicates, and don't need to be removed later. This also allows for choosing no copy of a PVID if they all happen to be md components.
2019-08-01 23:04:10 +03:00
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);
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);
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);
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
keep track of which mdas have old metadata in lvmcache This will be used for more advanced repair in a subsequent commit.
2019-02-05 22:09:56 +03:00
bool lvmcache_scan_mismatch(struct cmd_context *cmd, const char *vgname, const char *vgid);
clvmd: separate saved_vg from vginfo The clvmd saved_vg data is independent from the normal lvm lvmcache vginfo data, so separate saved_vg from vginfo. Normal lvm doesn't need to use save_vg at all, and in clvmd, lvmcache changes on vginfo can be made without worrying about unwanted effects on saved_vg.
2018-05-03 00:58:49 +03:00
cov: clean up pvid and vgid usage pvid and vgid are sometimes a null-terminated string, and other times a 'struct id', and the two types were often cast between each other. When a struct id was cast to a char pointer, the resulting string would not necessarily be null terminated. Casting a null-terminated string id to a struct id is fine, but is still avoided when possible. A struct id is: int8_t uuid[ID_LEN] A string id is: char pvid[ID_LEN + 1] A convention is introduced to help distinguish them: - variables and struct fields named "pvid" or "vgid" should be null-terminated strings. - variables and struct fields named "pv_id" or "vg_id" should be struct id's. - examples: char pvid[ID_LEN + 1]; char vgid[ID_LEN + 1]; struct id pv_id; struct id vg_id; Function names also attempt to follow this convention. Avoid casting between the two types as much as possible, with limited exceptions when known to be safe and clearly commented. Avoid using variations of strcpy and strcmp, and instead use memcpy/memcmp with ID_LEN (with similar limited exceptions possible.)
2021-08-03 23:32:33 +03:00
int lvmcache_vginfo_has_pvid(struct lvmcache_vginfo *vginfo, const char *pvid_arg);
add device hints to reduce scanning Save the list of PVs in /run/lvm/hints. These hints are used to reduce scanning in a number of commands to only the PVs on the system, or only the PVs in a requested VG (rather than all devices on the system.)
2018-12-07 23:35:22 +03:00
io: warn when metadata size approaches io memory size When a single copy of metadata gets within 1MB of the current io_memory_size value, begin printing a warning that the io_memory_size should be increased.
2019-03-04 21:13:09 +03:00
uint64_t lvmcache_max_metadata_size(void);
void lvmcache_save_metadata_size(uint64_t val);
pvscan: autoactivate without lvmetad When lvmetad is not used, use temporary files to record which PVs have appeared. Use these temp files to determine when a VG is complete, to trigger autoactivation. This change allows us to remove lvmetad while keeping the same autoactivation behavior that lvmetad provides. The temp files are created in /run/lvm/pvs_online/ and are named for the PVID of the PV. The files contain the major:minor of the device the PV was read from. e.g. if VG foo has dev1 and dev2, then: . pvscan --cache -aay dev1 reads vg metadata from dev1 creates /run/lvm/pvs_online/<pvid-of-dev1> checks if all vg->pvs are online: no . pvscan --cache -aay dev2 reads vg metadata from dev2 creates /run/lvm/pvs_online/<pvid-of-dev2> checks if all vg->pvs are online: yes autoactivates vg A 'pvscan --cache dev' (without -aay) still records that dev is online. A 'pvscan --cache --major X --minor Y' after a device is gone will remove the temp file for it. A 'pvscan --cache [-aay]' (no devs) resets the state of temp files by removing them all, then scanning all devs and creating temp files for PVs that are found. If no online files exist, the first pvscan --cache scans all devs and creates temp files for any PVs found. The scope of the temp files is only pvscan, and they are only used for pvscan-based autoactivation. No other commands are concerned with or aware of these temp files. When lvm creates or removes PVs, no attempt is made to update the temp files.
2018-06-28 22:48:03 +03:00
int dev_in_device_list(struct device *dev, struct dm_list *head);
ability to keep track of bad mdas in lvmcache mda's that cannot be processed by lvm because of some corruption can be kept on a separate list. These will be used for more advanced repair in a subsequent commit.
2019-02-05 21:39:08 +03:00
bool lvmcache_has_bad_metadata(struct device *dev);
keep track of which mdas have old metadata in lvmcache This will be used for more advanced repair in a subsequent commit.
2019-02-05 22:09:56 +03:00
bool lvmcache_has_old_metadata(struct cmd_context *cmd, const char *vgname, const char *vgid, struct device *dev);
ability to keep track of outdated pvs in lvmcache Outdated PVs hold metadata for VG from which they have been removed. Add the ability to keep track of these in lvmcache. This will be used for more advanced repair in a subsequent commit.
2019-02-05 21:55:51 +03:00
void lvmcache_get_outdated_devs(struct cmd_context *cmd,
const char *vgname, const char *vgid,
struct dm_list *devs);
void lvmcache_get_outdated_mdas(struct cmd_context *cmd,
const char *vgname, const char *vgid,
struct device *dev,
struct dm_list **mdas);
bool lvmcache_is_outdated_dev(struct cmd_context *cmd,
const char *vgname, const char *vgid,
struct device *dev);
void lvmcache_del_outdated_devs(struct cmd_context *cmd,
const char *vgname, const char *vgid);
ability to keep track of bad mdas in lvmcache mda's that cannot be processed by lvm because of some corruption can be kept on a separate list. These will be used for more advanced repair in a subsequent commit.
2019-02-05 21:39:08 +03:00
void lvmcache_save_bad_mda(struct lvmcache_info *info, struct metadata_area *mda);
void lvmcache_get_bad_mdas(struct cmd_context *cmd,
const char *vgname, const char *vgid,
struct dm_list *bad_mda_list);
scanning: optimize by checking text offset and checksum After the VG lock is taken for vg_read, reread the mda_header and compare the metadata text offset and checksum to what was seen during label scan. If it is unchanged, then the metadata has not changed since the label scan, and the metadata does not need to be reread under the lock for command processing. For commands that do not make changes (e.g. reporting), the mda_header is reread and checked on one mda to decide if the full metadata rereading can be skipped. For other commands (e.g. modifying the vg) the mda_header is reread and checked from all PVs. (These could probably just check one mda also.)
2019-11-26 20:56:51 +03:00
void lvmcache_get_mdas(struct cmd_context *cmd,
const char *vgname, const char *vgid,
struct dm_list *mda_list);
devices: support printing the filter that rejects a device Use of this new message function needs to be added to various commands to improve the output.
2020-07-20 20:48:36 +03:00
const char *dev_filtered_reason(struct device *dev);
const char *devname_error_reason(const char *devname);
lvmcache: add lvmcache_get_dev_mda for future patch
2020-10-15 20:53:01 +03:00
struct metadata_area *lvmcache_get_dev_mda(struct device *dev, int mda_num);
md component detection changes Move extra md component detection into the label scan phase. It had been in set_pv_devices which was deep within the vg_read phase, which wasn't a good place (better to detect that earlier.) Now that pv metadata info is available in the scan phase, the pv details (size and device_hint) can be used for extra md checking. Use the device_hint from the pv metadata to trigger a full md component check if the device_hint begins with /dev/md. Stop triggering full md component checks based on missing udev info for a dev. Changes to tests to reflect that the code is now detecting md components in some test case that it wasn't before.
2021-02-06 01:16:03 +03:00
void lvmcache_extra_md_component_checks(struct cmd_context *cmd);
device usage based on devices file The LVM devices file lists devices that lvm can use. The default file is /etc/lvm/devices/system.devices, and the lvmdevices(8) command is used to add or remove device entries. If the file does not exist, or if lvm.conf includes use_devicesfile=0, then lvm will not use a devices file. When the devices file is in use, the regex filter is not used, and the filter settings in lvm.conf or on the command line are ignored. LVM records devices in the devices file using hardware-specific IDs, such as the WWID, and attempts to use subsystem-specific IDs for virtual device types. These device IDs are also written in the VG metadata. When no hardware or virtual ID is available, lvm falls back using the unstable device name as the device ID. When devnames are used, lvm performs extra scanning to find devices if their devname changes, e.g. after reboot. When proper device IDs are used, an lvm command will not look at devices outside the devices file, but when devnames are used as a fallback, lvm will scan devices outside the devices file to locate PVs on renamed devices. A config setting search_for_devnames can be used to control the scanning for renamed devname entries. Related to the devices file, the new command option --devices <devnames> allows a list of devices to be specified for the command to use, overriding the devices file. The listed devices act as a sort of devices file in terms of limiting which devices lvm will see and use. Devices that are not listed will appear to be missing to the lvm command. Multiple devices files can be kept in /etc/lvm/devices, which allows lvm to be used with different sets of devices, e.g. system devices do not need to be exposed to a specific application, and the application can use lvm on its own set of devices that are not exposed to the system. The option --devicesfile <filename> is used to select the devices file to use with the command. Without the option set, the default system devices file is used. Setting --devicesfile "" causes lvm to not use a devices file. An existing, empty devices file means lvm will see no devices. The new command vgimportdevices adds PVs from a VG to the devices file and updates the VG metadata to include the device IDs. vgimportdevices -a will import all VGs into the system devices file. LVM commands run by dmeventd not use a devices file by default, and will look at all devices on the system. A devices file can be created for dmeventd (/etc/lvm/devices/dmeventd.devices) If this file exists, lvm commands run by dmeventd will use it. Internal implementaion: - device_ids_read - read the devices file . add struct dev_use (du) to cmd->use_devices for each devices file entry - dev_cache_scan - get /dev entries . add struct device (dev) to dev_cache for each device on the system - device_ids_match - match devices file entries to /dev entries . match each du on cmd->use_devices to a dev in dev_cache, using device ID . on match, set du->dev, dev->id, dev->flags MATCHED_USE_ID - label_scan - read lvm headers and metadata from devices . filters are applied, those that do not need data from the device . filter-deviceid skips devs without MATCHED_USE_ID, i.e. skips /dev entries that are not listed in the devices file . read lvm label from dev . filters are applied, those that use data from the device . read lvm metadata from dev . add info/vginfo structs for PVs/VGs (info is "lvmcache") - device_ids_find_renamed_devs - handle devices with unstable devname ID where devname changed . this step only needed when devs do not have proper device IDs, and their dev names change, e.g. after reboot sdb becomes sdc. . detect incorrect match because PVID in the devices file entry does not match the PVID found when the device was read above . undo incorrect match between du and dev above . search system devices for new location of PVID . update devices file with new devnames for PVIDs on renamed devices . label_scan the renamed devs - continue with command processing
2020-06-23 21:25:41 +03:00
unsigned int lvmcache_vg_info_count(void);
A new cache.
2002-11-18 16:53:58 +03:00
#endif
Copy Permalink