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
d6cf83968c
lvm2/lib/report/values.h

101 lines
6.0 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
*
*/
/*
select: add support for range reserved values and flagging named-only values This patch allows for registration and recognition of reserved values which are ranges, so they're composed of two values actually to denote the lower and upper bound for the range (stored as an array with exactly two items to define the boundaries). Also, this patch allows for flagging reserved values as named-only which means that such values are not strictly reserved. The strictly reserved values are reserved values as used before this patch. Distinction between strictly-reserved and named-only values is clearly visible with comparisons. Normally, strictly reserved value is not accounted for if we do "greater than" or "lower than" comparisons, for example: 1 2 3 .... | abc - we have "abc" as reserved value for field with value "2" - the value reported for the field is "abc" (or "2", it doesn't matter here) - the selection we're processing is -S 'field < abc' - the result of the selection gives nothing as "abc" is strictly reserved value (bound to "2") and there's no order defined for it and it would only match if we directly compared the value (so -S 'field = abc' would match) With named-only values, the "abc" is named-only value for "2", so selection -S 'field < abc" is the same as using -S 'field < 2'. The "abc" is just an alias for some value so the value or its assigned name can be used equally in selection criteria.
2015-06-30 11:13:35 +03:00
* TYPE_RESERVED_VALUE(type, flags, reserved_value_id, description, value, reserved_name, ...)
* FIELD_RESERVED_VALUE(field_id, flags, reserved_value_id, description, value, reserved_name, ...)
cleanup: also use values.h for final dm_report_reserved_value array composition
2014-07-10 15:37:26 +04:00
* 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. */
select: add support for range reserved values and flagging named-only values This patch allows for registration and recognition of reserved values which are ranges, so they're composed of two values actually to denote the lower and upper bound for the range (stored as an array with exactly two items to define the boundaries). Also, this patch allows for flagging reserved values as named-only which means that such values are not strictly reserved. The strictly reserved values are reserved values as used before this patch. Distinction between strictly-reserved and named-only values is clearly visible with comparisons. Normally, strictly reserved value is not accounted for if we do "greater than" or "lower than" comparisons, for example: 1 2 3 .... | abc - we have "abc" as reserved value for field with value "2" - the value reported for the field is "abc" (or "2", it doesn't matter here) - the selection we're processing is -S 'field < abc' - the result of the selection gives nothing as "abc" is strictly reserved value (bound to "2") and there's no order defined for it and it would only match if we directly compared the value (so -S 'field = abc' would match) With named-only values, the "abc" is named-only value for "2", so selection -S 'field < abc" is the same as using -S 'field < 2'. The "abc" is just an alias for some value so the value or its assigned name can be used equally in selection criteria.
2015-06-30 11:13:35 +03:00
TYPE_RESERVED_VALUE(NUM, NOFLAG, 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")
select: add support for range reserved values and flagging named-only values This patch allows for registration and recognition of reserved values which are ranges, so they're composed of two values actually to denote the lower and upper bound for the range (stored as an array with exactly two items to define the boundaries). Also, this patch allows for flagging reserved values as named-only which means that such values are not strictly reserved. The strictly reserved values are reserved values as used before this patch. Distinction between strictly-reserved and named-only values is clearly visible with comparisons. Normally, strictly reserved value is not accounted for if we do "greater than" or "lower than" comparisons, for example: 1 2 3 .... | abc - we have "abc" as reserved value for field with value "2" - the value reported for the field is "abc" (or "2", it doesn't matter here) - the selection we're processing is -S 'field < abc' - the result of the selection gives nothing as "abc" is strictly reserved value (bound to "2") and there's no order defined for it and it would only match if we directly compared the value (so -S 'field = abc' would match) With named-only values, the "abc" is named-only value for "2", so selection -S 'field < abc" is the same as using -S 'field < 2'. The "abc" is just an alias for some value so the value or its assigned name can be used equally in selection criteria.
2015-06-30 11:13:35 +03:00
FIELD_RESERVED_VALUE(NAMED, vg_permissions, vg_permissions_rw, "", "writeable", "writeable", "rw", "read-write")
FIELD_RESERVED_VALUE(NAMED, vg_permissions, vg_permissions_r, "", "read-only", "read-only", "r", "ro")
FIELD_RESERVED_VALUE(NOFLAG, 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")
select: add support for range reserved values and flagging named-only values This patch allows for registration and recognition of reserved values which are ranges, so they're composed of two values actually to denote the lower and upper bound for the range (stored as an array with exactly two items to define the boundaries). Also, this patch allows for flagging reserved values as named-only which means that such values are not strictly reserved. The strictly reserved values are reserved values as used before this patch. Distinction between strictly-reserved and named-only values is clearly visible with comparisons. Normally, strictly reserved value is not accounted for if we do "greater than" or "lower than" comparisons, for example: 1 2 3 .... | abc - we have "abc" as reserved value for field with value "2" - the value reported for the field is "abc" (or "2", it doesn't matter here) - the selection we're processing is -S 'field < abc' - the result of the selection gives nothing as "abc" is strictly reserved value (bound to "2") and there's no order defined for it and it would only match if we directly compared the value (so -S 'field = abc' would match) With named-only values, the "abc" is named-only value for "2", so selection -S 'field < abc" is the same as using -S 'field < 2'. The "abc" is just an alias for some value so the value or its assigned name can be used equally in selection criteria.
2015-06-30 11:13:35 +03:00
FIELD_RESERVED_VALUE(NAMED, lv_permissions, lv_permissions_rw, "", "writeable", "writeable", "rw", "read-write")
FIELD_RESERVED_VALUE(NAMED, lv_permissions, lv_permissions_r, "", "read-only", "read-only", "r", "ro")
FIELD_RESERVED_VALUE(NAMED, lv_permissions, lv_permissions_r_override, "", "read-only-override", "read-only-override", "ro-override", "r-override", "R")
FIELD_RESERVED_VALUE(NOFLAG, lv_read_ahead, lv_read_ahead_auto, "", &_siz_max, "auto")
FIELD_RESERVED_VALUE(NAMED, lv_when_full, lv_when_full_error, "", "error", "error", "error when full", "error if no space")
FIELD_RESERVED_VALUE(NAMED, lv_when_full, lv_when_full_queue, "", "queue", "queue", "queue when full", "queue if no space")
FIELD_RESERVED_VALUE(NOFLAG, lv_when_full, lv_when_full_undef, "", "", "", "undefined")
report: select: add handler to recognize fuzzy time specification Recognize date and time specification within selection criteria that is formulated in a more free-form way besides to the original basic YYYY-MM-DD HH:MM format that libdevmapper supports. Currently, this free-form format is recognized for lv_time field. Users are able to use expressions from this set: - weekday names ("Sunday" - "Saturday" or abbreviated as "Sun" - "Sat") - labels for points in time ("noon", "midnight") - labels for a day relative to current day ("today", "yesterday") - points back in time with relative offset from today (N is a number) ( "N" "seconds"/"minutes"/"hours"/"days"/"weeks"/"years" "ago") ( "N" "secs"/"mins"/"hrs" ... "ago") ( "N" "s"/"m"/"h" ... "ago") - time specification either in hh:mm:ss format or with AM/PM suffixes - month names ("January" - "December" or abbreviated as "Jan" - "Dec") For example: $ date Fri Jul 3 10:11:13 CEST 2015 $ lvmconfig --type full report/time_format time_format="%a %Y-%m-%d %T %z %Z [%s]" $ lvs LV VG Time lvol0 vg Fri 2014-08-22 21:25:41 +0200 CEST [1408735541] lvol2 vg Sun 2015-04-26 14:52:20 +0200 CEST [1430052740] root fedora Wed 2015-05-27 08:09:21 +0200 CEST [1432706961] swap fedora Wed 2015-05-27 08:09:21 +0200 CEST [1432706961] lvol1 vg Tue 2015-06-30 03:25:43 +0200 CEST [1435627543] lvol3 vg Tue 2015-06-30 14:52:23 +0200 CEST [1435668743] lvol6 vg Wed 2015-07-01 13:35:56 +0200 CEST [1435750556] lvol4 vg Thu 2015-07-02 12:12:02 +0200 CEST [1435831922] lvol5 vg Thu 2015-07-02 14:30:32 +0200 CEST [1435840232] $ lvs -S 'time=yesterday' LV VG Time lvol4 vg Thu 2015-07-02 12:12:02 +0200 CEST [1435831922] lvol5 vg Thu 2015-07-02 14:30:32 +0200 CEST [1435840232] $ lvs -S 'time since "June 30"' LV VG Time lvol1 vg Tue 2015-06-30 03:25:43 +0200 CEST [1435627543] lvol3 vg Tue 2015-06-30 14:52:23 +0200 CEST [1435668743] lvol6 vg Wed 2015-07-01 13:35:56 +0200 CEST [1435750556] lvol4 vg Thu 2015-07-02 12:12:02 +0200 CEST [1435831922] lvol5 vg Thu 2015-07-02 14:30:32 +0200 CEST [1435840232] $ lvs -S 'time since "noon June 30"' LV VG Time lvol3 vg Tue 2015-06-30 14:52:23 +0200 CEST [1435668743] lvol6 vg Wed 2015-07-01 13:35:56 +0200 CEST [1435750556] lvol4 vg Thu 2015-07-02 12:12:02 +0200 CEST [1435831922] lvol5 vg Thu 2015-07-02 14:30:32 +0200 CEST [1435840232] $ lvs -S 'time since "2 July 9AM"' LV VG Time lvol4 vg Thu 2015-07-02 12:12:02 +0200 CEST [1435831922] lvol5 vg Thu 2015-07-02 14:30:32 +0200 CEST [1435840232] $ lvs -S 'time since "2 July 1PM"' LV VG Time lvol5 vg Thu 2015-07-02 14:30:32 +0200 CEST [1435840232] ...and so on.
2015-07-03 11:43:07 +03:00
FIELD_RESERVED_VALUE(NAMED | RANGE | FUZZY | DYNAMIC, lv_time, lv_time_fuzzy, "", lv_time_handler, NULL)
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 */
select: add support for range reserved values and flagging named-only values This patch allows for registration and recognition of reserved values which are ranges, so they're composed of two values actually to denote the lower and upper bound for the range (stored as an array with exactly two items to define the boundaries). Also, this patch allows for flagging reserved values as named-only which means that such values are not strictly reserved. The strictly reserved values are reserved values as used before this patch. Distinction between strictly-reserved and named-only values is clearly visible with comparisons. Normally, strictly reserved value is not accounted for if we do "greater than" or "lower than" comparisons, for example: 1 2 3 .... | abc - we have "abc" as reserved value for field with value "2" - the value reported for the field is "abc" (or "2", it doesn't matter here) - the selection we're processing is -S 'field < abc' - the result of the selection gives nothing as "abc" is strictly reserved value (bound to "2") and there's no order defined for it and it would only match if we directly compared the value (so -S 'field = abc' would match) With named-only values, the "abc" is named-only value for "2", so selection -S 'field < abc" is the same as using -S 'field < 2'. The "abc" is just an alias for some value so the value or its assigned name can be used equally in selection criteria.
2015-06-30 11:13:35 +03:00
FIELD_RESERVED_VALUE(NOFLAG, cache_policy, cache_policy_undef, "", "", "", "undefined")
FIELD_RESERVED_VALUE(NOFLAG, seg_monitor, seg_monitor_undef, "", "", "", "undefined")
FIELD_RESERVED_VALUE(NOFLAG, 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