summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* tests: use yes option in pv-ext-flagsdev-dct-pvcreate-23David Teigland2016-02-171-4/+4
| | | | | pvcreate|pvremove have previously used "-ff -y" to fully override cases where a PV is used by a VG.
* metadata: add fixme about code used only by liblvmDavid Teigland2016-02-171-0/+11
|
* pvremove: use common toollib processing codeDavid Teigland2016-02-174-58/+274
| | | | | Use the new pvcreate_each_device() function from toollib.
* toollib: remove unsed pvcreate params functionDavid Teigland2016-02-172-117/+0
| | | | | which has been replaced by an equivalent pvcreate_each params function.
* liblvm: replace pvcreate_single with pvcreate_volDavid Teigland2016-02-173-25/+10
| | | | And remove the pvcreate_single wrapper.
* vgcreate: use the common toollib pv createDavid Teigland2016-02-175-39/+86
| | | | | | | | | | | | | | | | | | | | | | | | | | Use the new pvcreate_each_device() function from toollib, previously added for pvcreate, in place of the old pvcreate_vol(). This also requires shifting the location where the lock is acquired for the new VG name. The lock for the new VG is supposed to be acquired before pvcreate. This means splitting the vg_lock_newname() out of vg_create(), and calling vg_lock_newname() directly before pvcreate, and then calling the remainder of vg_create() after pvcreate. The new function vg_lock_and_create() now does vg_lock_newname() + vg_create(), like the previous version of vg_create(). The lock on the new VG name is released before the pvcreate and reacquired after the pvcreate because pvcreate needs to reset lvmcache, which doesn't work when locks are held. An exception could likely be made for the new VG name lock, which would allow vgcreate to hold the new VG name lock across the pvcreate step.
* vgextend: use the common toollib pv createDavid Teigland2016-02-171-34/+55
|
* pvcreate: use the common toollib pv createDavid Teigland2016-02-171-51/+92
|
* toollib: add two phase pv processing codeDavid Teigland2016-02-1713-32/+1096
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is common code for handling PV create/remove that can be shared by pvcreate/vgcreate/vgextend/pvremove. This does not change any commands to use the new code. - Pull out the hidden equivalent of process_each_pv into an actual top level process_each_pv. - Pull the prompts to the top level, and do not run any prompts while locks are held. The orphan lock is reacquired after any prompts are done, and the devices being created are checked for any change made while the lock was not held. Previously, pvcreate_vol() was the shared function for creating a PV for pvcreate, vgcreate, vgextend. Now, it will be toollib function pvcreate_each_device(). pvcreate_vol() was called effectively as a helper, from within vgcreate and vgextend code paths. pvcreate_each_device() will be called at the same level as other process_each functions. One of the main problems with pvcreate_vol() is that it included a hidden equivalent of process_each_pv for each device being created: pvcreate_vol() -> _pvcreate_check() -> find_pv_by_name() -> get_pvs() -> get_pvs_internal() -> _get_pvs() -> get_vgids() -> /* equivalent to process_each_pv */ dm_list_iterate_items(vgids) vg = vg_read_internal() dm_list_iterate_items(&vg->pvs) pvcreate_each_device() reorganizes the code so that each-VG-each-PV loop is done once, and uses the standard process_each_pv function at the top level of the function.
* vgconvert: refactor to avoid pvcreate codeDavid Teigland2016-02-173-42/+80
| | | | | | | | This uses the vg->pv_write_list in place of the vg->pvs_to_write list, and eliminates the use of pvcreate_params. The label remove and zeroing steps are shifted out of vg_write() to the higher level like pvcreate will do.
* metadata: use pv_write_list for _check_old_pv_ext_for_vgDavid Teigland2016-02-171-10/+9
| | | | | | The _check_old_pv_ext_for_vg() function only needs to do pv_write(), so it can use the simpler pv_list structs on the pv_write_list.
* metadata: refactor part of add_pv_to_vgDavid Teigland2016-02-172-22/+16
| | | | | | This shifts the use of the 'pv_to_write' struct and the 'pvcreate_params' struct to the one caller of add_pv_to_vg, which is made static.
* vg_write: add list of pvs to writeDavid Teigland2016-02-173-2/+12
| | | | | | | | | | The vg->pv_write_list contains pv_list structs for which vg_write() should call pv_write(). The new list will replace vg->pvs_to_write that contains vg_to_create structs which are used to perform higher-level pvcreate-related operations. The higher level pvcreate operations will be moved out of vg_write() to higher levels.
* man: fix list of restricted LV name suffixesPeter Rajnoha2016-02-171-1/+1
|
* metadata: add missing _repair_inconsinstent_vg call during PV ext repairPeter Rajnoha2016-02-171-4/+15
|
* metadata: do not repair missing PV_EXT_USED flag for PVs belonging to foreign VGPeter Rajnoha2016-02-171-51/+58
| | | | | | | | The host that owns foreign VGs is responsible for fixing up PV_EXT_USED flag - the same already applies to repairing any inconsistent VG. This patch also moves the iteration over vg->pvs inside _check_or_repair_pv_ext fn - it's cleaner this way.
* refactor: add common _is_foreign_vg fnPeter Rajnoha2016-02-161-2/+7
|
* pv: use pv->fmt to check for fake PVs, not pv->vgPeter Rajnoha2016-02-151-1/+1
| | | | | | | | pv->vg is not set yet during pvcreate processing. Use pv->fmt instead to check for these fake PVs (all normal PVs have format defined, devices which are not PVs don't have this set). This fixes commit 0000db7f98a07aa31c5b1cf13938b612e7f2821b.
* cleanup: make the message about marked PVs consistent with the othersPeter Rajnoha2016-02-151-1/+1
|
* toollib: skip PV if system ID is used and PV marked as used but metadata missingPeter Rajnoha2016-02-152-0/+7
| | | | | | | | | | | If we know that a PV belongs to some VG and we're missing metadata (because we have only those PV(s) from VG present in the system that don't have metadata areas), we should skip such PV when processing under system ID. This is because we know that the PV belongs to some VG, but we really can't decide whether it matches system ID unless the VG metadata is present again.
* pv: mark fake PVs as not usedPeter Rajnoha2016-02-151-0/+3
| | | | | | Some of the PVs are not even orphan PVs - they're fake PVs - this can happen if we're listing all devices with "pvs -a". Such PV must not be marked as used.
* cleanup: use is_used_pv fn to detect whether PV is in use while reporting ↵Peter Rajnoha2016-02-151-13/+5
| | | | pv_free field
* WHATS_NEW: PV_EXT_USED flag and relatedPeter Rajnoha2016-02-151-0/+5
|
* tests: fix tests checking pv_attr - there's a new bit nowPeter Rajnoha2016-02-152-5/+8
|
* tests: add pv-ext-flags.sh testPeter Rajnoha2016-02-151-0/+163
| | | | | Testing PV extension flags. Currently, there's only one PV extension flag present - the PV_EXT_USED flag (marking PV as used in a VG).
* vg: automatically update to newest PV ext version during vg_writePeter Rajnoha2016-02-151-0/+58
|
* format: format_text: add pv_needs_rewrite to format_handler and implemention ↵Peter Rajnoha2016-02-152-0/+31
| | | | for format_text
* report: identify used PVs in pv_attr field with 'u' charPeter Rajnoha2016-02-152-2/+5
|
* report: always display 0 for pv_free field if we don't have any mda and PV ↵Peter Rajnoha2016-02-151-0/+14
| | | | is marked as used at the same time
* backup: backup_restore_vg: register PVs that need writing via ↵Peter Rajnoha2016-02-153-89/+123
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | vg->pvs_to_write list The backup_restore_vg is used directly for restoring the VG from backup. It's also used to do the VG conversions from one metadata format to another which means vgconvert calls backup_restore_vg too. When restoring VG from backup, we need to rewrite/write PV headers as PVs may have been orphans before and now they're becoming part of some VG - we need to write the PV_EXT_USED flag at least. When using the backup_restore_vg for vgconvert, we need to write completely new PV header in different format. Avoid the special "pv_write" call and handling that was used before this patch in vgconvert (vgconvert_single function to be more precise) and reuse existing internal interface to register PV header for writing (or rewriting) via vg->pvs_to_write list instead like we do it elsewhere in the code. This patch also resolves a problem in which PV headers with target format were written in the vgconvert_single fn as orphans and VG metadata were added later on - this was a tiny hack actually. We can't do this now - we need to write the PV as belonging to a VG because otherwise the PV_EXT_USED flag won't be written properly (if the PV header is written as orphan, the PV_EXT_USED is set to 0, of course, even though metadata are attached later). So this patch removes this tiny inconsistency which was passing just fine before because we didn't have any relation to the VG in PV header before. Now we have the PV_EXT_USED flag which says the "PV is used in some VG".
* metadata: _vg_read: check if PV_EXT_USED flag is set correctly for ↵Peter Rajnoha2016-02-151-1/+56
| | | | | | | | | | | | | | | | | non-orphan PVs and do a repair if needed The same check as we already do for orphan PVs, just the other way round now: if the PV is surely part of some VG and any PV the VG contains does not have the PV_EXT_USED flag set, repair it. For example - /dev/sda here is in VG vg and it's incorrectly not marked as used by PV_EXT_USED flag: pvs --binary -o pv_ext_vsn,pv_in_use WARNING: Volume Group vg is not consistent. WARNING: Repairing Physical Volume /dev/sda that is in Volume Group vg but not marked as used. PV VG Fmt Attr PSize PFree ExtVsn PInUse /dev/sda vg lvm2 a-- 124.00m 124.00m 2 1
* report: add pv_ext_vsn field to display PV header extension version usedPeter Rajnoha2016-02-153-0/+20
| | | | | | | | | | For example: $ pvs -o pv_name,vg_name,pv_ext_vsn,pv_in_use PV VG ExtVsn InUse /dev/sda 2 /dev/sdb vg 2 used /dev/vda2 fedora 1 used
* metadata: check for PV extension version before doing any checks on PV ↵Peter Rajnoha2016-02-151-0/+12
| | | | | | | | | | | | extension flags PV header extension versions: 0 - the original PV without any extensions 1 - bootloader area support added 2 - PV_EXT_USED flag support added So do the associated checks related to PV_EXT_USED flag only if PV header extension found is of version 2 and higher.
* metadata: _vg_read: check if PV_EXT_USED flag is set correctly for orphan ↵Peter Rajnoha2016-02-152-16/+81
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PVs and do a repair if needed If we know that the PV is orphan, meaning there's at least one MDA on that PV which does not reference any VG and at the same time there's PV_EXT_USED flag set, we're certainly in an inconsistent state and we need to fix this. For example, such situation can happen during vgremove/vgreduce if we removed/reduced the VG, but we haven't written PV headers yet because vgremove stopped abruptly for whatever reason just before writing new PV headers with updated state, including PV extension flags (and so the PV_EXT_USED flag). However, in case the PV has no MDAs at all, we can't double-check whether the PV_EXT_USED is correct or not - if that PV is marked as used, it's either: - really used (but other disks with MDAs are missing) - or the error state as described above is hit User needs to overwrite the PV header directly if it's really clear the PV having no MDAs does not belong to any VG and at the same time it's still marked as being in use (pvcreate -ff <dev_name> will fix this). For example - /dev/sda here has 1 MDA, orphan and is incorrectly marked with PV_EXT_USED flag: $ pvs --binary -o+pv_in_use WARNING: Found inconsistent standalone Physical Volumes. WARNING: Repairing flag incorrectly marking Physical Volume /dev/sda as used. PV VG Fmt Attr PSize PFree InUse /dev/sda lvm2 --- 128.00m 128.00m 0
* report: add pv_in_use field to display whether PV is in use or notPeter Rajnoha2016-02-154-0/+17
| | | | | | | | | | | | | | For example: $ pvs -o pv_name,vg_name,pv_in_use PV VG InUse /dev/sda vg used /dev/sdb /dev/sdc used (sda is part of vg - it's used sdb is not part of vg - it's not used sdc is part of vg, but MDAs missing - it's used)
* pv: _pvcreate_write: do label removal and zeroing only if creating a new PVPeter Rajnoha2016-02-151-16/+17
|
* pv: issue different message of different type when we're overwriting ↵Peter Rajnoha2016-02-152-1/+8
| | | | | | | | | | | | | | | | | | | | | | existing PV header instead of creating a new one Scenario: $ pvcreate /dev/sda Physical volume "/dev/sda" successfully created We're adding the PV to a VG. Before this patch: $ vgcreate vg /dev/sda Physical volume "/dev/sda" successfully created Volume group "vg" successfully created With this path applied: $ vgcreate vg /dev/sda Volume group "vg" successfully created ...and verbose log containing: "Physical volume "/dev/sda" successfully written"
* pv: check for the PV_EXT_USED flag and deny ↵Peter Rajnoha2016-02-153-10/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | pvcreate/pvchange/pvremove/vgcreate on such PV (unless forced) Make sure we won't use a PV that is already marked as used. Normally, VG metadata would stop us from doing that, but we can run into a situation where such metadata is missing because PVs with MDAs are missing and the PVs left are the ones with 0 MDAs. (/dev/sda in this example has 0 MDAs and it belongs to a VG, but other PVs with MDA are missing) $ pvs -o pv_name,pv_mda_count /dev/sda PV #PMda /dev/sda 0 $ pvcreate /dev/sda PV '/dev/sda' is marked as belonging to a VG but its metadata is missing. Can't initialize PV '/dev/sda' without -ff. $ pvchange -u /dev/sda PV '/dev/sda' is marked as belonging to a VG but its metadata is missing. Can't change PV '/dev/sda' without -ff. Physical volume /dev/sda not changed 0 physical volumes changed / 1 physical volume not changed $ pvremove /dev/sda PV '/dev/sda' is marked as belonging to a VG but its metadata is missing. (If you are certain you need pvremove, then confirm by using --force twice.) $ vgcreate vg /dev/sda Physical volume '/dev/sda' is marked as belonging to a VG but its metadata is missing. Unable to add physical volume '/dev/sda' to volume group 'vg'.
* pv: format-text: store PV_EXT_USED flag if PV is used and unset it otherwisePeter Rajnoha2016-02-151-0/+18
| | | | | When adding a PV to VG, set the PV_EXT_USED flag in PV header and vice versa - if the PV is no longer in a VG, unset the flag.
* metadata: schedule PV for header rewrite if adding a PV to VG or restoring VGPeter Rajnoha2016-02-152-1/+12
| | | | | When adding PV to VG, we need to rewrite PV header as there's a flip in PV_EXT_USED flag. The same applies if we're restoring VG from backup.
* metadata: add_pv_to_vg: add 'new_pv' arg to state if the PV is about to be ↵Peter Rajnoha2016-02-152-5/+9
| | | | created
* pv: add is_used_pv fnPeter Rajnoha2016-02-152-0/+22
|
* lvmcache/lvmetad: cache PV extension versionPeter Rajnoha2016-02-156-0/+19
| | | | Store PV extension version in lvmcache/lvmetad for use throughout the code.
* lvmcache/lvmetad: cache PV extension flagsPeter Rajnoha2016-02-156-1/+23
| | | | Store PV extension flags in lvmcache/lvmetad for use throughout the code.
* metadata: introduce PV_EXT_USED flag and bump PV_HEADER_EXTENSION_VSNPeter Rajnoha2016-02-152-1/+9
|
* format: add FMT_PV_FLAGS to indicate format supports PV flagsPeter Rajnoha2016-02-152-1/+2
|
* refactor: rename struct pv_to_create --> struct pv_to_writePeter Rajnoha2016-02-153-21/+21
| | | | | | We'll use this struct in subsequent patches for PVs which should be rewritten, not just created. So rename struct pv_to_create to struct pv_to_write for clarity.
* post-releaseAlasdair G Kergon2016-02-154-2/+8
|
* pre-releasev2_02_142Alasdair G Kergon2016-02-154-8/+9
|
* man: pvresize: remove old comment about inability to resize PV with more mdasPeter Rajnoha2016-02-122-2/+27
|
View Lorry Controller Status