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.
Created attachment 621019 [details] Patch to correctly return value of property "data_percent"
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?
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
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; }
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