RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 821932 - Provide reporting fields to access each attribute individually
Summary: Provide reporting fields to access each attribute individually
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: lvm2
Version: 6.5
Hardware: All
OS: All
medium
low
Target Milestone: rc
: 6.5
Assignee: Peter Rajnoha
QA Contact: Cluster QE
URL:
Whiteboard:
Depends On:
Blocks: 1002699
TreeView+ depends on / blocked
 
Reported: 2012-05-15 19:13 UTC by Alasdair Kergon
Modified: 2014-12-11 16:13 UTC (History)
14 users (show)

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
Clone Of:
Environment:
Last Closed: 2014-10-14 08:23:00 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2014:1387 0 normal SHIPPED_LIVE lvm2 bug fix and enhancement update 2014-10-14 01:39:47 UTC

Description Alasdair Kergon 2012-05-15 19:13:21 UTC
A lot of state is encoded in the attribute fields (e.g. lv_attr) and it would be useful to separate out all the state into separate fields that can be queried individually.  (No changes to the existing fields or default outputs.)

Comment 2 Zdenek Kabelac 2014-05-14 20:01:14 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...

Comment 3 Alasdair Kergon 2014-05-14 20:33:22 UTC
Absolutely!

Comment 5 Peter Rajnoha 2014-06-06 13:20:21 UTC
...suitable for -S/--select for use in selection clauses. I'll have a look at this...

Comment 6 Peter Rajnoha 2014-07-11 11:29:48 UTC
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).

Comment 7 Peter Rajnoha 2014-07-11 12:17:05 UTC
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.

Comment 9 Corey Marthaler 2014-08-01 22:27:52 UTC
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.

Comment 10 Corey Marthaler 2014-08-06 23:29:30 UTC
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

Comment 11 Peter Rajnoha 2014-08-07 09:47:38 UTC
(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?

Comment 12 Peter Rajnoha 2014-08-07 11:03:58 UTC
(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.

Comment 13 Peter Rajnoha 2014-08-07 11:07:06 UTC
(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
>

Comment 14 Corey Marthaler 2014-08-07 20:07:48 UTC
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

Comment 15 Corey Marthaler 2014-08-07 20:17:25 UTC
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

Comment 16 Corey Marthaler 2014-08-07 20:21:41 UTC
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.

Comment 18 errata-xmlrpc 2014-10-14 08:23:00 UTC
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


Note You need to log in before you can comment on or make changes to this bug.