Bug 821932
Summary: | Provide reporting fields to access each attribute individually | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Alasdair Kergon <agk> |
Component: | lvm2 | Assignee: | Peter Rajnoha <prajnoha> |
lvm2 sub component: | Displaying and Reporting (RHEL6) | QA Contact: | Cluster QE <mspqa-list> |
Status: | CLOSED ERRATA | Docs Contact: | |
Severity: | low | ||
Priority: | medium | CC: | agk, bmarzins, bmr, cmarthal, dwysocha, heinzm, jbrassow, jonathan, lvm-team, msnitzer, prajnoha, prockai, thornber, zkabelac |
Version: | 6.5 | Keywords: | FutureFeature |
Target Milestone: | rc | ||
Target Release: | 6.5 | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Fixed In Version: | lvm2-2.02.107-2.el6 | Doc Type: | Enhancement |
Doc Text: |
Feature:
New reporting fields for each attribute from original lv_attr field and more descriptive and also more extensive information if possible using these new fields.
Reason:
The lv_attr field tries to encode the information in a very condensed way. This format is useful for quick overview of LV's attributes, but it's neither practical for use in scripts nor is it descriptive. Also, using the original lv_attr field for selection criteria (the --select lvm command option, see also bz #1112551) is impractical. To resolve these problems and to make it easier for users, the attributes encoded in the original lv_attr field can now be reported independently while values used in these new fields are descriptive words.
Result:
There are new LVM reporting fields:
LV related:
lv_layout, lv_role, lv_initial_image_sync, lv_image_synced, lv_merging, lv_converting, lv_allocation_policy, lv_allocation_locked, lv_fixed_minor,
lv_merge_failed, lv_snapshot_invalid, lv_health_status, lv_skip_activation, lv_active_locally, lv_active_remotely, lv_active_exclusively, lv_permissions, lv_suspended, lv_live_table, lv_inactive_table, lv_device_open
PV related:
pv_allocatable, pv_exported, pv_missing
VG related:
vg_permissions, vg_extendable, vg_exported, vg_partial, vg_allocation_policy, vg_clustered
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2014-10-14 08:23:00 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 1002699 |
Description
Alasdair Kergon
2012-05-15 19:13:21 UTC
I don't think there is added value in just reporting values as shortcut letters. I'd prefer here output like this: lvs -o volume_health returns [partial|refresh_needed|mismatches_exist|....] so it gives fully understandable result where user doesn't need to look into the manpage every time he wants to really understand what the value mean... Absolutely! ...suitable for -S/--select for use in selection clauses. I'll have a look at this... We've added these new fields to access the attributes individually: Logical Volume Fields --------------------- lv_volume_type - LV volume type. lv_initial_image_sync - Set if mirror/RAID images underwent initial resynchronization. lv_image_synced - Set if mirror/RAID image is synchronized. lv_merging - Set if snapshot LV is being merged to origin. lv_converting - Set if LV is being converted. lv_allocation_policy - LV allocation policy. lv_allocation_locked - Set if LV is locked against allocation changes. lv_fixed_minor - Set if LV has fixed minor number assigned. lv_merge_failed - Set if snapshot merge failed. lv_snapshot_invalid - Set if snapshot LV is invalid. lv_target_type - Kernel target type the LV is related to. lv_health_status - LV health status. lv_skip_activation - Set if LV is skipped on activation. lv_active_locally - Set if the LV is active locally. lv_active_remotely - Set if the LV is active remotely. lv_active_exclusively - Set if the LV is active exclusively. Logical Volume Device Fields ---------------------------- lv_permissions - LV permissions. lv_suspended - Set if LV is suspended. lv_live_table - Set if LV has live table present. lv_inactive_table - Set if LV has inactive table present. lv_device_open - Set if LV device is open. Physical Volume Fields ---------------------- pv_allocatable - Set if this device can be used for allocation. pv_exported - Set if this device is exported. pv_missing - Set if this device is missing in system. Volume Group Fields ------------------- vg_attr - Various attributes - see man page. vg_permissions - VG permissions. vg_extendable - Set if VG is extendable. vg_exported - Set if VG is exported. vg_partial - Set if VG is partial. vg_allocation_policy - VG allocation policy. vg_clustered - Set if VG is clustered. There are two which still need looking at: lv_kernel_target_type and lv_volume_type (mainly to include combinations where an LV may be of two or more times at the same time - e.g. thin-snapshot where it's possible to have thin volume used as origin and snapshot at the same time). I'm moving this to POST now as most fields should be OK. As for the lv_volume_type and lv_kernel_target_type mentioned above - we'll enhance these two within next update - that needs more thorough look. All of the above commands have been added to the regression tests and have been verified to "work" (with the exception of lv_volume_type). Continuing to go thought and actually verify whether or not the information reported is indeed valid. I went through all of these and tried to set up a case where the report would be something meaningful. The two I have questions on are lv_merging and lv_merge_failed. I couldn't get them to report "on" during a mirror conversion or a failed merge. Logical Volume Fields --------------------- lv_volume_type GOOD Reports: "mirror" ( REGRESSION IN CURRENT BUILD ) lv_initial_image_sync GOOD Reports: "initial image sync" lv_image_synced GOOD Reports: "image synced" lv_merging GOOD Reports: "merging" lv_converting BAD Reports: nothing while converting to a mirror lv_allocation_policy GOOD Reports: "inherit" or "anywhere" lv_allocation_locked GOOD Reports: "allocation locked" lv_fixed_minor GOOD Reports: "fixed minor" lv_merge_failed BAD Reports: "unknown" after a failed merge attempt lv_snapshot_invalid GOOD Reports: "snapshot invalid" lv_target_type CURRENTLY UNDEFINED lv_health_status GOOD Reports: "partial" lv_skip_activation GOOD Reports: "skip activation" lv_active_locally GOOD Reports: "active locally" lv_active_remotely GOOD Reports: "unknown" or "active remotely" lv_active_exclusively GOOD Reports: "active exclusively" Logical Volume Device Fields ---------------------------- lv_permissions GOOD Reports: "writeable" lv_suspended GOOD Reports: "unknown" lv_live_table GOOD Reports: "unknown" or "live table present" lv_inactive_table GOOD Reports: "unknown" lv_device_open GOOD Reports: "unknown" or "open" Physical Volume Fields ---------------------- pv_allocatable GOOD Reports: "allocatable" pv_exported GOOD Reports: "exported" pv_missing GOOD Reports: "missing" Volume Group Fields ------------------- vg_attr GOOD Reports: "wz-pnc" vg_permissions GOOD Reports: "writeable" vg_extendable GOOD Reports: "extendable" vg_exported GOOD Reports: "exported" vg_partial GOOD Reports: "partial" vg_allocation_policy GOOD Reports: "normal" vg_clustered GOOD Reports: "clustered" lvm2-2.02.109-1.el6 BUILT: Tue Aug 5 10:36:23 CDT 2014 lvm2-libs-2.02.109-1.el6 BUILT: Tue Aug 5 10:36:23 CDT 2014 lvm2-cluster-2.02.109-1.el6 BUILT: Tue Aug 5 10:36:23 CDT 2014 udev-147-2.57.el6 BUILT: Thu Jul 24 08:48:47 CDT 2014 device-mapper-1.02.88-1.el6 BUILT: Tue Aug 5 10:36:23 CDT 2014 device-mapper-libs-1.02.88-1.el6 BUILT: Tue Aug 5 10:36:23 CDT 2014 device-mapper-event-1.02.88-1.el6 BUILT: Tue Aug 5 10:36:23 CDT 2014 device-mapper-event-libs-1.02.88-1.el6 BUILT: Tue Aug 5 10:36:23 CDT 2014 device-mapper-persistent-data-0.3.2-1.el6 BUILT: Fri Apr 4 08:43:06 CDT 2014 cmirror-2.02.109-1.el6 BUILT: Tue Aug 5 10:36:23 CDT 2014 (In reply to Corey Marthaler from comment #10) > lv_volume_type GOOD Reports: "mirror" ( REGRESSION IN CURRENT > BUILD ) (...this one was removed in v109 as already reported by bug #1127451, will be reinstated in next build with some changes) > lv_converting BAD Reports: nothing while converting to a mirror Indeed - even the lv_attr bit is not reporting the conversion. I'll check this one. > lv_merge_failed BAD Reports: "unknown" after a failed merge attempt Hmm, this seems to be OK on my machine: [root@rhel6-a ~]# lvcreate -L100m vg Logical volume "lvol0" created [root@rhel6-a ~]# lvcreate -L100m -s vg/lvol0 Logical volume "lvol1" created [root@rhel6-a ~]# dd if=/dev/zero of=/dev/vg/lvol0 bs=1M count=50 50+0 records in 50+0 records out 52428800 bytes (52 MB) copied, 4.24539 s, 12.3 MB/s [root@rhel6-a ~]# lvconvert --merge vg/lvol1 Merging of volume lvol1 started. lvol0: Merged: 54.8% ... ==== [root@rhel6-a ~]# lvs -o lv_name,vg_name,lv_attr,lv_merging vg LV VG Attr Merging lvol0 vg Owi-a-s--- merging What was your cmd sequence exactly for the merge scenario? (In reply to Peter Rajnoha from comment #11) > > lv_converting BAD Reports: nothing while converting to a mirror > > > Indeed - even the lv_attr bit is not reporting the conversion. I'll check > this one. Well, this works only if we're upconverting existing mirror (--type mirror), it does not apply to raid (--type raid1), downconversion or converting linear volumes to mirror ones: (conversion from linear to mirror) [1] f20/~ # lvcreate -L512m vg Logical volume "lvol0" created [1] f20/~ # lvconvert -m1 --type mirror vg/lvol0 vg/lvol0: Converted: 0.8% ... === (conversion from 2-way to 3-way mirror) [3] f20/~ # lvs -o lv_name,vg_name,lv_attr,lv_converting LV VG Attr Converting lvol0 vg mwi-a-m--- ---------------------------------------- [1] f20/~ # lvconvert -m2 vg/lvol0 vg/lvol0: Converted: 1.6% [3] f20/~ # lvs -o lv_name,vg_name,lv_attr,lv_converting LV VG Attr Converting lvol0 vg cwi-a-m--- converting This is because we're using existence of internal and temporary "_mimagetmp" LV to detect the conversion. Since this was never detected in any other situations, it would be an RFE for adding better detection so all the other conversion types are detected as well. (In reply to Peter Rajnoha from comment #12) > (conversion from 2-way to 3-way mirror) ...wrong place for the note, sorry... > [3] f20/~ # lvs -o lv_name,vg_name,lv_attr,lv_converting > LV VG Attr Converting > lvol0 vg mwi-a-m--- > > ---------------------------------------- > The note "conversion from 2-way to 3-way mirror" should be here: (conversion from 2-way to 3-way mirror) > [1] f20/~ # lvconvert -m2 vg/lvol0 > vg/lvol0: Converted: 1.6% > > [3] f20/~ # lvs -o lv_name,vg_name,lv_attr,lv_converting > LV VG Attr Converting > lvol0 vg cwi-a-m--- converting > I filed bug rfe 1127902 for the converting issue, and have verified that lv_converting does report for existing mirrors being upconverted like mentioned in comment #13 It was 'lv_merge_failed' that I had questions about, not 'lv_merging'. I tried to merge invalidated snap shots and then tried to kill the machine during a merge and neither produced the "failed" status. I did however finally see the failed status when killing the device that was being merged. [root@host-049 ~]# lvs -a -o +devices LV VG Attr LSize Origin Data% Devices merge4 snapper swi-a-s--- 3.00g origin 32.56 /dev/sdf1(768) merge5 snapper swi-a-s--- 3.00g origin 32.56 /dev/sdf1(1536) origin snapper owi-a-s--- 8.00g /dev/sdb1(0) [root@host-049 ~]# echo offline > /sys/block/sdf/device/state [root@host-049 ~]# lvconvert --merge /dev/snapper/merge4 Merging of volume merge4 started. /dev/sdf1: read failed after 0 of 2048 at 0: Input/output error /dev/snapper/origin: read failed after 0 of 4096 at 0: Input/output error /dev/snapper/origin: read failed after 0 of 4096 at 4096: Input/output error /dev/snapper/merge5: read failed after 0 of 4096 at 0: Input/output error /dev/snapper/merge5: read failed after 0 of 4096 at 4096: Input/output error /dev/sdf1: read failed after 0 of 512 at 16104947712: Input/output error /dev/sdf1: read failed after 0 of 512 at 16105054208: Input/output error /dev/sdf1: read failed after 0 of 512 at 0: Input/output error /dev/sdf1: read failed after 0 of 512 at 4096: Input/output error Couldn't find device with uuid lkKYio-FrhC-RQkJ-I2pm-IbnD-Ybtr-11RlPp. Cannot change VG snapper while PVs are missing. Consider vgreduce --removemissing. ABORTING: Can't reread VG for snapper/origin [root@host-049 ~]# lvs -a -o lv_name,lv_merge_failed /dev/snapper/origin: read failed after 0 of 4096 at 0: Input/output error /dev/snapper/origin: read failed after 0 of 4096 at 4096: Input/output error /dev/snapper/merge5: read failed after 0 of 4096 at 0: Input/output error /dev/snapper/merge5: read failed after 0 of 4096 at 4096: Input/output error /dev/sdf1: read failed after 0 of 2048 at 0: Input/output error /dev/sdf1: read failed after 0 of 512 at 16104947712: Input/output error /dev/sdf1: read failed after 0 of 512 at 16105054208: Input/output error /dev/sdf1: read failed after 0 of 512 at 0: Input/output error /dev/sdf1: read failed after 0 of 512 at 4096: Input/output error Couldn't find device with uuid lkKYio-FrhC-RQkJ-I2pm-IbnD-Ybtr-11RlPp. LV MergeFailed [merge4] merge failed merge5 Marking this feature verified with the multiple known caveats listed in this report. I will also check on bug 1127451 in the next 6.6 lvm build. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2014-1387.html |