summaryrefslogtreecommitdiff
path: root/tools/vgimportdevices.c
Commit message (Collapse)AuthorAgeFilesLines
* cov: check syscall resultZdenek Kabelac2023-05-061-1/+2
|
* vgimportdevices: LOCK_EX requires <sys/file.h> includeJory Pratt2023-02-101-0/+2
| | | | | | https://linux.die.net/man/2/flock Bug: https://bugs.gentoo.org/887259
* lvmdevices: use deviceidtype option strictlyDavid Teigland2022-10-101-1/+1
| | | | | Only use the device id type specified by --deviceidtype, and fail if that type is not available for the device.
* vgimportdevices: fix locking when creating devices fileDavid Teigland2022-08-301-2/+8
| | | | | | | Take the devices file lock before creating a new devices file. (Was missed by the change to preemptively create the devices file prior to setup_devices(), which was done to improve the error path.)
* vgimportdevices: change result when devices are not addedDavid Teigland2022-08-301-13/+28
| | | | | | | | | | | | | | | | | | | | When using --all, if one VG is skipped, continue adding other VGs, and do not return an error from the command if some VGs are added. (A VG is skipped if it's missing PVs.) If the command fails during devices file setup or device scanning, then remove the devices file if it has been newly created by the command, and exit with an error. If devices from a named VG are not imported (e.g. the VG is missing devices), then remove the devices file if it has been newly created by the command, and exit with an error. If --all VGs are being imported, and no devices are found to include in the devices file, then remove the devices file if it has been newly created by the command, and exit with an error.
* vgimportdevices: fix incorrect deviceidtype usageDavid Teigland2022-04-061-2/+1
| | | | | | | | When a VG has PVs with different device id types, it would try to use the idtype of the previous PV in the loop. This would produce an unncessary warning, or could lead to using the devname idtype when a better idtype is available.
* vgimportdevices: skip lvmlockd lockingDavid Teigland2021-10-251-0/+11
| | | | | | | | Help bootstrapping existing shared vgs into the devices file. Reading the vg in vgimportdevices would require locking to be started, but vgchange lockstart won't see the vg if it's not in the devices file. The lvmlockd locks are not protecting vg modifications so skipping them here won't be a problem.
* cov: clean up pvid and vgid usageDavid Teigland2021-08-161-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.)
* backup: automatically store data on vg_unlockZdenek Kabelac2021-06-091-1/+0
| | | | | | | | | | Previously there have been necessary explicit call of backup (often either forgotten or over-used). With this patch the necessity to store backup is remember at vg_commit and once the VG is unlocked, the committed metadata are automatically store in backup file. This may possibly alter some printed messages from command when the backup is now taken later.
* cov: unused valueZdenek Kabelac2021-03-101-2/+1
|
* cov: remove unnecessary headersZdenek Kabelac2021-03-101-1/+0
|
* device usage based on devices fileDavid Teigland2021-02-231-0/+207
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