summaryrefslogtreecommitdiff
path: root/tools/tools.h
Commit message (Collapse)AuthorAgeFilesLines
* toollib: provide proper hint for referencing VG uuid in case of duplicate VG ↵Peter Rajnoha2023-05-161-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | names vgrename does not support -S|--select, so do not provide a hint about using it. Instead, provide a hint about using VG uuid directly. ❯ vgs WARNING: VG name vg1 is used by VGs DXjcSK-gWfu-5gLh-9Kbg-sG49-dtRr-GqXzGL and MVMfyM-sjOa-M2xV-AT4Y-JddR-h4SP-UO5Ttk. Fix duplicate VG names with vgrename uuid, a device filter, or system IDs. VG #PV #LV #SN Attr VSize VFree vg1 1 0 0 wz--n- 124.00m 124.00m vg1 1 0 0 wz--n- 124.00m 124.00m (vgrename does not support -S|--select) ❯ vgrename vg1 vg2 WARNING: VG name vg1 is used by VGs DXjcSK-gWfu-5gLh-9Kbg-sG49-dtRr-GqXzGL and MVMfyM-sjOa-M2xV-AT4Y-JddR-h4SP-UO5Ttk. Fix duplicate VG names with vgrename uuid, a device filter, or system IDs. Multiple VGs found with the same name: skipping vg1 Use VG uuid in place of the VG name. (vgchange does support -S|--select) ❯ vgchange --addtag a vg1 WARNING: VG name vg1 is used by VGs DXjcSK-gWfu-5gLh-9Kbg-sG49-dtRr-GqXzGL and MVMfyM-sjOa-M2xV-AT4Y-JddR-h4SP-UO5Ttk. Fix duplicate VG names with vgrename uuid, a device filter, or system IDs. Multiple VGs found with the same name: skipping vg1 Use --select vg_uuid=<uuid> in place of the VG name.
* lvresize: restructure codeDavid Teigland2022-09-091-7/+9
| | | | | Rewrite top level resize function to prepare for adding new fs resizing.
* args: add ARG_NONINTERACTIVE for cmds not supported in lvm shellPeter Rajnoha2022-08-261-0/+1
| | | | | | | | | | | Certain args can't be used in lvm shell ("interactive mode") because they are not supported there. Add ARG_NONINTERACTIVE flag to mark such args and error out if we're in interactive mode and at the same time we detect use of such argument. Currently, this is the case for --reportformat arg - we don't support changing the format per command in lvm shell. The whole shell is running under a reportformat chosen at shell's start.
* move code from pvscan.c to online.cDavid Teigland2021-11-041-2/+0
| | | | | related to managing files in /run/lvm/pvs_online and /run/lvm/vgs_online
* vgchange -aay: optimize device scan using pvs_online filesDavid Teigland2021-11-041-1/+1
| | | | | | | | | | | | | | | | | | | Port the old pvscan -aay scanning optimization to vgchange -aay. The optimization uses pvs_online files created by pvscan --cache to derive a list of devices to use when activating a VG. This allows autoactivation of a VG to avoid scanning all devices, and only scan the devices used by the VG itself. The optimization is applied internally using the device hints interface. The new option "--autoactivation event" is given to pvscan and vgchange commands that are called by event activation. This informs the command that it is being used for event activation, so that it can apply checks and optimizations that are specific to event activation. Those include: - skipping the command if lvm.conf event_activation=0 - checking that a VG is complete before activating it - using pvs_online files to limit device scanning
* pvscan: add options listlvs listvg checkcompleteDavid Teigland2021-10-071-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | pvscan --cache <dev> . read only dev . create online file for dev pvscan --listvg <dev> . read only dev . list VG using dev pvscan --listlvs <dev> . read only dev . list VG using dev . list LVs using dev pvscan --cache --listvg [--checkcomplete] <dev> . read only dev . create online file for dev . list VG using dev . [check online files and report if VG is complete] pvscan --cache --listlvs [--checkcomplete] <dev> . read only dev . create online file for dev . list VG using dev . list LVs using dev . [check online files and report if VG is complete] . [check online files and report if LVs are complete] [--vgonline] can be used with --checkcomplete, to enable use of a vg online file. This results in only the first pvscan command to see the complete VG to report 'VG complete', and others will report 'VG finished'. This allows the caller to easily run a single activation of the VG. [--udevoutput] can be used with --cache --listvg --checkcomplete, to enable an output mode that prints LVM_VG_NAME_COMPLETE='vgname' that a udev rule can import, and prevents other output from the command (other output causes udev to ignore the command.) The list of complete LVs is meant to be passed to lvchange -aay, or the complete VG used with vgchange -aay. When --checkcomplete is used, lvm assumes that that the output will be used to trigger event-based autoactivation, so the pvscan does nothing if event_activation=0 and --checkcomplete is used. Example of listlvs ------------------ $ lvs -a vg -olvname,devices LV Devices lv_a /dev/loop0(0) lv_ab /dev/loop0(1),/dev/loop1(1) lv_abc /dev/loop0(3),/dev/loop1(3),/dev/loop2(1) lv_b /dev/loop1(0) lv_c /dev/loop2(0) $ pvscan --cache --listlvs --checkcomplete /dev/loop0 pvscan[35680] PV /dev/loop0 online, VG vg incomplete (need 2). VG vg incomplete LV vg/lv_a complete LV vg/lv_ab incomplete LV vg/lv_abc incomplete $ pvscan --cache --listlvs --checkcomplete /dev/loop1 pvscan[35681] PV /dev/loop1 online, VG vg incomplete (need 1). VG vg incomplete LV vg/lv_b complete LV vg/lv_ab complete LV vg/lv_abc incomplete $ pvscan --cache --listlvs --checkcomplete /dev/loop2 pvscan[35682] PV /dev/loop2 online, VG vg is complete. VG vg complete LV vg/lv_c complete LV vg/lv_abc complete Example of listvg ----------------- $ pvscan --cache --listvg --checkcomplete /dev/loop0 pvscan[35684] PV /dev/loop0 online, VG vg incomplete (need 2). VG vg incomplete $ pvscan --cache --listvg --checkcomplete /dev/loop1 pvscan[35685] PV /dev/loop1 online, VG vg incomplete (need 1). VG vg incomplete $ pvscan --cache --listvg --checkcomplete /dev/loop2 pvscan[35686] PV /dev/loop2 online, VG vg is complete. VG vg complete
* devices file: limit warnings about devices file entries not foundDavid Teigland2021-08-051-0/+2
| | | | | | All commands were printing a warning if a devices file entry was not found. Limit this to commands that report/display lvm state.
* skip indexing devices used by LVs in more commandsDavid Teigland2021-07-091-0/+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().
* device usage based on devices fileDavid Teigland2021-02-231-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* integrity: always default to journal modeDavid Teigland2020-09-011-2/+0
| | | | | lvconvert was defaulting to bitmap mode, and lvcreate was defaulting to journal mode.
* gcc: zero-sized array to fexlible array C99Zdenek Kabelac2020-09-011-1/+1
| | | | | | | | | | | | | | Switch remaining zero sized struct to flexible arrays to be C99 complient. These simple rules should apply: - The incomplete array type must be the last element within the structure. - There cannot be an array of structures that contain a flexible array member. - Structures that contain a flexible array member cannot be used as a member of another structure. - The structure must contain at least one named member in addition to the flexible array member. Although some of the code pieces should be still improved.
* tools: move struct element before variable lenght listZdenek Kabelac2020-08-281-1/+1
| | | | | | | Move prio field before 'variable' struct array field. Interesting why this has not been catched yet. TODO: think about test case
* lvcreate: new cache or writecache lv with single commandDavid Teigland2020-06-161-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To create a new cache or writecache LV with a single command: lvcreate --type cache|writecache -n Name -L Size --cachedevice PVfast VG [PVslow ...] - A new main linear|striped LV is created as usual, using the specified -n Name and -L Size, and using the optionally specified PVslow devices. - Then, a new cachevol LV is created internally, using PVfast specified by the cachedevice option. - Then, the cachevol is attached to the main LV, converting the main LV to type cache|writecache. Include --cachesize Size to specify the size of cache|writecache to create from the specified --cachedevice PVs, otherwise the entire cachedevice PV is used. The --cachedevice option can be repeated to create the cache from multiple devices, or the cachedevice option can contain a tag name specifying a set of PVs to allocate the cache from. To create a new cache or writecache LV with a single command using an existing cachevol LV: lvcreate --type cache|writecache -n Name -L Size --cachevol LVfast VG [PVslow ...] - A new main linear|striped LV is created as usual, using the specified -n Name and -L Size, and using the optionally specified PVslow devices. - Then, the cachevol LVfast is attached to the main LV, converting the main LV to type cache|writecache. In cases where more advanced types (for the main LV or cachevol LV) are needed, they should be created independently and then combined with lvconvert. Example ------- user creates a new VG with one slow device and one fast device: $ vgcreate vg /dev/slow1 /dev/fast1 user creates a new 8G main LV on /dev/slow1 that uses all of /dev/fast1 as a writecache: $ lvcreate --type writecache --cachedevice /dev/fast1 -n main -L 8G vg /dev/slow1 Example ------- user creates a new VG with two slow devs and two fast devs: $ vgcreate vg /dev/slow1 /dev/slow2 /dev/fast1 /dev/fast2 user creates a new 8G main LV on /dev/slow1 and /dev/slow2 that uses all of /dev/fast1 and /dev/fast2 as a writecache: $ lvcreate --type writecache --cachedevice /dev/fast1 --cachedevice /dev/fast2 -n main -L 8G vg /dev/slow1 /dev/slow2 Example ------- A user has several slow devices and several fast devices in their VG, the slow devs have tag @slow, the fast devs have tag @fast. user creates a new 8G main LV on the slow devs with a 2G writecache on the fast devs: $ lvcreate --type writecache -n main -L 8G --cachedevice @fast --cachesize 2G vg @slow
* Allow dm-integrity to be used for raid imagesDavid Teigland2020-04-151-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | dm-integrity stores checksums of the data written to an LV, and returns an error if data read from the LV does not match the previously saved checksum. When used on raid images, dm-raid will correct the error by reading the block from another image, and the device user sees no error. The integrity metadata (checksums) are stored on an internal LV allocated by lvm for each linear image. The internal LV is allocated on the same PV as the image. Create a raid LV with an integrity layer over each raid image (for raid levels 1,4,5,6,10): lvcreate --type raidN --raidintegrity y [options] Add an integrity layer to images of an existing raid LV: lvconvert --raidintegrity y LV Remove the integrity layer from images of a raid LV: lvconvert --raidintegrity n LV Settings Use --raidintegritymode journal|bitmap (journal is default) to configure the method used by dm-integrity to ensure crash consistency. Initialization When integrity is added to an LV, the kernel needs to initialize the integrity metadata/checksums for all blocks in the LV. The data corruption checking performed by dm-integrity will only operate on areas of the LV that are already initialized. The progress of integrity initialization is reported by the "syncpercent" LV reporting field (and under the Cpy%Sync lvs column.) Example: create a raid1 LV with integrity: $ lvcreate --type raid1 -m1 --raidintegrity y -n rr -L1G foo Creating integrity metadata LV rr_rimage_0_imeta with size 12.00 MiB. Logical volume "rr_rimage_0_imeta" created. Creating integrity metadata LV rr_rimage_1_imeta with size 12.00 MiB. Logical volume "rr_rimage_1_imeta" created. Logical volume "rr" created. $ lvs -a foo LV VG Attr LSize Origin Cpy%Sync rr foo rwi-a-r--- 1.00g 4.93 [rr_rimage_0] foo gwi-aor--- 1.00g [rr_rimage_0_iorig] 41.02 [rr_rimage_0_imeta] foo ewi-ao---- 12.00m [rr_rimage_0_iorig] foo -wi-ao---- 1.00g [rr_rimage_1] foo gwi-aor--- 1.00g [rr_rimage_1_iorig] 39.45 [rr_rimage_1_imeta] foo ewi-ao---- 12.00m [rr_rimage_1_iorig] foo -wi-ao---- 1.00g [rr_rmeta_0] foo ewi-aor--- 4.00m [rr_rmeta_1] foo ewi-aor--- 4.00m
* pvck: show specific dump option valuesDavid Teigland2019-12-101-0/+1
|
* pvck: repair headers and metadataDavid Teigland2019-11-271-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To write a new/repaired pv_header and label_header: pvck --repairtype pv_header --file <file> <device> This uses the metadata input file to find the PV UUID, device size, and data offset. To write new/repaired metadata text and mda_header: pvck --repairtype metadata --file <file> <device> This requires a good pv_header which points to one or two metadata areas. Any metadata areas referenced by the pv_header are updated with the specified metadata and a new mda_header. "--settings mda_num=1|2" can be used to select one mda to repair. To combine all header and metadata repairs: pvck --repair --file <file> <device> It's best to use a raw metadata file as input, that was extracted from another PV in the same VG (or from another metadata area on the same PV.) pvck will also accept a metadata backup file, but that will produce metadata that is not identical to other metadata copies on other PVs and other areas. So, when using a backup file, consider using it to update metadata on all PVs/areas. To get a raw metadata file to use for the repair, see pvck --dump metadata|metadata_search. List all instances of metadata from the metadata area: pvck --dump metadata_search <device> Save one instance of metadata at the given offset to the specified file (this file can be used for repair): pvck --dump metadata_search --file <file> --settings "metadata_offset=<off>" <device>
* exported vg handlingDavid Teigland2019-06-251-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The exported VG checking/enforcement was scattered and inconsistent. This centralizes it and makes it consistent, following the existing approach for foreign and shared VGs/PVs, which are very similar to exported VGs/PVs. The access policy that now applies to foreign/shared/exported VGs/PVs, is that if a foreign/shared/exported VG/PV is named on the command line (i.e. explicitly requested by the user), and the command is not permitted to operate on it because it is foreign/shared/exported, then an access error is reported and the command exits with an error. But, if the command is processing all VGs/PVs, and happens to come across a foreign/shared/exported VG/PV (that is not explicitly named on the command line), then the command silently skips it and does not produce an error. A command using tags or --select handles inaccessible VGs/PVs the same way as a command processing all VGs/PVs, and will not report/return errors if these inaccessible VGs/PVs exist. The new policy fixes the exit codes on a somewhat random set of commands that previously exited with an error if they were looking at all VGs/PVs and an exported VG existed on the system. There should be no change to which commands are allowed/disallowed on exported VGs/PVs. Certain LV commands (lvs/lvdisplay/lvscan) would previously not display LVs from an exported VG (for unknown reasons). This has not changed. The lvm fullreport command would previously report info about an exported VG but not about the LVs in it. This has changed to include all info from the exported VG.
* Use "cachevol" to refer to cache on a single LVDavid Teigland2019-02-271-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | and "cachepool" to refer to a cache on a cache pool object. The problem was that the --cachepool option was being used to refer to both a cache pool object, and to a standard LV used for caching. This could be somewhat confusing, and it made it less clear when each kind would be used. By separating them, it's clear when a cachepool or a cachevol should be used. Previously: - lvm would use the cache pool approach when the user passed a cache-pool LV to the --cachepool option. - lvm would use the cache vol approach when the user passed a standard LV in the --cachepool option. Now: - lvm will always use the cache pool approach when the user uses the --cachepool option. - lvm will always use the cache vol approach when the user uses the --cachevol option.
* add device hints to reduce scanningDavid Teigland2019-01-151-0/+3
| | | | | | | 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.)
* Add dm-writecache supportDavid Teigland2018-11-061-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | dm-writecache is used like dm-cache with a standard LV as the cache. $ lvcreate -n main -L 128M -an foo /dev/loop0 $ lvcreate -n fast -L 32M -an foo /dev/pmem0 $ lvconvert --type writecache --cachepool fast foo/main $ lvs -a foo -o+devices LV VG Attr LSize Origin Devices [fast] foo -wi------- 32.00m /dev/pmem0(0) main foo Cwi------- 128.00m [main_wcorig] main_wcorig(0) [main_wcorig] foo -wi------- 128.00m /dev/loop0(0) $ lvchange -ay foo/main $ dmsetup table foo-main_wcorig: 0 262144 linear 7:0 2048 foo-main: 0 262144 writecache p 253:4 253:3 4096 0 foo-fast: 0 65536 linear 259:0 2048 $ lvchange -an foo/main $ lvconvert --splitcache foo/main $ lvs -a foo -o+devices LV VG Attr LSize Devices fast foo -wi------- 32.00m /dev/pmem0(0) main foo -wi------- 128.00m /dev/loop0(0)
* remove unneded check to skip filter initDavid Teigland2018-09-121-2/+0
| | | | | There's no more persistent filter so we don't need to check for it.
* Remove lvmetadDavid Teigland2018-07-111-3/+3
| | | | | | | | | | | | | Native disk scanning is now both reduced and async/parallel, which makes it comparable in performance (and often faster) when compared to lvm using lvmetad. Autoactivation now uses local temp files to record online PVs, and no longer requires lvmetad. There should be no apparent command-level change in behavior.
* lvconvert: support to convert lv into vdopoolZdenek Kabelac2018-07-091-0/+3
| | | | | | | | Support: lvconvert --type vdo-pool vg/lv lvconvert --vdopool vg/lv --virtualsize 10G
* build: Don't generate symlinks in include/ dirJoe Thornber2018-05-141-22/+22
| | | | | | | 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/
* scan: skip device rescan in vg_readDavid Teigland2018-04-201-0/+4
| | | | | | | | | | | 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.)
* remove unnecessary REQUIRES_FULL_LABEL_SCANDavid Teigland2018-04-201-5/+2
| | | | we always scan all devices
* lvmcache: simplify metadata cacheDavid Teigland2018-04-201-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* cleanup: add _mb_ to regiosize optionZdenek Kabelac2018-04-201-1/+1
| | | | Just like with others mentions default unit in function name.
* persistent filter: Skip import before rescanAlasdair G Kergon2017-11-131-0/+2
| | | | | | The persistent filter should not be imported by any command that doesn't use it so take addtional note of REQUIRES_FULL_LABEL_SCAN (for vgrename) and introduce IGNORE_PERSISTENT_FILTER for vgscan and pvscan.
* lvconvert: support repair of cache/cachepoolZdenek Kabelac2017-09-201-1/+1
| | | | | Extend repair for cache and cachepool target and user 'lvconvert_repair' routine name.
* vgchange: split out code for systemidDavid Teigland2017-07-241-0/+1
| | | | | Use the command definitions to separate the implementation of vgchange systemid from the rest of vgchange.
* vgchange: split out code for lockstart and lockstopDavid Teigland2017-07-241-0/+1
| | | | | Use the command definitions to separate the implementation of lockstop and lockstart from the rest of vgchange.
* vgchange: separate change locktype and allow recoveryDavid Teigland2017-07-241-0/+2
| | | | | | | | | | | | | | | | | | | | Add an independent command definition for "vgchange --locktype", and split the implementation out of the set of common metadata changes. It is unlike normal metadata changes, and can only be run by itself. (Changing the lock type is similar in principle to changing the VG name or the VG system ID; it effects the ability of any host to see or access the VG.) At some point this command lost the ability to forcibly change the lock type of a shared VG to "none" (making it a local VG). This can be necessary to repair shared VGs (e.g. recovery steps that occur in vg_read are disabled for shared VGs because they are not locked properly, or recovering sanlock locks when the PV holding them is lost.) "vgchange --locktype none --lockopt force VG" is used as the method of forcing the shared VG to become local so that it can be repaired.
* pre-releasev2_02_169Alasdair G Kergon2017-03-281-1/+0
| | | | | | Removing some unused new lines and changing some incorrect "can't release until this is fixed" comments. Rename license.txt to make it clear its merely an included file, not itself a licence.
* commands: use correct relative signs with mirror optionDavid Teigland2017-03-101-0/+1
| | | | | | | | As was recently done with relative signes for sizes/extents, limit the signs used with the mirrors option, e.g. lvcreate --mirrors now does not accept or advertise an optional minus sign with the value. lvconvert --mirrors accepts +|-.
* cache: allow to specify cachemetadataformatZdenek Kabelac2017-03-101-0/+1
| | | | | | | OO_LVCREATE_CACHE accepts --cachemetadataformat. Support new option --cachemetadataformat auto|1|2 for caching. Word 'auto' can be also be given as '0'.
* commands: clean up and unify signed option value handlingDavid Teigland2017-03-081-0/+5
| | | | | | | | | | | | | | | | | | | | | | | Add new values for different sign variations, resulting in: size_VAL no sign accepted ssize_VAL accepts + or - psize_VAL accepts + nsize_VAL accpets - extents_VAL no sign accepted sextents_VAL accepts + or - pextents_VAL accepts + nextents_VAL accepts - Depending on the command being run, change the option values for --size, --extents, --poolmetadatasize to use the appropriate value from above. lvcreate uses no sign (but accepts + and ignores it). lvresize accepts +|- for a relative change. lvextend accepts + for a relative change. lvreduce accepts - for a relative change.
* commands: combine duplicate arrays for lv types and propsDavid Teigland2017-03-081-17/+2
| | | | | | | Like opt and val arrays in previous commit, combine duplicate arrays for lv types and props in command.c and lvmcmdline.c. Also move the command_names array to be defined in command.c so it's consistent with the others.
* commands: combine duplicate arrays for opt and valDavid Teigland2017-03-081-20/+0
| | | | | | command.c and lvmcmdline.c each had a full array defining all options and values. This duplication was not removed when the command.c code was merged into the run time.
* lvcreate/lvresize: the --size option accepts signed valuesDavid Teigland2017-03-021-1/+2
| | | | | | | | | | | | | | | | | | | There was confusion in the code about whether or not the --size option accepted a sign. Make it consistent and clear that it does. This exposes a new problem in that an option can only accept one value type, e.g. --size can only accept a signed number, it cannot accept a positive or negative number for some commands and reject negative numbers for others. In practice, lvcreate accepts only positive --size values and lvresize accepts positive or negative --size values. There is currently no way to encode this difference. Until that is fixed, the man page output is hacked to avoid printing the [+|-] prefix for sizes in lvcreate.
* man: use Size variable for a number with unitDavid Teigland2017-02-241-1/+1
| | | | | Define a separate variable type Size to represent a number that takes an optional UNIT.
* lvconvert: include swap behavior in generic pool syntaxDavid Teigland2017-02-171-1/+1
| | | | | | | | | | | | | | | | | For this syntax: lvconvert --thinpool LV1 --poolmetadata LV2 lvconvert --cachepool LV1 --poolmetadata LV2 Restore the metadata swapping behavior in addition to the pool creation behavior. When LV1 is already a pool, the metadata LV will be swapped with LV2. When LV1 is not a pool, it will be converted to a pool using the specified LV for metadata. This syntax is no longer advertised because of the ambiguous behavior. The primary syntaxes for pool creation and metadata swapping will be the advertised methods.
* Revert "lvconvert: enable previous syntax to swap metadata"David Teigland2017-02-141-1/+0
| | | | | | | | | | This reverts commit 717363bb9427c02addeb22ef77396132cb30c782. These alternate forms for swapping metadata cannot be distinguished from the command for creating a pool. If we were to add these alternate forms for swapping metadata, we would need to overload the pool creation command defs, making those definitions ambiguous.
* lvconvert: enable previous syntax to swap metadataDavid Teigland2017-02-131-0/+1
|
* args: use arg parsing function for region sizeDavid Teigland2017-02-131-0/+1
| | | | | Consolidate the validation of the region size arg in a new arg parsing function.
* lvconvert: add command to change region size of a raid LVDavid Teigland2017-02-131-0/+1
|
* commands: move command def parsing into lvm binaryDavid Teigland2017-02-131-0/+8
| | | | It was previously done at build time by the ccmd binary.
* args: add man page descriptionsDavid Teigland2017-02-131-1/+2
|
* lvconvert: use command defs for raid/mirror typesDavid Teigland2017-02-131-0/+3
| | | | | | | | | | All lvconvert functionality has been moved out of the previous monolithic lvconvert code, except conversions related to raid/mirror/striped/linear. This switches that remaining code to be based on command defs, and standard process_each_lv arg processing. This final switch results in quite a bit of dead code that is also removed.
* lvconvert: use command defs for mergemirrorsDavid Teigland2017-02-131-0/+4
| | | | | and route the generic --merge to one of the specific merge functions
View Lorry Controller Status