summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* toollib: process_each_pv workaround for no mda pvsdev-dct-process-v20David Teigland2014-06-201-13/+26
| | | | | | Add a workaround for a bug somewhere that can cause a pv with no mda to appear in both its real vg and in the orphan vg when not using lvmetad.
* test: add process-each toollib testsDavid Teigland2014-06-194-0/+1933
|
* logging: use flags to enable warningsDavid Teigland2014-06-195-53/+59
| | | | | | | | | | | | | | | The "warnings" arg was used to enable logging of warnings when reading a pv. This arg is turned into a set of flags with the WARN_PV_READ flag matching the existing behavior. A new flag WARN_INCONSISTENT is added that will cause vg_read_internal() to log the "vg is not consistent" warning, and the various callers do not need to log this warning themselves. A new vg_read flag READ_WARN_INCONSISTENT is used from reporting to enable the WARN_INCONSISTENT flag in vg_read_internal.
* vgreduce: use normal process_each_pvDavid Teigland2014-06-193-83/+76
| | | | In the non-repair case.
* toollib: rewrite process_each_pvDavid Teigland2014-06-1911-371/+474
| | | | | | Process pvs by iterating through vgs, then iterating through devs if the command wants to process non-pv devices. The process_single function can always use the vg and pv args.
* toollib: add ENABLE_ALL_DEVS flagDavid Teigland2014-06-192-3/+4
| | | | | | | The ENABLE_ALL_DEVS flag is added to the command structure for commands that should process all devs (pvs and non-pvs) when they call process_each_pv and the command includes the --all arg. This will be used in a later process_each_pv patch.
* toollib: remove unused arg from process_each_lv_in_vgDavid Teigland2014-06-193-4/+2
| | | | | The failed_lvnames arg is no longer used since the cmd_vg replicator wrapper was removed.
* toollib: improve error message in process_each_lv_in_vgDavid Teigland2014-06-191-6/+11
| | | | Include in the error message the lv name args that were not found.
* toollib: rewrite process_each_lvDavid Teigland2014-06-191-297/+334
| | | | | | - Copy the same form as the new process_each_vg. - Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly.
* toollib: rewrite process_each_vgDavid Teigland2014-06-191-145/+233
| | | | | | | | - Split the collecting of arguments from processing them. - The split allows the two different loops through vgs to be replaced by a single loop. - Replace unused struct cmd_vg and cmd_vg_read() replicator code with struct vg and vg_read() directly.
* toollib: add ALL_VGS_IS_DEFAULT flagDavid Teigland2014-06-192-14/+21
| | | | | | | The ALL_VGS_IS_DEFAULT flag is added to the command structure for commands that should process all vgs when they call process_each_vg or process_each_lv with no args. This will be used in later patches to process_each functions.
* dmsetup: no need to check for "help" field name after report initPeter Rajnoha2014-06-191-3/+0
| | | | | The "help" field (as well as "?") is implicit now - libdevmapper takes care of it completely.
* pvmove: Fix code that looks up the "move pv" for displayJonathan Brassow2014-06-191-4/+19
| | | | | | | 'lvs' would segfault if trying to display the "move pv" if the pvmove was run with '--atomic'. The structure of an atomic pvmove is different and requires us to descend another level in the LV tree to retrieve the PV information.
* pvmove: Clean-up iterator.Jonathan Brassow2014-06-191-4/+19
| | | | | | In 'find_pvmove_lv', separate the code that searches the atomic pvmove LVs from the code that searches the normal pvmove LVs. This cleans up the segment iterator code a bit.
* report: display explicit fields first, then implicit fields in field helpPeter Rajnoha2014-06-191-3/+4
| | | | | | | It's better to have implicit fields at the very end of the output so users can see them without scrolling back if the list of fields is long (the "help" is also an implicit field now so it should be easily visible).
* libdevmapper: revoke commit 7c86131233011c9fb81190bcb40d5d4ac54a533dPeter Rajnoha2014-06-193-9/+4
| | | | | | | | | | | We have "help" and "?" defined as implicit fields now. As such, we don't need to export these names in libdevmapper (as it was introduced by commit 7c86131233011c9fb81190bcb40d5d4ac54a533d within this release). If anyone uses these field names by mistake, the libdevmapper code can error out correctly if it detects that the set of explicit field names (the ones supplied by "fields" arg in dm_report_init/dm_report_init_with_selection) contains any of the implicit field names (the ones defined internally by libdevmapper itself).
* report: make "help" and "?" field implicitPeter Rajnoha2014-06-193-38/+58
| | | | | | | | | | | | | Making "help" and "?" implicit also simplifies code since the dm_report_init caller (lvm/dmsetup) doesn't need to check on dm_report_init return whether "help" or "?" was hit while parsing fields/sort keys in libdevmapper. The libdevmapper now sets internal "RH_ALREADY_REPORTED" flag after it reports the "help" or "?" implicit field. Then libdevmapper itself checks for this flag in dm_report_object and if found, the actual reporting is skipped (because the "help" implicit field was reported instead of the actual report).
* select: add list of allowed types for each selection operator mentioned in helpPeter Rajnoha2014-06-191-8/+8
|
* pvmove: tidyAlasdair G Kergon2014-06-195-21/+16
|
* tests: remove dmeventd usageZdenek Kabelac2014-06-191-1/+1
| | | | | This test is testing --use-policies on cmdline. So monitoring must not be used.
* cleanup: rename variable waitZdenek Kabelac2014-06-191-2/+2
| | | | With older system headers (sys/wait.h) this shadows declaration.
* cleanup: more readableZdenek Kabelac2014-06-191-14/+9
| | | | | Older gcc complained a bit about uninitialized vars so reorder code for better readability.
* lvchange: better --refresh of raid and mirrorsZdenek Kabelac2014-06-192-4/+2
| | | | | | Use lv_check_not_in_use() to detect openned device. Plain info.open_count is not good enough for udev random device openning.
* test: Clean-up pvmove-basic for atomic pvmove testJonathan Brassow2014-06-181-6/+3
| | | | | The way I was testing for the existence of pvmove mimages was incorrect for rhel5. This patch makes it more generic/universal.
* man: lvmthinDavid Teigland2014-06-181-164/+169
| | | | | Clean up inconsistencies in the last change. Improve some bad formatting.
* cleanup: use insert_layer_for_lv implicit renameZdenek Kabelac2014-06-182-23/+9
| | | | | | | There is implicit rename for certain layered device. Do it now for _tdata, _cdata and _corig. TODO: use better API here...
* lvconvert: print warning when not convert thinpoolZdenek Kabelac2014-06-181-14/+16
| | | | | | Warning about destruction should not be printed, When we are converting already existing pool (improving original in-release commit bbf4b2c1c9d)
* compilation: fix warnings: build_dm_uuid now accepts whole struct ↵Peter Rajnoha2014-06-181-5/+5
| | | | | | | | | | logical_volume, not lvid replicator/replicator.c:338:2: warning: passing argument 2 of 'build_dm_uuid' from incompatible pointer type [enabled by default] replicator/replicator.c:629:3: warning: passing argument 2 of 'build_dm_uuid' from incompatible pointer type [enabled by default] replicator/replicator.c:644:6: warning: passing argument 2 of 'build_dm_uuid' from incompatible pointer type [enabled by default] replicator/replicator.c:668:7: warning: passing argument 2 of 'build_dm_uuid' from incompatible pointer type [enabled by default] replicator/replicator.c:677:4: warning: passing argument 2 of 'build_dm_uuid' from incompatible pointer type [enabled by default]
* man: add man page entry for dmsetup info -c -S/--select + minor cleanupsPeter Rajnoha2014-06-184-12/+24
|
* cleanup: gcc warnings and report-select test vs snap_percent 0%Peter Rajnoha2014-06-182-3/+7
| | | | | | | | | Fix gcc warnings: libdm-report.c:1952:5: warning: "end_op_flag_hit" may be used uninitialized in this function [-Wmaybe-uninitialized] libdm-report.c:2232:28: warning: "custom" may be used uninitialized in this function [-Wmaybe-uninitialized] And snap_percent is not 0% in dm < 1.10.0 so don't test comparison with 0% here.
* WHATS_NEW: commit 76467bdcfd297ffbe2c088b6340ecc7d17d56742Peter Rajnoha2014-06-181-0/+1
| | | | | | Ordering string list items on reports is also new compared to previous state where items were not ordered at all and they got reported simply as they appeared/were processed.
* WHATS_NEW: commits ↵Peter Rajnoha2014-06-182-0/+18
| | | | | | 7dbbc05a69c4cb9756464720cad29e3c1ed971c3..b16f5633ab199dedfd25f08562f686a6fb4aba9d Report selection support...
* pvmove: Enable all-or-nothing (atomic) pvmovesJonathan Brassow2014-06-1716-75/+344
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | pvmove can be used to move single LVs by name or multiple LVs that lie within the specified PV range (e.g. /dev/sdb1:0-1000). When moving more than one LV, the portions of those LVs that are in the range to be moved are added to a new temporary pvmove LV. The LVs then point to the range in the pvmove LV, rather than the PV range. Example 1: We have two LVs in this example. After they were created, the first LV was grown, yeilding two segments in LV1. So, there are two LVs with a total of three segments. Before pvmove: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- After pvmove inserts the temporary pvmove LV: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- Each of the affected LV segments now point to a range of blocks in the pvmove LV, which purposefully corresponds to the segments moved from the original LVs into the temporary pvmove LV. The current implementation goes on from here to mirror the temporary pvmove LV by segment. Further, as the pvmove LV is activated, only one of its segments is actually mirrored (i.e. "moving") at a time. The rest are either complete or not addressed yet. If the pvmove is aborted, those segments that are completed will remain on the destination and those that are not yet addressed or in the process of moving will stay on the source PV. Thus, it is possible to have a partially completed move - some LVs (or certain segments of LVs) on the source PV and some on the destination. Example 2: What 'example 1' might look if it was half-way through the move. --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | | ------------------------- source PV | | 256 - 511 | 512 - 767 | | ------------------------- | || ------------------------- dest PV | 000 - 255 | 256 - 511 | ------------------------- This update allows the user to specify that they would like the pvmove mirror created "by LV" rather than "by segment". That is, the pvmove LV becomes an image in an encapsulating mirror along with the allocated copy image. Example 3: A pvmove that is performed "by LV" rather than "by segment". --------- --------- | LV1s0 | | LV2s0 | --------- --------- | | ------------------------- pvmove0 | * LV-level mirror * | ------------------------- / \ pvmove_mimage0 / pvmove_mimage1 ------------------------- ------------------------- | seg 0 | seg 1 | | seg 0 | seg 1 | ------------------------- ------------------------- | | | | ------------------------- ------------------------- | 000 - 255 | 256 - 511 | | 000 - 255 | 256 - 511 | ------------------------- ------------------------- source PV dest PV The thing that differentiates a pvmove done in this way and a simple "up-convert" from linear to mirror is the preservation of the distinct segments. A normal up-convert would simply allocate the necessary space with no regard for segment boundaries. The pvmove operation must preserve the segments because they are the critical boundary between the segments of the LVs being moved. So, when the pvmove copy image is allocated, all corresponding segments must be allocated. The code that merges ajoining segments that are part of the same LV when the metadata is written must also be avoided in this case. This method of mirroring is unique enough to warrant its own definitional macro, MIRROR_BY_SEGMENTED_LV. This joins the two existing macros: MIRROR_BY_SEG (for original pvmove) and MIRROR_BY_LV (for user created mirrors). The advantages of performing pvmove in this way is that all of the LVs affected can be moved together. It is an all-or-nothing approach that leaves all LV segments on the source PV if the move is aborted. Additionally, a mirror log can be used (in the future) to provide tracking of progress; allowing the copy to continue where it left off in the event there is a deactivation.
* test: fix report_select test to work in clusterPeter Rajnoha2014-06-171-1/+1
| | | | | The snapshot LV is used to check selection of percent values. The orig volume must be activated exclusively in cluster.
* tests: update lvcreate-thin for latest changesPeter Rajnoha2014-06-171-1/+1
| | | | | | | | | With recent changes introduced with the report selection support, the content of lv_modules field is of string list type (before it was just string type). String list elements are always ordered now so update lvcreate-thin test to expect the elements to be ordered.
* prop: update FIELD macro to accomodate the differentiation of number, size ↵Peter Rajnoha2014-06-172-1/+2
| | | | | | | | and percent field values The differentiation of the original number field into number, size and percent field types has been introduced with recent changes for report selection support.
* report: select: add man pages for report selection featuredev-prajnoha-report-selectPeter Rajnoha2014-06-177-0/+117
|
* report: select: add --select arg to lvm devtypesPeter Rajnoha2014-06-171-1/+2
|
* report: add support for implicit fields, add implicit "selected" fieldPeter Rajnoha2014-06-171-67/+282
| | | | | | | | | | | | | | | | | | | | | | | | Implicit fields are fields that are registered with the report and reported internally by libdevmapper itself (compared to explicit fields that are registered by the layer above libdevmapper - e.g. LVM, dmsetup...). The "selected" field is the implicit field (for now the only one) that reports the result of the selection. Since the selection itself is the property of the libdevmapper, the upper layer using dm_report_init can't register this field itself and it must be done directly at libdevmapper layer. The "selected" field is internally registered as part of the "common" report type with id 0x80000000 (the last bit in uin32_t) which is then reserved (the explicit report types are then checked if they do not contain this id and if yes, we error out). This way, the "selected" field is recognized by all libdevmapper users that initialize the reporting with "dm_report_init_with_selection". If reporting is initialized with the classical "dm_report_init", there's no functional change (so the "selected" field is not defined and it's not recognized).
* tests: select: add test for report selection featurePeter Rajnoha2014-06-171-0/+212
|
* report: select: add support for percent selectionPeter Rajnoha2014-06-175-37/+84
|
* report: select: refactor: move percent handling code to libdm for reusePeter Rajnoha2014-06-1730-257/+266
|
* report: select: add support for reserved value recognition in report ↵Peter Rajnoha2014-06-174-43/+268
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | selection string - add struct dm_report_reserved_value Make dm_report_init_with_selection to accept an argument with an array of reserved values where each element contains a triple: {dm report field type, reserved value, array of strings representing this value} When the selection is parsed, we always check whether a string representation of some reserved value is not hit and if it is, we use the reserved value assigned for this string instead of trying to parse it as a value of certain field type. This makes it possible to define selections like: ... --select lv_major=undefined (or -1 or unknown or undef or whatever string representations are registered for this reserved value in the future) ... --select lv_read_ahead=auto ... --select vg_mda_copies=unmanaged With this, each time the field value of certain type is hit and when we compare it with the selection, we use the proper value for comparison. For now, register these reserved values that are used at the moment (also more descriptive names are used for the values): const uint64_t _reserved_number_undef_64 = UINT64_MAX; const uint64_t _reserved_number_unmanaged_64 = UINT64_MAX - 1; const uint64_t _reserved_size_auto_64 = UINT64_MAX; { {DM_REPORT_FIELD_TYPE_NUMBER, _reserved_number_undef_64, {"-1", "undefined", "undef", "unknown", NULL}}, {DM_REPORT_FIELD_TYPE_NUMBER, _reserved_number_unmanaged_64, {"unmanaged", NULL}}, {DM_REPORT_FIELD_TYPE_SIZE, _reserved_size_auto_64, {"auto", NULL}}, NULL } Same reserved value of different field types do not collide. All arrays are null-terminated. The list of reserved values is automatically displayed within selection help output: Selection operands ------------------ ... Reserved values --------------- -1, undefined, undef, unknown - Reserved value for undefined numeric value. [number] unmanaged - Reserved value for unmanaged number of metadata copies in VG. [number] auto - Reserved value for size that is automatically calculated. [size] Selection operators ------------------- ...
* report: select: show field type in field list if in context of selectionPeter Rajnoha2014-06-171-6/+21
| | | | | | | | When the field list is displayed as help for constructing selection criteria, show also the field value type. This is useful for users to know what set of operators are allowed for the type - the subsequent "Selection operands" section in the help output summarize all known types that can be used in selection.
* report: select: add help for creating selectionsPeter Rajnoha2014-06-172-7/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The "<lvm command> -S/--select help" shows help (including list of fields to match against): ...field list here including the field type name... Selection operands ------------------ field - Reporting field. number - Non-negative integer value. size - Floating point value with units specified. string - Characters quoted by ' or " or unquoted. string list - Strings enclosed by [ ] and elements delimited by either "all items must match" or "at least one item must match" operator. regular expression - Characters quoted by ' or " or unquoted. Selection operators ------------------- Comparison operators: =~ - Matching regular expression. !~ - Not matching regular expression. = - Equal to. != - Not equal to. >= - Greater than or equal to. > - Greater than <= - Less than or equal to. < - Less than. Logical and grouping operators: && - All fields must match , - All fields must match || - At least one field must match # - At least one field must match ! - Logical negation ( - Left parenthesis ) - Right parenthesis [ - List start ] - List end
* report: select: add support for comparing string lists with selection definedPeter Rajnoha2014-06-171-0/+73
|
* report: select: add support for processing string lists in selectionPeter Rajnoha2014-06-171-6/+198
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Selection list items are enclosed in '[' and ']' (if there's only one item, the '[' and ']' can be omitted). Each element of the list is a string (either quoted or unquoted, like the usual string operand used in selection) and each element is delimited either by conjunction (meaining "match all") or disjunction operator (meaning "match any"). For example, if "," is the conjuction operator and "/" is the disjunction operator then: lv_tags=[a,b,c] ...will match all fields where tags contain *all* a, b and c. lv_tags=[a/b/c] ...will match all fields where tags contain *any* of a, b, or c. Mixing operators within the list is not supported: lv_tags=[a,b/c] ...will give an error. The order in which items are defined in the selection do not matter. This patch enhances the selection parsing functionality to recognize such lists.
* report: select: add DM_REPORT_FIELD_TYPE_STRING_LIST to make a difference ↵Peter Rajnoha2014-06-176-23/+32
| | | | | | | | between STRING and STRING_LIST The {pv,vg,lv,seg}_tags and lv_modules fields are reported as string lists using the new dm_report_field_string_list - so we just pass the list to the fn that takes care of reporting and item sorting itself.
* report: select: add dm_report_field_string_list to libdmPeter Rajnoha2014-06-172-0/+129
| | | | | | | | | | | | | | | | | | | | | | | | | | | Add a separate dm_report_field_string_list fn to libdevmapper to support reporting string lists. Before, the code used libdevmappers's dm_report_field_string fn which required formatting the list to a single string. This functionality is now moved to libdevmapper and the code that needs to report the string list just needs to pass the list itself and libdevmapper will take care of this. This also enhances code reuse. The dm_report_field_string_list also accepts an argument to define custom delimiter to use. If not defined, a default "," (comma) is used as item delimiter in the string list reported. The dm_report_field_string_list automatically sorts the items in the list before formatting it to a final string. It also encodes the position and length within the final string where each element can be found. This can be used to support checking against each list item reported since since when formatted as a single string for the actual report, we would lose this information otherwise (we don't want to copy each item, the position and length within the final string is enough for us to get the original items back). When such lists are checked against the selection tree, we can check each item individually this way and we can support operators like "match any" and "match all".
* report: select: refactor: move str_list to libdmPeter Rajnoha2014-06-1733-84/+51
| | | | | | | | | | The list of strings is used quite frequently and we'd like to reuse this simple structure for report selection support too. Make it part of libdevmapper for general reuse throughout the code. This also simplifies the LVM code a bit since we don't need to include and manage lvm-types.h anymore (the string list was the only structure defined there).
View Lorry Controller Status