shaba/lvm2
1
0
Fork 0
mirror of git://sourceware.org/git/lvm2.git synced 2024-12-21 13:34:40 +03:00
Code Releases Activity
797c18d543
lvm2/lib/report/values.h

100 lines
5.8 KiB
C
Raw Normal View History

report: add values.h for per-field reserved value declaration
2014-07-10 11:22:45 +04:00
/*
* Copyright (C) 2014 Red Hat, Inc. All rights reserved.
*
* This file is part of LVM2.
*
* This copyrighted material is made available to anyone wishing to use,
* modify, copy, or redistribute it subject to the terms and conditions
* of the GNU Lesser General Public License v.2.1.
*
* You should have received a copy of the GNU Lesser General Public License
* along with this program; if not, write to the Free Software Foundation,
* Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
/*
* This file defines reserved names for field values.
*
* This is used for registering reserved names with reporting code that
* uses the exact value defined whenever the reserved name is hit, for
* example during selection criteria processing.
*
cleanup: report reserved value macros
2014-07-10 13:54:37 +04:00
* TYPE_RESERVED_VALUE defines reserved value that is not bound to any field,
* but rather it's bound to a certain type. This can be used as a reserved
cleanup: use helper macros to get reserved value from values.h for vg_mda_copies and lv_read_ahead fields Avoid making a copy of the keyword which is already registered in values.h for "unmanaged" (vg_mda_copies field) and "auto" reserved value (lv_read_ahead field). Also use helper macros to handle these reserved - this is the correct approach - just do not copy the same thing again and do not mix it! The GET_FIELD_RESERVED_VALUE and GET_FIRST_RESERVED_NAME macros guarantees this - use it! In addition to that, rename reserved values: vg_mda_copies --> vg_mda_copies_unmanaged lv_read_ahead --> lv_read_ahead_auto So the field reserved values follows this scheme: "<field_name>_<reserved_value_name>". The same applies for type reserved values with this scheme: "<report type name in lowercase>_<reserved_value_name>" Add a comment about this scheme for others to follow as well when adding new fields and their reserved values. This makes it a bit easier to read the code then.
2014-12-18 16:52:16 +03:00
* value for all fields of that type then. When naming type reserved value,
* please follow this naming scheme:
* <report type name in lowercase>_<reserved_value_name>
report: add values.h for per-field reserved value declaration
2014-07-10 11:22:45 +04:00
*
cleanup: report reserved value macros
2014-07-10 13:54:37 +04:00
* FIELD_RESERVED_VALUE defines reserved value bound to a single field.
cleanup: use helper macros to get reserved value from values.h for vg_mda_copies and lv_read_ahead fields Avoid making a copy of the keyword which is already registered in values.h for "unmanaged" (vg_mda_copies field) and "auto" reserved value (lv_read_ahead field). Also use helper macros to handle these reserved - this is the correct approach - just do not copy the same thing again and do not mix it! The GET_FIELD_RESERVED_VALUE and GET_FIRST_RESERVED_NAME macros guarantees this - use it! In addition to that, rename reserved values: vg_mda_copies --> vg_mda_copies_unmanaged lv_read_ahead --> lv_read_ahead_auto So the field reserved values follows this scheme: "<field_name>_<reserved_value_name>". The same applies for type reserved values with this scheme: "<report type name in lowercase>_<reserved_value_name>" Add a comment about this scheme for others to follow as well when adding new fields and their reserved values. This makes it a bit easier to read the code then.
2014-12-18 16:52:16 +03:00
* When naming reserved value for the field, please follow this naming scheme:
* <field_name>_<reserved_value_name>
cleanup: report reserved value macros
2014-07-10 13:54:37 +04:00
*
* FIELD_BINARY_RESERVED_VALUE is similar to FIELD_RESERVED_VALUE but it
* is specifically designed for defintion of reserved names for fields
* with binary values where the reserved names given denote value 1.
report: add values.h for per-field reserved value declaration
2014-07-10 11:22:45 +04:00
* The first reserved_name given is also used for reporting,
cleanup: report reserved value macros
2014-07-10 13:54:37 +04:00
* others are synonyms which are recognized in addition.
report: add values.h for per-field reserved value declaration
2014-07-10 11:22:45 +04:00
*
*/
/*
cleanup: also use values.h for final dm_report_reserved_value array composition
2014-07-10 15:37:26 +04:00
* TYPE_RESERVED_VALUE(type, reserved_value_id, description, value, reserved_name, ...)
* FIELD_RESERVED_VALUE(field_id, reserved_value_id, description, value, reserved_name, ...)
* FIELD_BINARY_RESERVED_VALUE(field_id, reserved_value_id, description, reserved_name for 1, ...)
report: add values.h for per-field reserved value declaration
2014-07-10 11:22:45 +04:00
*/
/* *INDENT-OFF* */
cleanup: report reserved value macros
2014-07-10 13:54:37 +04:00
/* Per-type reserved values usable for all fields of certain type. */
cleanup: use helper macros to get reserved value from values.h for vg_mda_copies and lv_read_ahead fields Avoid making a copy of the keyword which is already registered in values.h for "unmanaged" (vg_mda_copies field) and "auto" reserved value (lv_read_ahead field). Also use helper macros to handle these reserved - this is the correct approach - just do not copy the same thing again and do not mix it! The GET_FIELD_RESERVED_VALUE and GET_FIRST_RESERVED_NAME macros guarantees this - use it! In addition to that, rename reserved values: vg_mda_copies --> vg_mda_copies_unmanaged lv_read_ahead --> lv_read_ahead_auto So the field reserved values follows this scheme: "<field_name>_<reserved_value_name>". The same applies for type reserved values with this scheme: "<report type name in lowercase>_<reserved_value_name>" Add a comment about this scheme for others to follow as well when adding new fields and their reserved values. This makes it a bit easier to read the code then.
2014-12-18 16:52:16 +03:00
TYPE_RESERVED_VALUE(NUM, num_undef_64, "Reserved value for undefined numeric value.", UINT64_C(-1), "-1", "unknown", "undefined", "undef")
cleanup: report reserved value macros
2014-07-10 13:54:37 +04:00
report: add values.h for per-field reserved value declaration
2014-07-10 11:22:45 +04:00
/* Reserved values for PV fields */
cleanup: also use values.h for final dm_report_reserved_value array composition
2014-07-10 15:37:26 +04:00
FIELD_RESERVED_BINARY_VALUE(pv_allocatable, pv_allocatable, "", "allocatable")
FIELD_RESERVED_BINARY_VALUE(pv_exported, pv_exported, "", "exported")
FIELD_RESERVED_BINARY_VALUE(pv_missing, pv_missing, "", "missing")
report: add values.h for per-field reserved value declaration
2014-07-10 11:22:45 +04:00
/* Reserved values for VG fields */
cleanup: also use values.h for final dm_report_reserved_value array composition
2014-07-10 15:37:26 +04:00
FIELD_RESERVED_BINARY_VALUE(vg_extendable, vg_extendable, "", "extendable")
FIELD_RESERVED_BINARY_VALUE(vg_exported, vg_exported, "", "exported")
FIELD_RESERVED_BINARY_VALUE(vg_partial, vg_partial, "", "partial")
FIELD_RESERVED_BINARY_VALUE(vg_clustered, vg_clustered, "", "clustered")
report: fix selection on {vg,lv}_permissions fields to properly match selection criteria There was a bug in value and their synonym definition for these two fields causing selections on these fields to not work correctly - nothing matched against vg/lv_permissions fields even if selection criteria should have matched. Scenario: $ lvs -o name,lv_permissions vg LV LPerms lvol0 read-only lvol1 writeable Before this patch: $ lvs -o name,lv_permissions vg -S 'permissions=read-only' (blank) $ lvs -o name,lv_permissions vg -S 'permissions=writeable (blank) With this patch applied: $ lvs -o name,lv_permissions vg -S 'permissions=read-only' LV LPerms lvol0 read-only $ lvs -o name,lv_permissions vg -S 'permissions=writeable' LV LPerms lvol1 writeable Also synonyms match correctly now: $ lvs -o name,lv_permissions vg -S 'permissions=rw' LV LPerms lvol1 writeable
2014-10-23 17:03:04 +04:00
FIELD_RESERVED_VALUE(vg_permissions, vg_permissions_rw, "", "writeable", "writeable", "rw", "read-write")
FIELD_RESERVED_VALUE(vg_permissions, vg_permissions_r, "", "read-only", "read-only", "r", "ro")
cleanup: use helper macros to get reserved value from values.h for vg_mda_copies and lv_read_ahead fields Avoid making a copy of the keyword which is already registered in values.h for "unmanaged" (vg_mda_copies field) and "auto" reserved value (lv_read_ahead field). Also use helper macros to handle these reserved - this is the correct approach - just do not copy the same thing again and do not mix it! The GET_FIELD_RESERVED_VALUE and GET_FIRST_RESERVED_NAME macros guarantees this - use it! In addition to that, rename reserved values: vg_mda_copies --> vg_mda_copies_unmanaged lv_read_ahead --> lv_read_ahead_auto So the field reserved values follows this scheme: "<field_name>_<reserved_value_name>". The same applies for type reserved values with this scheme: "<report type name in lowercase>_<reserved_value_name>" Add a comment about this scheme for others to follow as well when adding new fields and their reserved values. This makes it a bit easier to read the code then.
2014-12-18 16:52:16 +03:00
FIELD_RESERVED_VALUE(vg_mda_copies, vg_mda_copies_unmanaged, "", &GET_TYPE_RESERVED_VALUE(num_undef_64), "unmanaged")
report: add values.h for per-field reserved value declaration
2014-07-10 11:22:45 +04:00
/* Reserved values for LV fields */
cleanup: also use values.h for final dm_report_reserved_value array composition
2014-07-10 15:37:26 +04:00
FIELD_RESERVED_BINARY_VALUE(lv_initial_image_sync, lv_initial_image_sync, "", "initial image sync", "sync")
FIELD_RESERVED_BINARY_VALUE(lv_image_synced, lv_image_synced, "", "image synced", "synced")
FIELD_RESERVED_BINARY_VALUE(lv_merging, lv_merging, "", "merging")
FIELD_RESERVED_BINARY_VALUE(lv_converting, lv_converting, "", "converting")
FIELD_RESERVED_BINARY_VALUE(lv_allocation_locked, lv_allocation_locked, "", "allocation locked", "locked")
FIELD_RESERVED_BINARY_VALUE(lv_fixed_minor, lv_fixed_minor, "", "fixed minor", "fixed")
FIELD_RESERVED_BINARY_VALUE(lv_active_locally, lv_active_locally, "", "active locally", "active", "locally")
FIELD_RESERVED_BINARY_VALUE(lv_active_remotely, lv_active_remotely, "", "active remotely", "active", "remotely")
FIELD_RESERVED_BINARY_VALUE(lv_active_exclusively, lv_active_exclusively, "", "active exclusively", "active", "exclusively")
FIELD_RESERVED_BINARY_VALUE(lv_merge_failed, lv_merge_failed, "", "merge failed", "failed")
FIELD_RESERVED_BINARY_VALUE(lv_snapshot_invalid, lv_snapshot_invalid, "", "snapshot invalid", "invalid")
FIELD_RESERVED_BINARY_VALUE(lv_suspended, lv_suspended, "", "suspended")
FIELD_RESERVED_BINARY_VALUE(lv_live_table, lv_live_table, "", "live table present", "live table", "live")
FIELD_RESERVED_BINARY_VALUE(lv_inactive_table, lv_inactive_table, "", "inactive table present", "inactive table", "inactive")
FIELD_RESERVED_BINARY_VALUE(lv_device_open, lv_device_open, "", "open")
FIELD_RESERVED_BINARY_VALUE(lv_skip_activation, lv_skip_activation, "", "skip activation", "skip")
report: report LV's zero field as binary field Like other binary fields we already have: $ lvs -o name,zero vg/lvx vg/pool vg/pool1 LV Zero lvx unknown pool pool1 zero $ lvs -o name,zero vg/lvx vg/pool vg/pool1 --binary LV Zero lvx -1 pool 0 pool1 1
2014-07-10 17:23:56 +04:00
FIELD_RESERVED_BINARY_VALUE(zero, zero, "", "zero")
report: fix selection on {vg,lv}_permissions fields to properly match selection criteria There was a bug in value and their synonym definition for these two fields causing selections on these fields to not work correctly - nothing matched against vg/lv_permissions fields even if selection criteria should have matched. Scenario: $ lvs -o name,lv_permissions vg LV LPerms lvol0 read-only lvol1 writeable Before this patch: $ lvs -o name,lv_permissions vg -S 'permissions=read-only' (blank) $ lvs -o name,lv_permissions vg -S 'permissions=writeable (blank) With this patch applied: $ lvs -o name,lv_permissions vg -S 'permissions=read-only' LV LPerms lvol0 read-only $ lvs -o name,lv_permissions vg -S 'permissions=writeable' LV LPerms lvol1 writeable Also synonyms match correctly now: $ lvs -o name,lv_permissions vg -S 'permissions=rw' LV LPerms lvol1 writeable
2014-10-23 17:03:04 +04:00
FIELD_RESERVED_VALUE(lv_permissions, lv_permissions_rw, "", "writeable", "writeable", "rw", "read-write")
FIELD_RESERVED_VALUE(lv_permissions, lv_permissions_r, "", "read-only", "read-only", "r", "ro")
FIELD_RESERVED_VALUE(lv_permissions, lv_permissions_r_override, "", "read-only-override", "read-only-override", "ro-override", "r-override", "R")
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 2f7f6932dcd450ba75fe590aba8c09838d2618dc, 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 2f7f6932dcd450ba75fe590aba8c09838d2618dc, 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 10:47:25 +03:00
FIELD_RESERVED_VALUE(lv_read_ahead, lv_read_ahead_auto, "", &_siz_max, "auto")
report: rename lv_error_when_full field to lv_when_full and display either "error", "queue" or "" Rename original lv_error_when_full field to lv_when_full and also convert it from binary field to string field displaying three possible values: "error", "queueu" or "" (blank for undefined). $ lvs vg/pool vg/pool1 vg/linear_lv -o+lv_when_full LV VG Attr LSize Data% Meta% WhenFull linear_lv vg -wi-a----- 4.00m pool vg twi-aotz-- 4.00m 0.00 0.98 queue pool1 vg twi-a-tz-- 4.00m 0.00 0.88 error For -S|--select these synonyms are recognized: "error" -> "error when full", "error if no space" "queue" -> "queue when full", "queue if no space" "" -> "undefined"
2015-01-21 12:43:40 +03:00
FIELD_RESERVED_VALUE(lv_when_full, lv_when_full_error, "", "error", "error", "error when full", "error if no space")
FIELD_RESERVED_VALUE(lv_when_full, lv_when_full_queue, "", "queue", "queue", "queue when full", "queue if no space")
FIELD_RESERVED_VALUE(lv_when_full, lv_when_full_undef, "", "", "", "undefined")
report: add values.h for per-field reserved value declaration
2014-07-10 11:22:45 +04:00
report: Add cache_policy and cache_settings (LV) segment fields.
2014-12-15 22:48:05 +03:00
/* Reserved values for SEG fields */
report: properly set "undefined" reserved value for cache_policy field Use helper macros to handle reserved values and also define "undefined" reserved value as: FIELD_RESERVED_VALUE(cache_policy, cache_policy_undef, "", "", "undefined") Which means: - print "" if the cache_policy value is undefined (the first name for this reserved value is "") - recognize "undefined" reserved name as synonym to "" (so statements like "lvs -S cache_policy=undefined" are still recognized)
2014-12-18 17:11:25 +03:00
FIELD_RESERVED_VALUE(cache_policy, cache_policy_undef, "", "", "", "undefined")
report: seg_monitor undefined Add 'undefined' value for segment which do not support monitoring. Fixes crash for commands like 'pvs -o+seg_monitor'.
2015-01-20 16:36:21 +03:00
FIELD_RESERVED_VALUE(seg_monitor, seg_monitor_undef, "", "", "", "undefined")
report: update report_object API Internal API change - pass single struct for both info & seg_status.
2015-01-20 15:16:41 +03:00
FIELD_RESERVED_VALUE(lv_health_status, health_undef, "", "", "", "undefined")
report: Add cache_policy and cache_settings (LV) segment fields.
2014-12-15 22:48:05 +03:00
/* TODO the following 2 need STR_LIST support for reserved values
FIELD_RESERVED_VALUE(cache_settings, cache_settings_default, "", "default", "default")
FIELD_RESERVED_VALUE(cache_settings, cache_settings_undef, "", "undefined", "undefined") */
report: add values.h for per-field reserved value declaration
2014-07-10 11:22:45 +04:00
/* *INDENT-ON* */
Copy Permalink