Bug 862095 - liblvm2app: property "data_percent" returns -1 for thin volumes
Summary: liblvm2app: property "data_percent" returns -1 for thin volumes
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: lvm2
Version: 6.5
Hardware: Unspecified
OS: Unspecified
medium
unspecified
Target Milestone: rc
: ---
Assignee: Zdenek Kabelac
QA Contact: Cluster QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-10-01 20:42 UTC by benscott
Modified: 2013-02-21 08:14 UTC (History)
13 users (show)

Fixed In Version: lvm2-2.02.98-1.el6
Doc Type: Bug Fix
Doc Text:
Unimplemented property "data_percent" for lvm2app caused return of incorrect value '-1' for thin volumes. It has been fixed by adding proper support for lvm_lv_get_property(lv, "data_percent");
Clone Of:
Environment:
Last Closed: 2013-02-21 08:14:08 UTC
Target Upstream Version:


Attachments (Terms of Use)
Patch to correctly return value of property "data_percent" (979 bytes, patch)
2012-10-03 16:49 UTC, Tony Asleson
no flags Details | Diff


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:0501 normal SHIPPED_LIVE lvm2 bug fix and enhancement update 2013-02-20 21:30:45 UTC

Description benscott 2012-10-01 20:42:30 UTC
Description of problem:

When using the following line of code:

   value = lvm_lv_get_property(lvmLV, "data_percent");

The value is the the same percentage reported by the "lvs" command for thin pools but returns invalid (-1) for thin volumes.

for example:

~# lvs
  LV        VG      Attr      LSize Pool     Data%  Move Log Copy%  Convert
  Pool_One  MyGroup twi-a-tz- 1.00g          9.96                        
  thin_vol2 MyGroup Vwi-a-tz- 2.00g Pool_One 4.98                        

for Pool_One  --> value = 9960937
for thin_vol2 --> value = -1


Version-Release number of selected component (if applicable):

  LVM version:     2.02.98(2)-git (2012-08-24)
  Library version: 1.02.77-git (2012-08-24)
  Driver version:  4.22.0

Additional info:

As reported in bug #838257 the number is reported with a uint64_t
but the percentage is an int32_t so sizes and signs are getting
mixed up.

Comment 2 Tony Asleson 2012-10-03 16:49:04 UTC
Created attachment 621019 [details]
Patch to correctly return value of property "data_percent"

Comment 3 Alasdair Kergon 2012-10-04 23:58:37 UTC
And what about the values when it's a snapshot, and various other conditions in the 'lvs' code.

Do we always want the output to match?  If so, we should find a better way to share the logic to arrive at the right number before going into the mechanics of outputting it either via liblvm or a cmdline report like lvs.

How many other fields similarly don't match?

Comment 4 Zdenek Kabelac 2012-10-05 08:41:14 UTC
Fixed upstream with slightly different patch to provide matching behavior with lvs reporting functionality (data_percent reports also snap_percent for old-snaps):

https://www.redhat.com/archives/lvm-devel/2012-October/msg00019.html

Comment 6 Zdenek Kabelac 2012-10-12 09:49:02 UTC
Here is simple    lvm2api test program which should pass now:

----
# Create pool & thin & snap LVs

lvcreate -L5M -T vg/pool
lvcreate -V1M -T vg/pool -n thin

----

#include "lvm2app.h"

int main(int argc, char *argv[])
{
	lvm_t handle;
	vg_t vg;
	lv_t lv;
	struct lvm_property_value v;

	handle = lvm_init(NULL);
	vg = lvm_vg_open(handle, argv[1], "r", 0);
	lv = lvm_lv_from_name(vg, "thin");
	v = lvm_lv_get_property(lv, "data_percent");

	lvm_vg_close(vg);
	lvm_quit(handle);

	return  (v.is_valid && v.value.integer != -1) ? 0 : 1;
}

Comment 9 errata-xmlrpc 2013-02-21 08:14:08 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-2013-0501.html


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