8.132. lvm2

Bug Fixes

BZ#857064

Previously, proper handling of the "-A" ("--activevolumegroups") option for the vgdisplay utility was missing. Consequently, vgdisplay displayed inactive Volume Groups (VGs) even though "-A" was used displaying only active VGs, defined here as a VG that contains at least one active Logical Volume (LV). This update adds proper handling of "-A" for vgdisplay. Now, when using the "vgdisplay -A" command ("vgdisplay --activevolumegroups"), only active VGs are displayed.

BZ#878948

Prior to this update, concurrent activation of the same Logical Volume (LV) caused a race condition and the following error message to be returned:

Device or resource busy

With this update, concurrent activation and deactivation of LVs is prohibited and locking is performed, so that operations are now processed sequentially. As a result, the "lvchange -ay $lv" and "lvchange -an $lv" commands no longer cause this bug if issued concurrently.

BZ#892991

When using the lvmetad daemon, the dmeventd daemon took into consideration metadata that was not up-to-date at a time of a RAID LV repair. Based on the outdated information, the repair did not proceed. With this update, the repair code forces a metadata refresh for the Physical Volumes (PVs) that host the RAID volume, and automatic RAID volume repair using dmeventd and manual repair using "lvconvert --repair" now work as expected regardless of lvmetad being enabled or not.

BZ#905063

Previously, RAID LVs either activated or failed to activate depending on how badly their redundancy was compromised. A new "degraded" activation mode has been added to the lvchange and vgchange utilities to better handle activation of incomplete RAID LVs that still have sufficient level of redundancy. This activation mode is now used by default.

BZ#989174

If the lvm2app lvm_vg_reduce() function was called to remove most but not all physical volumes (PV) from a Volume Group (VG), it often destroyed the VG completely. Moreover, no error message was generated. With this update, lvm_vg_reduce() gains some additional validation, and lvm2app lvm_vg_reduce() now works as expected.

BZ#995157

If the user attempted to assign a clustered attribute to a Volume Group (VG) by running the "vgchange -cy VG" command, and the system was not yet properly configured for it, the user was not prompted to confirm the change. In addition, any subsequent LVM command skipped such clustered VG if system was not specifically configured for it. The bug has been fixed, and the lvm command now prompts and warns the user about enabling clustered attribute on VG provided that the clvmd daemon or cluster is not running. The user can also override this prompt by supplying the "--yes" argument.

BZ#1016218

Previously, Logical Volume Management (LVM) utilities tried to connect to the lvmetad daemon even though the utilities were run with the "--sysinit" option denoting the early system initialization. Nevertheless, lvmetad did not have to be running yet, and thus error messages were issued multiple times during system initialization. This update adds a check whether a LVM utility is running during early system initialization by checking the use of the "--sysinit" option. Now, if lvmetad socket is not present in early system initialization when using "--sysinit", LVM utilities automatically fallback to non-lvmetad mode silently.

BZ#1024347

When converting existing Logical Volume (LV) to a thin-pool LV, the lvm utility needed to open the volume temporarily to be initialized with zeroes at its start. However, this initialization step caused the WATCH udev rule to trigger. Consequently, all udev rules were reevaluated based on the WATCH rule, which caused subsequent scanning of the device for changes and LVM could try to close the device in parallel, which would end up with an error. With this update, lvm uses proper flags for temporary volumes which are used during conversions as intermediate step; these flags direct the udev utility to avoid setting the WATCH rule or initiate any scanning on such devices until they are properly initialized.

BZ#1049296

The lvm utility uses lock files to prevent incompatible operations from running simultaneously. Prior to this update, when forking sub-processes, such as the fsadm utility using the "lvresize -r" command, lvm could incorrectly drop these locks and incorrectly permit commands to run in parallel. This update fixes the exec_cmd() function responsible for the wrong behavior. Now, running "lvresize -r" in parallel with other lvm commands works correctly, and all Logical Volumes (LVs) are correctly resized.

BZ#1084157

Previously, the lvm2-cluster subpackage had a requirement of the same or higher version of the lvm2 package, but did not work unless the versions were exactly the same. As a consequence, lvm2-cluster did not work correctly. With this update, lvm2 and all its subpackages define strict version dependencies among themselves, including a dependency between the lvm2-cluster subpackage and the lvm2 packages. This way the lvm2-cluster subpackage always depends on the right lvm2 packages and incompatible versions of lvm2-cluster cannot thus be installed at the same time.

BZ#1085553

Previously, information about Physical Volume (PV) availability could be out of date. Consequently, the status string in the output of the lvs command for a RAID LV could be different in identical situations depending on whether lvmetad was used or not. The dmeventd volume monitoring daemon now updates PV information in lvmetad for devices participating in a RAID array that have encountered an error. As a result, if dmeventd is active, which is recommended regardless of this bug, the lvs output is the same in both lvmetad and non-lvmetad cases. Note that when dmeventd is disabled, it is recommended to run the "lvscan --cache" command for faulty RAID arrays to ensure up-to-date information in the lvs output.

BZ#1089229

The device-mapper packages are merged inside lvm2. However, prior dependencies were not strict, and the user could update device-mapper without updating lvm2, leading to a version mismatch. The lvm2 packages and all their subpackages now define strict version dependencies among themselves, so that after updating any of these lvm2 subpackages the user receives consistent update of the main lvm2 packages as well. As there is only one debuginfo package for lvm2 and all its subpackages, this fix also resolves the problem of the user receiving unusable debuginfo if one of the subpackages has been updated to a newer version.

BZ#1113539

If a persistent filter was used, /etc/lvm/cache/.cache, and a new Physical Volume (PV) was created, filters were not reevaluated to acquire any changes that could correctly prevent the PV create process to succeed. Consequently, without up-to-date information, LVM could overwrite existing foreign signatures. With this update, filters are always reevaluated before PV creation. In addition, if a change is done outside the lvm utility after last filter evaluation, these changes are now properly considered before PV creation.

BZ#1121216

When a RAID logical volume mirror was created and then one of the Physical Volume (PV) devices was removed, the "lvconvert --repair" command refused to restore the mirror leg with a PV that was already used partly by another LV. An upstream patch has been applied to fix this bug, and "lvconvert --repair" now accepts a few additional arguments including "--alloc" and "--force", and the mirror leg with a PV is now correctly restored using "lvconvert --repair".

BZ#1124766

Previously, there was an incorrect check of the cluster status of non-clustered snapshot origin Logical Volume (LV) before local deactivation. Consequently, attempts to exclusively deactivate already inactive Logical Volume (LV) locally on a single host (non-clustered) led to the following incorrect error messages being issued:

• Cannot deactivate remotely exclusive device locally. (newer versions)
  

• Cannot deactivate <lv name> locally. (older versions)
  

With this update, the check is performed before local deactivation to properly check only clustered LVs, and misleading error messages no longer occur.

BZ#1125154

Previously, the check handling the vgcreate utility while using disks for new Volume Group (VG) for which Physical Volumes (PVs) had not yet been created was incorrect. Consequently, vgcreate several times created PVs with the following misleading error message:

	
Physical volume <pv name> not found

The check for existing PVs has been fixed in the vgcreate code not to issue any errors if the PV cannot be found, and is thus created by vgcreate.

BZ#1129311

Due to an incorrect persistent filter, /etc/lvm/cache/.cache, generated when using the pvcreate utility, pvcreate tried to refresh cache if MD filter was switched on. As a consequence, if the pvcreate utility was run against a device with an existing MD signature, signature detected and wiped, the device could continue to be filtered out, as if the signature had not been deleted. This update changes the filters, and the device is now correctly made available for immediate use after the signature is deleted.

BZ#1132547

When the volume_list configuration parameter was set to not allow activation of thin-pool and then a thin volume was created, the transaction_id parameter was moved forward, but the kernel target was not notified about it. As a consequence, future activation failures reporting a transaction ID mismatch could occur. The lvm2 metadata has been fixed, and the lvm utility no longer incorrectly expects that messages were sent to the kernel's thin pool driver when such interaction is forbidden due to activation of volume_list parameters.

BZ#1035871

The lvm2 utility calculates maximum space that a snapshot can use and restricts the user-supplied snapshot size, so that it is never larger than the maximum usable space. However, lvm2 previously calculated snapshot space incorrectly, and under certain circumstances could allocate a snapshot that was too small. As a consequence, when such a snapshot was filled up, it overflowed with modified blocks from origin device, and all data in the snapshot became lost. With this update, lvm2 respects the size specified by the user, and the snapshot no longer overflows.

BZ#1020877

In the cluster, the local activation of a volume was automatically converted into exclusive activation if the volume supported only exclusive mode. However this could cause that local activation activated the volume on a different (non-local) node in the cluster. With this update, automatic conversion has been fixed, and local activation is now converted into local-exclusive activation. In addition, if local activation is successful, the volume is now locally (and exclusively) active.

Enhancements

BZ#669111

With this update, a new command-line option, "--atomic", has been added to the pvmove utility. The "--atomic" option causes all identified Logical Volumes (LV) to be moved together. The commit that places each LV on its final destination is not performed unless the last LV is processed. Thus, the "pvmove abort" command ensures that all affected LVs remain on the source device.

BZ#815680

This update adds two manual pages to cover the Logical Volume (LVM) topics of thin-provisioning and caching, also called "tiered storage". These new man pages are lvmthin(7) and lvmcache(7).

BZ#821932

New reporting fields for each attribute from the original "lv_attr" field have been added. This update provides more descriptive and also more extensive information on logical volumes (LV) attributes. In addition, the attributes encoded in the original "lv_attr" field can now be reported independently.

BZ#829920

The "%FREE" argument can now be used to create RAID logical volumes (LVs); "%FREE" is used with the "-l" ("--extents") argument of the lvcreate command. The resulting size is approximately equal to the desired percentage including adjustments that need to be made for RAID metadata areas.

BZ#880395

With this update, the latest lvm2app library gains new functions to customize the parameters used to create Physical Volumes (PV), namely size, PV metadata copies, PV metadata size, data alignment and data alignment offset, and zeroing.

BZ#986687

With this update, the user is able to create Logical Volume Management (LVM) configuration profiles that contain settings related to LVM reporting. The user can apply these settings per each LVM command simply by using a the following schema: "<lvm command> --command_profile <profile_name>". Now, users are able to define LVM report formatting and settings for each usecase needed.

BZ#997223

This update adds support for erasing detected signatures on newly created Logical Volumes (LVs). When creating a new LV and a signature is detected, Logical Volume Management (LVM) tries to erase the signature first before properly activating the new LV. A prompt with a question has also been added for the user:

WARNING: <signature name> signature detected on <device name>. Wipe it? [y/n]

This question confirms the deletion of the signature. In addition, a new lvm.conf option "allocation/wipe_signatures_when_zeroing_new_lvs" has been enabled by default to enable or disable this feature.

BZ#1112551

This update provides criteria-based Logical Volume Management (LVM) reporting by adding the new "-S" ("--select SelectionCriteria") option to LVM reporting commands: pvs, vgs, lvs, pvdisplay, vgdisplay, lvdisplay, and lvm devtypes. SelectionCriteria are criteria constructed by using reporting field names, restricting field values by using comparison operators and creating more complex criteria by using grouping and logical operators.

BZ#951600

A new command-line parameter, "--readonly", has been added to Logical Volume Management (LVM) commands that report the state of Logical Volumes (LVs), Volume Groups (VGs) or Physical Volumes (PVs). The parameter uses a special read-only mode that accesses on-disk metadata without needing locks.

BZ#1122698

Logical Volume Management (LVM) includes considerable improvements to the calculation of an appropriate amount of space to allocate when using percentages in commands such as "lvresize -l+50%FREE". The new behavior strives to be more intuitive; sizes specified are treated either as relating to Logical Extents or to Physical Extents as appropriate, and the new logical size desired for the Logical Volume (LV) is calculated. Rounding is then performed to make sure any parallel stripes or mirror legs are the same size.

BZ#1127451

This update adds new "lv_layout" and "lv_role" Logical Volume Management (LVM) reporting fields. These new fields have been created as part of decoupling existing bits in the "lv_attr" reporting field into separate reporting fields. This separate form is more readable as LVM reports values in full words instead of single characters. It also better suits LVM report output handling in scripts as well as using these new fields within selection criteria (the new "--select" lvm command option).

For more information, see also BZ#1112551 and BZ#821932.

BZ#1130168

With this update, the dmsetup utility gains a new flag, "--deferred". If specified and the device is open, the flag schedules the device to be deleted later after being closed.