summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* remove unused set_preferred_duplicatesdev-dct-lvmetad-disable-3David Teigland2016-02-112-44/+0
|
* lvmcache: process duplicate PVs directlyDavid Teigland2016-02-113-122/+147
| | | | | | | | | | | | | | | | | | | | 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.
* lvmcache: improve duplicate PV handlingDavid Teigland2016-02-116-216/+374
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/strict_pv_device can be set to 1 which will disallow modifying a VG when it contains PVs with duplicate devices. Set to 0 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 with holders 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 It seems that if one dev has holders and the other doesn't, the dev with holders is more likely to be currently used by an active LV, in which case it should be preferred.
* lvmetad: disable when lvm1 metadata is createdDavid Teigland2016-02-111-0/+8
| | | | We could alternatively report an error and fail the command.
* lvmetad: remove client side altdev codeDavid Teigland2016-02-111-40/+2
| | | | | | This is no longer used since lvmetad no longer keeps track of alternate devices for duplicate PVs, but is simply disabled when duplicates appear.
* pvscan: repopulate and reenable disabled lvmetadDavid Teigland2016-02-113-1/+47
| | | | | | | | | | Other commands ignore lvmetad when it's disabled, but pvscan --cache is an exception since it is populating the lvmetad cache, not using the lvmetad cache. Have 'pvscan --cache' clear the disabled flag in lvmetad if, after scanning all devices, it found no lvm1 metadata and found no duplicate PVs.
* lvmetad: disable when duplicate PVs are seenDavid Teigland2016-02-111-152/+31
| | | | | | | | | | When duplicate PVs are detected, set the disabled flag so that commands will disable use of lvmetad. Remove the "altdev" logic that attempted to keep track of multiple devices for a single PV. It is no longer used since lvmetad is disabled in this case.
* pvscan: disable lvmetad if duplicate PVs are foundDavid Teigland2016-02-111-0/+5
|
* pvscan: disable lvmetad if lvm1 metadata is foundDavid Teigland2016-02-112-0/+30
|
* lvmetad: add disabled stateDavid Teigland2016-02-115-5/+138
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A global flag in lvmetad indicates it has been disabled. Other flags indicate the reason it was disabled. These flags can be queried using get_global_info. The lvmetactl debugging utility can set and clear the disabled flag in lvmetad. Nothing else sets the disabled flag yet. Commands check these flags after connecting to lvmetad. If the disabled flag is set, the command disables use of lvmetad (as it already does in other cases.) To test this feature: $ lvmetactl get_global_info response = "OK" global_invalid = 0 global_disable = 0 disable_reason = "none" token = "filter:3041577944" $ vgs (should report VGs from lvmetad) $ lvmetactl set_global_disable 1 $ lvmetactl get_global_info response = "OK" global_invalid = 0 global_disable = 1 disable_reason = "DIRECT" token = "filter:3041577944" $ vgs WARNING: Disabling use of lvmetad because the disable flag was set directly. (should report VGs without contacting lvmetad) $ lvmetactl set_global_disable 0 $ vgs (should report VGs from lvmetad)
* lvmetad: preemptively check and rescan in commandsDavid Teigland2016-02-116-27/+191
| | | | | | | | | | | | | | | | | | Move checking the lvmetad state, and the possible rescan, out of lvmetad_send() to the start of the command. Previously, the token mismatch and rescan would occur within lvmetad_send() for some other request. Now, the token mismatch is detected earlier, so the rescan can be done before the main command is in progress. Rescanning deep within the processing of another command will disturb the lvmcache state of that other command. A rescan already exists at the start of the command for the case where foreign VGs are going to be read. This same rescan is now also performed when there is an lvmetad token mismatch (from a changed global_filter).
* rename function read_vgname to read_vgsummaryDavid Teigland2016-02-114-11/+15
| | | | The name did not clearly represent what it does.
* lvmlockd: don't adopt locks from unused lmDavid Teigland2016-01-281-6/+10
| | | | | When built without dlm or sanlock support, don't attempt to adopt locks from that lm.
* post-releaseAlasdair G Kergon2016-01-254-2/+8
|
* pre-releasev2_02_141Alasdair G Kergon2016-01-254-5/+5
|
* tests: add pv-check-dev-size.shPeter Rajnoha2016-01-221-0/+44
|
* conf: add metadata/check_pv_device_sizesPeter Rajnoha2016-01-226-1/+25
|
* metadata: check PV dev size is not less than PV sizePeter Rajnoha2016-01-222-0/+35
|
* lvmcache: invalidate all cached dev sizes if all VGs got unlockedPeter Rajnoha2016-01-221-1/+3
|
* device: also cache device sizePeter Rajnoha2016-01-223-1/+35
| | | | | | | | | | | | | | | | Add "size" and "size_seqno" to struct device to cache device's size and also to control its lifetime - the cached value is valid as long as the global _dev_size_seqno is equal to the device's size_seqno, otherwise we need to get the size again and cache the new value. This patch also adds new dev_size_seqno_inc() fn for the appropriate parts of the code to increment current global value of _dev_size_seqno and hence to cause all currently cached values for device sizes to be invalidated. The device size is now cached because we're planning to reuse this information for further checks and we want to avoid checking it more than necessary to save resources.
* lvmlockd: remove noisy log_debugDavid Teigland2016-01-211-3/+1
| | | | | The debug message appeared even when lvmlockd was not used, and the lockd operation was simply being skipped.
* vgimportclone: fix VG name variable reference in error message after failed ↵Peter Rajnoha2016-01-211-1/+1
| | | | PV uuid change
* cleanup: add missing prototypeZdenek Kabelac2016-01-211-0/+1
| | | | | Commit 2304286f68debd4755b44fa8b779b762142bfada missed to add function prototype.
* toollib: restore command break supportZdenek Kabelac2016-01-212-0/+5
| | | | | | | Fix regression caused by c9f021de0b4d2c873ef5b97d17c602d0380359fd. This commit actually transfered real-action (e.g. device removal) into the next loop which has however missed to check for break. So add check for break also there.
* toollib: use cmd mempool for listZdenek Kabelac2016-01-212-1/+2
| | | | | | | When creating a list in 'context of command' - use proper mempool. vg->vgmem is mempool related to VG metadata - and can be eventually locked read-only when VG struct is shared.
* doc: change fsf addressZdenek Kabelac2016-01-21690-691/+691
| | | | | Hmm rpmlint suggest fsf is using a different address these days, so lets keep it up-to-date
* cleanup: join if/elseZdenek Kabelac2016-01-211-4/+1
|
* man: show hidden piecesZdenek Kabelac2016-01-212-4/+5
| | | | | | | | W: manual-page-warning /usr/share/man/man8/lvm.8.gz 491: warning: macro `_cdata',' not defined rpmlint actually notices we had few hidden word in man page. the line cannot start with apostrophe as it has then a different meaning.
* man: dmsetupZdenek Kabelac2016-01-212-2/+3
| | | | Typo in CMD_UDEVCREATECOOKIE macro name noticed by rpmlint.
* configure: fix configure to set proper use_blkid_wiping if autodetected as ↵Peter Rajnoha2016-01-214-3/+4
| | | | | | | | | | | | | disabled If not using explicit --enable-blkid-wiping/--disable-blkid-wiping configure option, the configure script tries to enable/disable blkid wiping feature automatically based on blkid library version found. The script incorrectly set default value for lvm.conf's allocation/use_blkid_wiping" setting to "1" (enabled) if proper blkid library version was not found or the version found was less than the minimum required. It should be set to "0" in this case.
* cleanup: reformat sentence about max sizesZdenek Kabelac2016-01-202-2/+2
| | | | | | | | | | | | | | | | | | | | | | The extent size must fits all blocks in 4294967295 sectors (in 512b units) this is 1/2 KiB less then 2TiB. So while previous statement 'suggested' 2TiB is still acceptable value, make it clear it's not. As now we support any multiples of 128KB as extent size - values like 2047G will still 'flow-in' otherwise the largest power-of-2 supported value is 1TiB. With 1TiB user needs 8388608 extents for 8EiB device. (FYI such device is already unusable with todays glibc-2.22.90-27) 4GiB extent size is currently the smallest extent size which allows a user to create 8EiB devices (with 2GiB it's less then 8EiB). TODO: lvm2 may possibly print amount of 'lost/unused space' on a PV, since using such ridiculously sized extent size may result in huge space being left unaccessible.
* cleanup: drop extra cmd passed argZdenek Kabelac2016-01-201-29/+26
| | | | Use vg->cmd when needed cmd struct.
* cleanup: relocate size assignZdenek Kabelac2016-01-201-6/+10
| | | | Directly set thin-pool size when thin data LV size changes.
* cleanup: adjust onceZdenek Kabelac2016-01-201-78/+73
|
* cleanup: update check functionZdenek Kabelac2016-01-201-26/+28
| | | | | | Use display_lvname(). Use lv_is_lockd_sanlock_lv(). Order 'error' checks ahead of 'ignore' ones.
* cleanup: shuffle check of thresholdZdenek Kabelac2016-01-201-4/+7
| | | | Check first threshold and then policy_amount.
* cleanup: use log_printZdenek Kabelac2016-01-201-5/+5
| | | | | Using log_print for ignoring message instead of log_warn. Add some missing '.'.
* activation: remote node check doesn't work yetAlasdair G Kergon2016-01-201-1/+1
|
* clvmd: Initialise udev.Alasdair G Kergon2016-01-202-1/+7
| | | | | | | Since commit 2fc126b00d83991c6a2f3ed9aa61457294a4c45e, the library code requires udev to be initialised for device scanning and clvmd can fail to find VGs if devices/external_device_info_source is set to "udev".
* activation: Add lv_is_active_remotely.Alasdair G Kergon2016-01-191-12/+37
|
* locking: Add node parameter to query_resource.Alasdair G Kergon2016-01-197-13/+19
|
* man: mention GPT id for LVM in pvcreate man pagePeter Rajnoha2016-01-191-1/+2
|
* report: fix off-by-one error when reporting LV segment's metadata device ↵Peter Rajnoha2016-01-191-1/+1
| | | | | | | extent count Commit a3f484f812bfb89063fbc25e378f34cacd50bf7d used "-1" two times by mistake for the extent count when reporting seg_metadata_le_ranges.
* report: add note about seg_pe_ranges and seg_le_ranges in -o helpPeter Rajnoha2016-01-191-1/+1
|
* report: add seg_le_ranges report fieldPeter Rajnoha2016-01-196-0/+34
|
* report: make devices, metadata_devices, seg_pe_ranges and ↵Peter Rajnoha2016-01-194-11/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | seg_metadata_le_ranges fields consistent There are two basic groups of fields for LV segment device reporting: - related to LV segment's devices: devices and seg_pe_ranges - related to LV segment's metadata devices: metadata_devices and seg_metadata_le_ranges The devices and metadata_devices report devices in this format: "device_name(extent_start)" The seg_pe_ranges and seg_metadata_le_ranges report devices in this format: "device_name:extent_start-extent_end" This patch reverts partly what commit 7f74a995029caa41ee3cf9aec0bd024a34bfd89a (v 2.02.140) introduced in this area - it added [] for hidden devices to mark them for all four fields mentioned above. We won't be marking hidden devices in devices and metadata_devices fields. The seg_metadata_le_ranges field will have hidden devices marked - it's new enough that we don't need to care about compatibility much yet. The seg_pe_ranges is old enough that we shouldn't be changing this one - so we're reverting to not marking hidden devices here. Instead, there's going to be a new field "seg_le_ranges" which is going to replace the seg_pe_ranges and it will mark hidden devices - this is going to be introduced in a patch later. So in the end we'll end up with: (LV segment's devices) devices field with "device_name(extent_start)" format, not marking hidden devices seg_pe_ranges field with "device_name:extent_start-extent_end" format, not marking hidden devices (deprecated, new seg_le_ranges should be used instead for standardized format) seg_le_ranges field with "device_name:extent_start-extent_end" format, marking hidden devices (LV segment's metadata devices) metadata_devices field with "device_name:extent_start-extent_end" format, not marking hidden devices seg_metadata_le_ranges field with "device_name:extent_start-extent_end" format, marking hidden devices Also, both seg_le_ranges and seg_metadata_le_ranges will honour the report/list_item_separator setting which can be used to configure the delimiter used for list items. So, to sum it up, we will recommend using the new seg_le_ranges and seg_metadata_le_ranges fields because they display devices with standard extent range format, they can mark hidden devices and they honour the report/list_item_separator setting. We'll be keeping devices,seg_pe_ranges and metadata_devices fields for compatibility.
* report: change _format_pvsegs to return list instead of plain string, change ↵Peter Rajnoha2016-01-195-89/+132
| | | | | | | | | | | | | | associated report fields from STR to STR_LIST The associated devices,metadata_devices,seg_pe_ranges and seg_metadata_le_ranges are reported as genuine string lists now. This allows for using the items separately in -S|--select (so searching for subsets etc.) and also it allows for configuring the separator using report/list_item_separator which may be useful in scripts (however, we'll enable this only for seg_le_metadata_ranges and not for devices,seg_pe_ranges and seg_metadata_devices for compatibility reasons - see following patch).
* refactor: add 'delimiter' variable for non-default delimiter when reporting ↵Peter Rajnoha2016-01-191-14/+15
| | | | string list
* lvconvert: disallow test mode in shared VGDavid Teigland2016-01-181-0/+7
| | | | | | until test mode can be checked in all the necessary locations related to lvmlockd to prevent making actual changes.
* toollib: add comment about missing deviceDavid Teigland2016-01-181-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a comment in _process_pvs_in_vg() to document the place where there have been problems with processing PVs twice. For a while we had a hacky workaround here where we'd skip processing a PV if its device wasn't found in all_devices (and !is_missing_pv since we want to process PVs with missing devices.). That workaround was removed in commit 5cd4d46f because it was no longer needed. The workaround had originally been needed to prevent a device from being processed twice when the PV had no MDAs -- it would be processed once in its real VG and then the workaround would prevent it from being processed a second time in the orphan VG. Wrongly appearing as an orphan likely happened because lvmcache would consider the no-MDA PV an orphan unless the real VG holding that PV was also in lvmcache. This issue is also mentioned in pvchange where holding the global lock allows VGs to remain in lvmcache so PVs with 0 mdas are not considered orphans. The workaround in _process_pvs_in_vg() was originally intended for reporting commands, not for pvchange. But, it was accidentally helping pvchange also because the method described by the pvchange global lock comment had been subverted by commit 80f4b4b8. Commit 80f4b4b8 was found to be unnecessary, and was reverted in commit e710bac0. This restored the intended global lock lvmcache effect to pvchange, and it no longer relied on the workaround in toollib.
View Lorry Controller Status