Peter Rajnoha 82f6dbfaf7 select: fix matching reserved values while <,<=,>,>= is used in selection criteria ... Scenario: $ vgs -o+vg_mda_copies VG #PV #LV #SN Attr VSize VFree #VMdaCps fedora 1 2 0 wz--n- 9.51g 0 unmanaged vg 16 9 0 wz--n- 1.94g 1.83g 2 $ lvs -o+read_ahead vg/lvol6 vg/lvol7 LV VG Attr LSize Pool Origin Data% Rahead lvol6 vg Vwi-a-tz-- 1.00g pool lvol5 0.00 auto lvol7 vg Vwi---tz-k 1.00g pool lvol6 256.00k Before this patch: $vgs -o vg_name,vg_mda_copies -S 'vg_mda_copies < unmanaged' VG #VMdaCps vg 2 Problem: Reserved values can be only used with exact match = or !=, not <,<=,>,>=. In the example above, the "unamanaged" is internally represented as 18446744073709551615, but this should be ignored while not comparing field directly with "unmanaged" reserved name with = or !=. Users should not be aware of this internal mapping of the reserved value name to its internal value and hence it doesn't make sense for such reserved value to take place in results of <,<=,> and >=. There's no order defined for reserved values!!! It's a special *reserved* value that is taken out of the usual value range of that type. This is very similar to what we have already fixed with 2f7f6932dc, but it's the other way round now - we're using reserved value name in selection criteria now (in the patch 2f7f693, we had concrete value and we compared it with the reserved value). So this patch completes patch 2f7f693. This patch also fixes this problem: $ lvs -o+read_ahead vg/lvol6 vg/lvol7 -S 'read_ahead > 32k' LV VG Attr LSize Pool Origin Data% Rahead lvol6 vg Vwi-a-tz-- 1.00g pool lvol5 0.00 auto lvol7 vg Vwi---tz-k 1.00g pool lvol6 256.00k Problem: In the example above, the internal reserved value "auto" is in the range of selection "> 32k" - it shouldn't match as well. Here the "auto" is internally represented as MAX_DBL and of course, numerically, MAX_DBL > 256k. But for users, the reserved value should be uncomparable to any number so the mapping of the reserved value name to its interna value is transparent to users. Again, there's no order defined for reserved values and hence it should never match if using <,<=,>,>= operators. This is actually exactly the same problem as already described in 2f7f6932dc, but that patch failed for size field types because of incorrect internal representation used. With this patch applied, both problematic scenarios mentioned above are fixed now: $ vgs -o vg_name,vg_mda_copies -S 'vg_mda_copies < unmanaged' (blank) $ lvs -o+read_ahead vg/lvol6 vg/lvol7 -S 'read_ahead > 32k' LV VG Attr LSize Pool Origin Rahead lvol7 vg Vwi---tz-k 1.00g pool lvol6 256.00k		2015-04-24 09:48:57 +02:00
..
datastruct	Use void pointer instead of char for binary key	2011-03-10 12:48:40 +00:00
ioctl	libdm: Add uuid/devno to ioctl failure log message.	2015-04-23 19:26:52 +01:00
misc	libdm: Add DM_INTERNAL_SUSPEND_FLAG.	2015-04-23 18:39:04 +01:00
mm	cleanup: indents comments backtraces	2014-11-10 22:05:49 +01:00
regex	cleanup: add braces for if()	2014-07-02 10:45:43 +02:00
.exported_symbols	dmsetup: Support remove --deferred.	2014-08-16 00:34:48 +01:00
libdevmapper.h	libdm: report: add dm_report_object_is_selected	2015-02-10 16:04:38 +01:00
libdevmapper.pc.in	Switch to use Requires.private for devmapper.pc and lvm2app.pc	2010-05-11 08:54:11 +00:00
libdm-common.c	libdm: revert incorrect path length size for sscanf	2014-08-29 13:10:18 +02:00
libdm-common.h	libdm: introduce and use DEV_UUID macro	2012-10-10 17:16:15 +02:00
libdm-config.c	cleanup: drop unused value assign	2015-02-19 14:43:25 +01:00
libdm-deptree.c	thin: errrorwhenfull support	2015-01-14 14:52:05 +01:00
libdm-file.c	Drop unreachable code	2012-02-08 12:59:45 +00:00
libdm-report.c	select: fix matching reserved values while <,<=,>,>= is used in selection criteria	2015-04-24 09:48:57 +02:00
libdm-string.c	cleanup: libdm simplier error comparation	2014-07-02 10:45:42 +02:00
Makefile.in	configure: Look for valgrind.h independently of VALGRIND_POOLS.	2015-02-05 13:50:34 +01:00