summaryrefslogtreecommitdiff
path: root/lib/cache
Commit message (Collapse)AuthorAgeFilesLines
* cleanup: correcting some log_printZdenek Kabelac2023-05-061-2/+2
| | | | | Correcting to log_print_unless_silent(), so -qq can do some work.
* lvmcache: fix valgrind error when dropping md duplicateDavid Teigland2023-04-251-0/+7
| | | | | | | When lvmcache info is dropped because it's an md component, then the lvmcache vginfo can also be dropped, but the list iterator was still using the list head in vginfo, so break from the loop earlier to avoid it.
* lvm: fix typosZdenek Kabelac2023-02-101-1/+1
| | | | | | Patch aec5e573afe610070eb2c6bed675d2a7c0efc7e8 was fixing some of typos only in generated file, but they need to be fixed in the source files.
* lvmcache: fix strncpy len for wwidDavid Teigland2022-12-011-5/+5
|
* devices: factor common list functionsDavid Teigland2022-11-072-37/+13
| | | | which were duplicated in various places
* device_id: handle duplicate serial numbersDavid Teigland2022-11-071-0/+16
| | | | | | | | | Handle multiple devices using the same serial number as their device id. After matching devices to devices file entries, if there is a discrepency between the ondisk PVID and the devices file PVID, then rematch devices to devices file entries using PVID, looking at all disks on the system with the same serial number.
* covscan: free wwid strings in lvmcacheDavid Teigland2022-09-211-15/+31
|
* apply multipath_component_detection=0 to duplicate PV handlingDavid Teigland2022-07-251-0/+3
| | | | | | | multipath_component_detection=0 has always applied to the filter-based component detection. Also apply this setting to the duplicate-PV handling which also eliminates multipath components (based on duplicate PVs having the same wwid.)
* exit with error when --devicesfile name doesn't existDavid Teigland2022-07-061-1/+2
|
* handle duplicate vgidsDavid Teigland2022-01-131-4/+16
| | | | | | | | | | | | | | | The approach to duplicate VGIDs has been that it is not possible or not allowed, so the behavior has been undefined. The actual result was unpredictable and/or broken, and generally unhelpful. Improve this by recognizing the problem, displaying the VGs, and printing a warning to fix the problem. Beyond this, using VGs with duplicate VGIDs remains undefined, but should work well enough to correct the problem with vgchange -u. It's possible to create this condition without too much difficulty by cloning PVs, followed by an incomplete attempt at making the two VGs unique (vgrename and pvchange -u, but missing vgchange -u.)
* lvmcache: remove lvmcache_update_vg_from_writeDavid Teigland2022-01-132-45/+0
| | | | | | | | After a vg_write, this function was used to attempt to make lvmcache data match the new state written to disk. It was not updated correctly in a many or most cases, and the resulting lvmcache is not actually used after vg_write, making the update unnecessary.
* Revert "handle duplicate vgids"David Teigland2022-01-111-16/+4
| | | | | | | | This reverts commit bd2baeaaa67da3885df9f06700565dc201c82861. This commit broke vgrename because vgrename relies on old bugs in lvmcache_update_vg_from_write and lvmcache_update_vgname which need to be fixed first.
* handle duplicate vgidsDavid Teigland2022-01-061-4/+16
| | | | | | | | | | | | | | | The approach to duplicate VGIDs has been that it is not possible or not allowed, so the behavior has been undefined. The actual result was unpredictable and/or broken, and generally unhelpful. Improve this by recognizing the problem, displaying the VGs, and printing a warning to fix the problem. Beyond this, using VGs with duplicate VGIDs remains undefined, but should work well enough to correct the problem with vgchange -u. It's possible to create this condition without too much difficulty by cloning PVs, followed by an incomplete attempt at making the two VGs unique (vgrename and pvchange -u, but missing vgchange -u.)
* devices: exclude md components when duplicate pvs are seenDavid Teigland2021-11-221-19/+149
| | | | | | | | Improve handling of md components that get through the filter, like the previous improvement for multipath. If md components get through the filter and trigger duplicate PV code, then eliminate any devs entirely that are not an md device.
* devices: exclude multipath components based on matching wwidDavid Teigland2021-11-181-7/+179
| | | | | | | | | | | | If multipath component devices get through the filter and cause lvm to see duplicate PVs, then check the wwid of the devs and drop the component devices as if they had been filtered. If a dm mpath device was found among the duplicates then use that as the PV, otherwise do not use any of the components as the PV. "duplicate PVs" associated with multipath configs will no longer stop commands from working.
* vgchange -aay: optimize device list using pvs_online filesDavid Teigland2021-11-052-0/+12
| | | | | | | | | | | | | | | | | | | | | | | Port another optimization from pvscan -aay to vgchange -aay: "pvscan: only add device args to dev cache" This optimization avoids doing a full dev_cache_scan, and instead populates dev-cache with only the devices in the VG being activated. This involves shifting the use of pvs_online files from the hints interface up to the higher level label_scan interface. This specialized label_scan is structured around creating a list of devices from the pvs_online files. Previously, a list of all devices was created first, and then reduced based on the pvs_online files. The initial step of listing all devices was slow when thousands of devices are present on the system. This optimization extends the previous optimization that used pvs_online files to limit the devices that were actually scanned (i.e. reading to identify the device): "vgchange -aay: optimize device scan using pvs_online files"
* fix segfault handling duplicate PVsDavid Teigland2021-10-141-1/+1
| | | | | cmd arg was missing when switching to use an alternative duplicate dev.
* fix lvmcache_add log_debug pvidDavid Teigland2021-10-131-4/+6
| | | | from previous cleanup
* cleanup: all lvmcache_add users pass char with 0Zdenek Kabelac2021-10-061-9/+3
| | | | No local copy needed, both users submit zero-end string as pv/vgid.
* handle bad metadata text in vg_read pathDavid Teigland2021-09-282-0/+16
| | | | | | | | | | | | | | | | | | Corrupt metadata text (with good mda header) was being handled in the label_scan phase, but not in the vg_read phase. This was sufficient because metadata areas would always be read and checksummed during label_scan (metadata parsing was skipped previously as an optimization.) This changed with the optimization in commit 61a6f9905e87e650f0bddae83fec6923bb100a57 "metadata: optimize reading metadata copies in scan" Now, some metadata areas will not be read and checksummed at all during the label_scan phase, only during the vg_read phase. This means that bad metadata text may first be detected in the vg_read phase. So, add equivalent bad metadata handling to the vg_read path to match the label_scan path.
* lvmcache: follow pv_id/pvid naming conventionDavid Teigland2021-09-201-2/+2
| | | | | | name the variable pv_id_arg to follow the convention: . "pvid" variable is null-terminated string . "pv_id" variable is non-null-terminated struct
* gcc: avoid name colision with function pv_id() from metadata.hZdenek Kabelac2021-09-201-4/+4
|
* cov: clean up pvid and vgid usageDavid Teigland2021-08-162-103/+128
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.)
* devices: rework libudev usageDavid Teigland2021-07-131-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | related to config settings: obtain_device_info_from_udev (controls if lvm gets a list of devices from readdir /dev or from libudev) external_device_info_source (controls if lvm asks libudev for device information) . Make the obtain_device_list_from_udev setting affect only the choice of readdir /dev vs libudev. The setting no longer controls if udev is used for device type checks. . Change obtain_device_list_from_udev default to 0. This helps avoid boot timeouts due to slow libudev queries, avoids reported failures from udev_enumerate_scan_devices, and avoids delays from "device not initialized in udev database" errors. Even without errors, for a system booting with 1024 PVs, lvm2-pvscan times improve from about 100 sec to 15 sec, and the pvscan command from about 64 sec to about 4 sec. . For external_device_info_source="none", remove all libudev device info queries, and use only lvm native device info. . For external_device_info_source="udev", first check lvm native device info, then check libudev info. . Remove sleep/retry loop when attempting libudev queries for device info. udev info will simply be skipped if it's not immediately available. . Only set up a libdev connection if it will be used by obtain_device_list_from_udev/external_device_info_source. . For native multipath component detection, use /etc/multipath/wwids. If a device has a wwid matching an entry in the wwids file, then it's considered a multipath component. This is necessary to natively detect multipath components when the mpath device is not set up.
* skip indexing devices used by LVs in more commandsDavid Teigland2021-07-091-2/+2
| | | | | | | | | | | | | | | | | | | | | expands commit d5a06f9a7df5a43b2e2311db62ff8d3011217d74 "pvscan: skip indexing devices used by LVs" The dev cache index is expensive and slow, so limit it to commands that are used to observe the state of lvm. The index is only used to print warnings about incorrect device use by active LVs, e.g. if an LV is using a multipath component device instead of the multipath device. Commands that continue to use the index and print the warnings: fullreport, lvmdiskscan, vgs, lvs, pvs, vgdisplay, lvdisplay, pvdisplay, vgscan, lvscan, pvscan (excluding --cache) A couple other commands were borrowing the DEV_USED_FOR_LV flag to just check if a device was actively in use by LVs. These are converted to the new dev_is_used_by_active_lv().
* coverity cleanupsDavid Teigland2021-06-161-0/+5
|
* lvmcache: fix memory leakZdenek Kabelac2021-04-231-1/+1
| | | | | | | | With commit 0b18c25d934564015402de33e15a267045ed1b8c there was introduced 'zalloc()' for allocation of outdates pvs, but no matching 'free()' is present. Switch to use cmd mempool instead of adding free() code into several places.
* hash: use individual hint sizesZdenek Kabelac2021-03-081-3/+3
| | | | | | | | | | | | | | Use different 'hint' size for dm_hash_create() call - so when debug info about hash is printed we can recognize which hash was in use. This patch doesn't change actual used size since that is always rounded to be power of 2 and >=16 - so as such is only a help to developer. We could eventually use 'name' arg, but since this would have changed API and this patchset will be routed to libdm & stable - we will just use this small trick.
* filters: better message for excluding LVDavid Teigland2021-03-031-0/+2
| | | | | | Make the generic "device is not usable" message from filter-usable more specific in case the device is not usable because it's an LV. (i.e. when scan_lvs=0)
* cleanup: free already checks for NULLZdenek Kabelac2021-03-021-2/+1
|
* device usage based on devices fileDavid Teigland2021-02-232-4/+86
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* fix for md component detection changesDavid Teigland2021-02-081-16/+40
| | | | | And some fine tuning of when the checks are applied in "start" mode.
* lvmcache: remove unused variable from last commitDavid Teigland2021-02-081-1/+0
|
* md component detection changesDavid Teigland2021-02-052-16/+103
| | | | | | | | | | | | | | | | | 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.
* lvmcache: rename label_read label_scan_devDavid Teigland2020-10-211-1/+1
| | | | for consistent naming with other similar functions
* lvmcache: add lvmcache_get_dev_mdaDavid Teigland2020-10-212-0/+17
| | | | for future patch
* debug: drop vgid from debugZdenek Kabelac2020-10-021-2/+2
| | | | | | From the code can be seen the VGID will be always NULL here as vgid != NULL is already handled before. Thus drop from being displayed.
* devices: support printing the filter that rejects a deviceDavid Teigland2020-10-012-0/+51
| | | | | Use of this new message function needs to be added to various commands to improve the output.
* tests: add case for metadata checksum differencesDavid Teigland2020-09-281-0/+3
| | | | | | | | | | Cover the case where two copies of metadata have the same seqno but different checksums. Also elaborate on an existing fixme in the code for this case, since we should be doing something better for this case. This had been uncovering an issue with reopening fds in readwrite mode.
* metadata: open rw fd before closing ro fdDavid Teigland2020-09-182-0/+17
| | | | | | | | | | | | | | | | | | | | | | | 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
* cleanup: matching declaration orderZdenek Kabelac2020-09-011-2/+2
| | | | Cosmetic
* lvmcache: use uint32_t for seqno cachingZdenek Kabelac2020-08-281-4/+4
|
* improve info about vgck updatemetadataDavid Teigland2020-06-031-0/+4
| | | | | Add man page info about this option, and add log messages pointing to this option.
* lvmcache: free vginfo lock_typeDavid Teigland2020-05-141-0/+2
|
* use refresh_filters only where neededDavid Teigland2020-04-221-10/+0
| | | | | | Filters are changed and need refresh in only one place (vgimportclone), so avoid doing the refresh for every other command that doesn't need it.
* lvmcache: rework handling of VGs with duplicate vgnamesDavid Teigland2020-04-212-257/+245
| | | | | | The previous method of managing duplicate vgnames prevented vgreduce from working if a foreign vg with the same name existed.
* pass cmd struct through more functionsDavid Teigland2020-04-212-7/+7
| | | | no functional change
* lvmcache_get_mda: remove unused functionDavid Teigland2020-04-212-35/+0
|
* scanning: optimize by checking text offset and checksumDavid Teigland2019-11-262-0/+28
| | | | | | | | | | | | | | 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.)
* cov: remove unused headersZdenek Kabelac2019-11-141-1/+0
|
View Lorry Controller Status