summaryrefslogtreecommitdiff
path: root/lib/activate
Commit message (Collapse)AuthorAgeFilesLines
...
* activation: move locking of critical sectionZdenek Kabelac2020-09-291-3/+8
| | | | | Move begining of 'suspending' critical section closer to _lv_suspend_lv() for better correctness of error paths.
* activation: use revert_lv on tree suspend failureZdenek Kabelac2020-09-221-0/+3
| | | | | | | | | | | | | | | | When thetable reload fails during suspend() - we were only calling plain resume() - and this will reload only those devices, which were left suspend, but will not try to restore metadata state according to lvm2 reverted metadata. So if we were reloading device tree - we have restored only top-level LV and rest of reverted device manipulation were left alone and possibly mismatched what is in committed metadata. FIXME: There are several cases were such revert will likely not work properly anyway as some operation are currenly handled in single commit, while they need multiple commits, but it's step towards better correctness. At least we catch there errors now earlier.
* Revert "raid: add _rimage and _rmeta as origin_only"Zdenek Kabelac2020-09-091-3/+2
| | | | | This reverts commit 3388e194892e9ab7a36b72e512796c2d218dae6e. More thinking needed.
* Revert "raid: do not enforce flushing of raids when it is not required"Zdenek Kabelac2020-09-091-1/+1
| | | | | This reverts commit ce5ea07411d57a2bd276d8d29e46ce30b957f657. More thinking needed.
* raid: do not enforce flushing of raids when it is not requiredZdenek Kabelac2020-09-081-1/+1
| | | | | | | This is probably somewhat experimantal patch - but when i.e. raid device is just extend, there should not be a technical need for flush, unless the target would stricly need it. It should allow faster processing of lvm command not being blocked by possibly longer flush.
* raid: add _rimage and _rmeta as origin_onlyZdenek Kabelac2020-09-081-2/+3
| | | | | | | Since we do not support rimage & rmeta for snapshots - we can avoid quering for -cow devices and add them as origin_only - since their snapshots (-cow) could have never existed. This redumes several ioctl operation during table preloading.
* cleanup: matching declaration orderZdenek Kabelac2020-09-011-3/+3
| | | | Cosmetic
* gcc: change zero-sized array to fexlible arrayZhao Heming2020-09-011-1/+1
| | | | | | this patch makes gcc happy with compiling option: [-Wstringop-overflow=] Signed-off-by: Zhao Heming <heming.zhao@suse.com>
* Allow dm-integrity to be used for raid imagesDavid Teigland2020-04-153-1/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* vdo: make vdopool wrapping device is read-onlyZdenek Kabelac2020-03-231-1/+1
| | | | | | | When vdopool is activated standalone - we use a wrapping linear device to hold actual vdo device active - for this we can set-up read-only device to ensure there cannot be made write through this device to actual pool device.
* writecache: working real dm uuid suffix for wcorig lvDavid Teigland2020-02-201-0/+4
|
* cachevol: stop dm errors with uncaching cache with cachevolZdenek Kabelac2020-02-111-7/+7
| | | | | | | | | | | | | | Fix the anoying kernel message reported: device-mapper: cache: 253:2: metadata operation 'dm_cache_commit' failed: error = -5 which has been reported while cachevol has been removed. Happened via confusing variable - so switch the variable to commonly user '_size' which presents a value in sector units and avoid 'scaling' this as extent length by vg extent size when placing 'error' target on removal path. Patch shouldn't have impact on actual users data, since at this moment of removal all date should have been already flushed to origin device. m
* cov: ensure read_ahead is availableZdenek Kabelac2019-11-111-1/+1
| | | | Make sure read_ahead pointer is not NULL when quering for RA.
* gcc: avoid declaration shadowingZdenek Kabelac2019-11-111-3/+3
| | | | dev_name is global in device.h
* activation: drop removed declarationZdenek Kabelac2019-10-311-2/+0
| | | | | Seems this function has been removed long time ago with: 3e781ea446bb7ddc9a494cbba6b6104dd51c3910
* mirror: fix leg splittingZdenek Kabelac2019-10-314-30/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Enhance lv_info with lv_info_with_name_check. This 'variant' not only check existance if UUID in DM table but also compares its DM name whether it's matching expected LV name. Otherwise activation may 'skip' activation with rename in case the DM UUID already exists, just device is different name. This change make fairly easier manipulation with i.e. detached mirror leg which ATM is using same UUID - just the LV name have been changed. Used code was not able to run 'activation' (and do a rename) and just skipped the call. So the code used to do a workaround and 'tried' to deactivate such LV firts - this however work only in non-clvmd case, as cluster was not having the lock for deactivated LV. With this extended lv_info code will run 'activation' and will synchronize the name to match expected LV name. Patch extends _lv_info() with new paramter 'with_name_check', which is later translated into 'name_check' argument for _info_run() which in case of name mismatch evaluates the check as if device does not exists. Such call is only used in one place _lv_activate() which then let activation run. All other invocation of _info() calls are left intact. TODO: fix mirror table manipulation (and raid)....
* snapshot: fix checking of merged thin volumeZdenek Kabelac2019-10-261-1/+2
| | | | | When merging of thin snapshot is taking place, the origin target will be of thin type.
* snapshot: correctly check device id of merged thinZdenek Kabelac2019-10-261-1/+10
| | | | | | | | When checking device id of a thin device that is just being merged - the snapshot actually could have been already finished which means '-real' suffix for the LV is already gone and just LV is there - so check explicitely for this condition and use correct UUID for this case.
* gcc: older compiler is happier with this initilizerZdenek Kabelac2019-10-211-1/+1
|
* cachevol: use CVOL UUID for cdata and cmeta layered devicesZdenek Kabelac2019-10-171-4/+6
| | | | | | | | | | | | | | | | Since code is using -cdata and -cmeta UUID suffixes, it does not need any new 'extra' ID to be generated and stored in metadata. Since introduce of new 'segtype' cache+CACHE_USES_CACHEVOL we can safely assume 'new' cache with cachevol will now be created without extra metadata_id and data_id in metadata. For backward compatibility, code still reads them in case older version of metadata have them - so it still should be able to activate such volumes. Bonus is lowered size of lv structure used to store info about LV (noticable with big volume groups).
* cachevol: drop no longer needed functionsZdenek Kabelac2019-10-142-93/+0
| | | | Code is no longer used/needed.
* cachevol: improve manipulation with dm treeZdenek Kabelac2019-10-141-70/+88
| | | | | | | | | | | Enhance activation of cached devices using cachevol. Correctly instatiace cachevol -cdata & -cmeta devices with '-' in name (as they are only layered devices). Code is also a bit more compacted (although still not ideal, as the usage of extra UUIDs stored in metadata is troublesome and will be repaired later). NOTE: this patch my brink potentially minor incompatiblity for 'runtime' upgrade
* cachevol: put _cvol as protected suffix.Zdenek Kabelac2019-10-141-1/+1
| | | | | | This revert "drop cvol dm uuid suffix for cachevol LVs" commit 5191057d9df3e5b92db3f80c412b99aea1074358. Start using -cvol for DM UUID.
* vdo: restore monitoring of vdo poolZdenek Kabelac2019-09-301-0/+2
| | | | Switch to -vpool layered name needs to monitor proper device.
* vdo: deactivate forgotten vdo poolZdenek Kabelac2019-09-301-0/+11
| | | | | | | | | | | If the linear mapping is lost (for whatever reason, i.e. test suite forcible 'dmsetup remove' linear LV, lvm2 had hard times figuring out how to deactivate such DM table. So add function which is in case inactive VDO pool LV checks if the pool is actually still active (-vpool device present) and it has open count == 0. In this case deactivation is allowed to continue and cleanup DM table.
* drop cvol dm uuid suffix for cachevol LVsDavid Teigland2019-09-231-1/+1
| | | | | The "-cvol" suffix on the uuid is interfering with activation code, so drop the suffix for now.
* cachevol: add dm uuid suffixes to hidden lvsDavid Teigland2019-09-201-7/+7
| | | | to indicate they are private lvm devs
* vdo: enhance activation with layer -vpoolZdenek Kabelac2019-09-172-7/+42
| | | | | | | | | | | | | | | | | | | | | | | | Enhance 'activation' experience for VDO pool to more closely match what happens for thin-pools where we do use a 'fake' LV to keep pool running even when no thinLVs are active. This gives user a choice whether he want to keep thin-pool running (wihout possibly lenghty activation/deactivation process) As we do plan to support multple VDO LVs to be mapped into a single VDO, we want to give user same experience and 'use-patter' as with thin-pools. This patch gives option to activate VDO pool only without activating VDO LV. Also due to 'fake' layering LV we can protect usage of VDO pool from command like 'mkfs' which do require exlusive access to the volume, which is no longer possible. Note: VDO pool contains 1024 initial sectors as 'empty' header - such header is also exposed in layered LV (as read-only LV). For blkid we are indentified as LV with UUID suffix - thus private DM device of lvm2 - so we do not need to store any extra info in this header space (aka zero is good enough).
* thin: activate layer pool aas read-only LVZdenek Kabelac2019-09-171-0/+5
| | | | | | | | | | | | When lvm2 is activating layered pool LV (to basically keep pool opened, the other function used to be 'locking' be in sync with DM table) use this LV in read-only mode - this prevents 'write' access into data volume content of thin-pool. Note: since EMPTY/unused thin-pool is created as 'public LV' for generic use by any user who i.e. wish to maintain thin-pool and thins himself. At this moment, thin-pool appears as writable LV. As soon as the 1st. thinLV is created, layer volume will appear is 'read-only' LV from this moment.
* devices: crypto skipZdenek Kabelac2019-09-171-0/+2
| | | | Devices with UUID signature CRYPT-SUBDEV are internal crypto devices.
* activation: use cmd pending mem for pending_deleteZdenek Kabelac2019-08-271-19/+12
| | | | | | | | | | | | | Since we need to preserve allocated strings across 2 separate activation calls of '_tree_action()' we need to use other mem pool them dm->mem - but since cmd->mem is released between individual lvm2 locking calls, we rather introduce a new separate mem pool just for pending deletes with easy to see life-span. (not using 'libmem' as it would basicaly keep allocations over the whole lifetime of clvmd) This patch is fixing previous commmit where the memory was improperly used after pool release.
* activation: extend handling of pending_deleteZdenek Kabelac2019-08-261-13/+11
| | | | | | | | | | | | | | | | | | | | | | | | With previous patch 30a98e4d6710a543692d40d11428ae4baea11b7b we started to put devices one pending_delete list instead of directly scheduling their removal. However we have operations like 'snapshot merge' where we are resuming device tree in 2 subsequent activation calls - so 1st such call will still have suspened devices and no chance to push 'remove' ioctl. Since we curently cannot easily solve this by doing just single activation call (which would be preferred solution) - we introduce a preservation of pending_delete via command structure and then restore it on next activation call. This way we keep to remove devices later - although it might be not the best moment - this may need futher tunning. Also we don't keep the list of operation in 1 trasaction (unless we do verify udev symlinks) - this could probably also make it more correct in terms of which 'remove' can be combined we already running 'resume'.
* activation: add synchronization pointZdenek Kabelac2019-08-201-8/+12
| | | | | | | | | | | Resuming of 'error' table entry followed with it's dirrect removal is now troublesame with latest udev as it may skip processing of udev rules for already 'dropped' device nodes. As we cannot 'synchronize' with udev while we know we have devices in suspended state - rework 'cleanup' so it collects nodes for removal into pending_delete list and process the list with synchronization once we are without any suspended nodes.
* pvmove: correcting read_ahead settingZdenek Kabelac2019-08-201-13/+34
| | | | | | | | | | | | | | When pvmove is finished, we do a tricky operation since we try to resume multiple different device that were all joined into 1 big tree. Currently we use the infromation from existing live DM table, where we can get list of all holders of pvmove device. We look for these nodes (by uuid) in new metadata, and we do now a full regular device add into dm tree structure. All devices should be already PRELOAD with correct table before entering suspend state, however for correctly working readahead we need to put correct info also into RESUME tree. Since table are preloaded, the same table is skip and resume, but correct read ahead is now set.
* activation: synchronize before removing devicesZdenek Kabelac2019-03-202-1/+15
| | | | | | | | | | | | | | | | | | | | | | | | Udev is running udev-rule action upon 'resume'. However lvm2 in special case is doing replacement of 'soon-to-be-removed' device with 'error' target for resuming and then follows actual removal - the sequence is usually quick, so when udev start action - it can result in 'strange' error message in kernel log like: Process '/usr/sbin/dmsetup info -j 253 -m 17 -c --nameprefixes --noheadings --rows -o name,uuid,suspended' failed with exit code 1. To avoid this - we need to ensure there is synchronization wait for udev between 'resume' and 'remove' part of this process. However existing code put strict requirement to avoid synchronizing with udev inside critical section - but this originally came from requirement to not do anything special while there could be devices in suspend-state. Now we are able to see differnce between critical section with or without suspended devices. For udev synchronization only suspended devices are prohibited to be there - so slightly relax condition and allow calling and using 'fs_sync()' even inside critical section - but there must not be any suspended device.
* dev_manager: add dev_manager_remove_dm_major_minorZdenek Kabelac2019-03-203-19/+20
| | | | | | | Move DM usage into dev_manager.c source file. Also convert STATUS to INFO ioctl - as that's enough to obtain UUID - this also avoid issuing unwanted flush on checked DM device for being mpath.
* Use "cachevol" to refer to cache on a single LVDavid Teigland2019-02-272-9/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* vdo: minor API cleanupZdenek Kabelac2019-01-213-20/+9
| | | | | | Since the parse_vdo_pool_status() become vdo_manip API part, and there will be no 'dm' matching status parser, the API can be simplified and closely match thin API here.
* vdo: add simple wrapper for getting pool percentageZdenek Kabelac2019-01-212-0/+14
| | | | | | Just like with i.e. thins provide simple function for getting percentage of VDO Pool usage (uses existing status function).
* raid: fix (de)activation of RaidLVs with visible SubLVsHeinz Mauelshagen2018-12-111-0/+6
| | | | | | | | | | | | | | | | | | | | There's a small window during creation of a new RaidLV when rmeta SubLVs are made visible to wipe them in order to prevent erroneous discovery of stale RAID metadata. In case a crash prevents the SubLVs from being committed hidden after such wiping, the RaidLV can still be activated with the SubLVs visible. During deactivation though, a deadlock occurs because the visible SubLVs are deactivated before the RaidLV. The patch adds _check_raid_sublvs to the raid validation in merge.c, an activation check to activate.c (paranoid, because the merge.c check will prevent activation in case of visible SubLVs) and shares the existing wiping function _clear_lvs in raid_manip.c moved to lv_manip.c and renamed to activate_and_wipe_lvlist to remove code duplication. Whilst on it, introduce activate_and_wipe_lv to share with (lvconvert|lvchange).c. Resolves: rhbz1633167
* gcc: avoid shadowing activate_lvZdenek Kabelac2018-12-012-6/+6
| | | | | Function activate_lv() is already declared, avoid its shadowing. activate.h:133: warning: shadowed declaration is here
* activation: trimming string is expectedZdenek Kabelac2018-11-081-5/+2
| | | | | | Commit 813347cf84617a946d9184f44c5fbd275bb41766 added extra validation, however in this particular we do want to trim suffix out so rather ignore resulting error code here intentionaly.
* Add dm-writecache supportDavid Teigland2018-11-064-0/+75
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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)
* Allow dm-cache cache device to be standard LVDavid Teigland2018-11-062-8/+271
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a single, standard LV is specified as the cache, use it directly instead of converting it into a cache-pool object with two separate LVs (for data and metadata). With a single LV as the cache, lvm will use blocks at the beginning for metadata, and the rest for data. Separate dm linear devices are set up to point at the metadata and data areas of the LV. These dm devs are given to the dm-cache target to use. The single LV cache cannot be resized without recreating it. If the --poolmetadata option is used to specify an LV for metadata, then a cache pool will be created (with separate LVs for data and metadata.) Usage: $ lvcreate -n main -L 128M vg /dev/loop0 $ lvcreate -n fast -L 64M vg /dev/loop1 $ lvs -a vg LV VG Attr LSize Type Devices main vg -wi-a----- 128.00m linear /dev/loop0(0) fast vg -wi-a----- 64.00m linear /dev/loop1(0) $ lvconvert --type cache --cachepool fast vg/main $ lvs -a vg LV VG Attr LSize Origin Pool Type Devices [fast] vg Cwi---C--- 64.00m linear /dev/loop1(0) main vg Cwi---C--- 128.00m [main_corig] [fast] cache main_corig(0) [main_corig] vg owi---C--- 128.00m linear /dev/loop0(0) $ lvchange -ay vg/main $ dmsetup ls vg-fast_cdata (253:4) vg-fast_cmeta (253:5) vg-main_corig (253:6) vg-main (253:24) vg-fast (253:3) $ dmsetup table vg-fast_cdata: 0 98304 linear 253:3 32768 vg-fast_cmeta: 0 32768 linear 253:3 0 vg-main_corig: 0 262144 linear 7:0 2048 vg-main: 0 262144 cache 253:5 253:4 253:6 128 2 metadata2 writethrough mq 0 vg-fast: 0 131072 linear 7:1 2048 $ lvchange -an vg/min $ lvconvert --splitcache vg/main $ lvs -a vg LV VG Attr LSize Type Devices fast vg -wi------- 64.00m linear /dev/loop1(0) main vg -wi------- 128.00m linear /dev/loop0(0)
* cleanup: move cast to det_t into MKDEV macroZdenek Kabelac2018-11-051-1/+1
|
* cov: add missing check for dm_strncpyZdenek Kabelac2018-11-031-1/+5
|
* cov: remove uneeded codeZdenek Kabelac2018-11-031-9/+0
| | | | Since clvmd was dropped this code become useless.
* cov: drop uneeded header filesZdenek Kabelac2018-10-151-1/+0
|
* filter: add config setting to skip scanning LVsDavid Teigland2018-08-302-0/+6
| | | | | | | | | | | devices/scan_lvs (default 1) determines whether lvm will scan LVs for layered PVs. The lvm behavior has always been to scan LVs, but it's rare for LVs to have layered PVs, and much more common for there to be many LVs that substantially slow down scanning with no benefit. This is implemented in the usable filter, and has the same effect as listing all LVs in the global_filter.
* mirror: fix splitmirrors for mirror typeZdenek Kabelac2018-08-071-0/+5
| | | | | | With improved mirror activation code --splitmirror issue poppedup since there was missing proper preload code and deactivation for splitted mirror leg.
View Lorry Controller Status