summaryrefslogtreecommitdiff
path: root/lib/raid
Commit message (Collapse)AuthorAgeFilesLines
* cleanup: reduce code duplictionZdenek Kabelac2021-03-191-4/+2
|
* raid: move non dm functions from DEVMAPPER ifdefZdenek Kabelac2021-03-191-57/+57
| | | | | | When lvm is compiled without device-mapper - this functions do not need this kernel support so move them from ifdef DEVMAPPER sections.
* lv_info: missing check for info.existsZdenek Kabelac2021-03-141-3/+2
| | | | | When &info is passed in, user needs to check for exists. When there is NULL, return value includes check for exists.
* targets: use target_present_versionZdenek Kabelac2021-02-081-4/+2
| | | | Skip duplicated dm version ioctl() on every startup.
* gcc: hide uninitialized warning with older gccZdenek Kabelac2021-02-011-1/+1
|
* lvdisplay: enhance LV status output for raid(0)Heinz Mauelshagen2021-01-271-0/+57
| | | | | | | | | | | | | | | | | | In case legs of a raid0 LV are removed, the lvdisplay command still reports 'available' though raid0 is not providing any resilience compared to the other raid levels. Also lvdisplay does not display '(partial)' in case of missing raid0 legs as oposed to the lvs command. Enhance lvdisplay to report "NOT available" for any RaidLV type in case too many legs are inaccessible hence causing data loss. I.e. any leg for raid0, all for raid1, more than 1 for raid4/5, more than 2 for raid6 and in case of completely lost mirror groups for raid10. Add test/shell/lvdisplay-raid.sh. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1872678
* active: fix compilation without devmapperZdenek Kabelac2020-09-291-17/+17
| | | | Better support for compilation without device-mapper.
* Revert "lvdisplay: dispaly correct status when underlying devs missing"David Teigland2020-08-281-54/+0
| | | | | | | This reverts commit 1d0dc74f9147e3c1f3681efa4166cbe2edcb6571. We should avoid adding anything new to lvdisplay and report new information via lvs reporting fields.
* lvdisplay: dispaly correct status when underlying devs missingZhao Heming2020-08-241-0/+54
| | | | | | | | | | | | | | | | | | | | | | | reproducible steps: 1. vgcreate vg1 /dev/sda /dev/sdb 2. lvcreate --type raid0 -l 100%FREE -n raid0lv vg1 3. do remove the /dev/sdb action 4. lvdisplay show wrong 'LV Status' After removing raid0 type LV underlying dev, lvdisplay still display 'available'. This is wrong status for raid0. This patch add a new function raid_is_available(), which will handle all raid case. With this patch, lvdisplay will show from: LV Status available to: LV Status NOT available (partial) Reviewed-by: Enzo Matsumiya <ematsumiya@suse.com> Signed-off-by: Zhao Heming <heming.zhao@suse.com>
* Merge branch '2018-06-04-data-structs'Joe Thornber2018-06-081-5/+6
|\
| * device_mapper: remove dbg_malloc.Joe Thornber2018-06-081-5/+6
| | | | | | | | | | I wrote dbg_malloc before we had valgrind. These days there's just no need.
* | build: drop exported symbolsZdenek Kabelac2018-06-081-1/+0
|/ | | | | This libs are no longer possible to create, drop maintanence of exported symbols.
* build: Don't generate symlinks in include/ dirJoe Thornber2018-05-141-11/+11
| | | | | | | As we start refactoring the code to break dependencies (see doc/refactoring.txt), I want us to use full paths in the includes (eg, #include "base/data-struct/list.h"). This makes it more obvious when we're breaking abstraction boundaries, eg, including a file in metadata/ from base/
* build: remove --with-{snapshots,mirrors,raid,thin,cache} options from ↵Joe Thornber2018-04-301-26/+0
| | | | | | ./configure It now behaves as if the were all set as 'internal'
* raid: fix version check of targetZdenek Kabelac2018-03-171-1/+1
| | | | | Comparision missed to check patch level for matching minor version. Howerver since all checked patchlevels were 0 - the fix doesn't change result.
* raid: add free for error pathZdenek Kabelac2018-02-281-3/+7
| | | | Recent patch forget to release now allocated 'dso' on error path.
* gcc: remove warns about free of constZdenek Kabelac2018-02-131-3/+3
|
* segtype: replace mempool allocationZdenek Kabelac2018-02-131-2/+6
| | | | | | | | | | | | | So this is a bit more complex and possibly worth futher checking. ATM clvmd drops cmd->mem mempool AFTER refresh of cmd. So anything allocating from cmd->mem during toolcontext init will likely die at some point in time. As a quick fix - just use regular malloc/free for 'dso' alloction. It's worth to note - cmd->libmem seems to be often misused causing hidden memleaking for clvmd.
* segtype: better get_monitor_dso_path apiZdenek Kabelac2018-02-121-2/+1
| | | | | | Instead of allocating always 4K for dso path, use only real needed size. Also simplify API call and move common functionality into function itself.
* cleanup: decode dso path just onceZdenek Kabelac2018-02-121-17/+14
| | | | | | | | Build dso plugin name during segtype initialisation and just use the string during command life-time. Also slightlt update message verbosity and make it very_verbose when operation is going to be made and 'verbose' when it's done.
* activation: separate reporting of error and monitoring statusZdenek Kabelac2018-02-121-2/+2
| | | | | | | | | Avoid using same return code for reporting 2 different things and stricly report error code by return value and add new parameter for reporting monitoring status. This makes easier to recognize which error we got from dm_event and continue only with ENOENT.
* raid: protect raid4 activationZdenek Kabelac2017-11-111-7/+17
| | | | | | Move check for presence of raid4 into the right place so there is no way how to hit activation of any LV with raid4 on kernel which does not support it.
* raid: fix allocation/activation of reshape spaceHeinz Mauelshagen2017-07-141-1/+8
| | | | | | | | | | | | | | When reshape space is allocated anew, an update and reload is needed to promote the new size to the cluster node with the exclusively active RaidLV or reloading the RaidLV will fail with a size related error. Additionally, store "data_offset <sectors>" with the RaidLV in the lvm2 metadata so that it can be retrieved on cluster nodes. Process allocation of reshape space on a 2-legged raid4/5 (interim layout to convert from/to linear via raid1) properly in the cluster. Resolves: rhbz1461562 Resolves: rhbz1448116
* cleanup: use 'dm_get_status_raid'Zdenek Kabelac2017-06-161-26/+11
| | | | | | Use single 'dm' call to parse raid status. (Avoiding multiple parsers - even when we know it's slighly less efficient).
* raid: adjust reshape feature flag checkHeinz Mauelshagen2017-06-161-1/+1
| | | | | | | | | | Relative to last comit ddf2a1d6564800f6d7f87e91cb8a7dfaa0edac1f: adjust the dm-raid target version to 1.12.0 which shows mandatory kernel MD deadlock fixes related to reshaping are presant in the kernel. Related: rhbz1443999
* lvconvert: linear -> raid1 upconvert should cause "recover" not "resync"Jonathan Brassow2017-06-141-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Two of the sync actions performed by the kernel (aka MD runtime) are "resync" and "recover". The "resync" refers to when an entirely new array is going through the process of initializing (or resynchronizing after an unexpected shutdown). The "recover" is the process of initializing a new member device to the array. So, a brand new array with all new devices will undergo "resync". An array with replaced or added sub-LVs will undergo "recover". These two states are treated very differently when failures happen. If any device is lost or replaced while "resync", there are no worries. This is because any writes created from the inception of the array have occurred to all the devices and can be safely recovered. Even though non-initialized portions will still be resync'ed with uninitialized data, it is ok. However, if a pre-existing device is lost (aka, the original linear device in a linear -> raid1 convert) during a "recover", data loss can be the result. Thus, writes are errored by the kernel and recovery is halted. The failed device must be restored or removed. This is the correct behavior. Unfortunately, we were treating an up-convert from linear as a "resync" when we should have been treating it as a "recover". This patch removes the special case for linear upconvert. It allows each new image sub-LV to be marked with a rebuild flag and treats the array as 'in-sync'. This has the correct effect of causing the upconvert to be treated as a "recover" rather than a "resync". There is no need to flag these two states differently in LVM metadata, because they are already considered differently by the kernel RAID metadata. (Any activation/deactivation will properly resume the "recover" process and not a "resync" process.) We make this behavior change based on the presense of dm-raid target version 1.9.0+.
* lvconvert: add segment type raid10_nearHeinz Mauelshagen2017-04-121-0/+1
| | | | | | | Introducing this alias for "raid10", avoid allocating reshape space when converting between them. Resolves: rhbz1441347
* Revert "raid: adjust to misordered raid table line output"Heinz Mauelshagen2017-03-231-22/+1
| | | | | | | This reverts commit 1e4462dbfbd2bbe3590936df24b3ccd83110b158 in favour of an enhanced solution avoiding changes in liblvm completetly by checking the target versions in libdm and emitting the respective parameter lines.
* raid: adjust to misordered raid table line outputHeinz Mauelshagen2017-03-211-1/+22
| | | | | | | | | | | | | | | | The libdevmapper interface compares existing table line retrieved from the kernel to new table line created to decide if it can suppress a reload. Any difference between input and output of the table line is taken to be a change thus causing a table reload. The dm-raid target started to misorder the raid parameters (e.g. 'raid10_copies') starting with dm-raid target version 1.9.0 up to (excluding) 1.11.0. This causes runtime failures (limited to raid10 as of tests) and needs to be reversed to allow e.g. old lvm2 uspace to run properly. Check for the aforementioned version range and adjust creation of the table line to the respective (mis)ordered sequence inside and correct order outside the range (as described for the raid target in the kernels Documentation/device-mapper/dm-raid.txt).
* raid: check target version for shrink supportHeinz Mauelshagen2017-03-171-0/+1
| | | | | | | Starting with dm-raid target version 1.9.0 shrinking of mapped devices is supported. Check for support being present in lvresize and lvreduce. Related: rhbz1394048
* raid: rework _raid_target_present()Heinz Mauelshagen2017-03-011-14/+29
| | | | | | | | | | | Recently added check for reshaping in this function called for a cleanup to avoid proliferating it with more explicit conditionals. Base the reshaping check on the given _features array. Related: rhbz834579 Related: rhbz1191935 Related: rhbz1191978
* lvconvert: adjust reshaping check to target versionHeinz Mauelshagen2017-02-281-1/+1
| | | | | | | | | | | https://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=dm-4.11&id=b08c6076782 sets the dm-raid target version to 1.10.1. Adjust the condition to set RAID_RESHAPE_FEATURE to it. Related: rhbz834579 Related: rhbz1191935 Related: rhbz1191978
* lvconvert: libdm RAID API compatibility versioningHeinz Mauelshagen2017-02-281-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 27384c52cf6a lowered the maximum number of devices back to 64 for compatibility. Because more members have been added to the API in 'struct dm_tree_node_raid_params *', we have to version the public libdm RAID API to not break any existing users. Changes: - keep the previous 'struct dm_tree_node_raid_params' and dm_tree_node_add_raid_target_with_params()/dm_tree_node_add_raid_target() in order to expose the already released public RAID API - introduce 'struct dm_tree_node_raid_params_v2' and additional functions dm_tree_node_add_raid_target_with_params_v2()/dm_tree_node_add_raid_target_v2() to be used by the new lvm2 lib reshape extentions With this new API, the bitfields for rebuild/writemostly legs in 'struct dm_tree_node_raid_params_v2' can be raised to 256 bits again (253 legs maximum supported in MD kernel). Mind that we can limit the maximum usable number via the DEFAULT_RAID{1}_MAX_IMAGES definition in defaults.h. Related: rhbz834579 Related: rhbz1191935 Related: rhbz1191978
* lvconvert: add infrastructure for RaidLV reshaping supportHeinz Mauelshagen2017-02-241-1/+1
| | | | | | | | | | | | | | | | | | | | | In order to support striped raid5/6/10 LV reshaping (change of LV type, stripesize or number of legs), this patch introduces more local infrastructure to raid_manip.c used by followup patches. Changes: - add lv_raid_data_copies returning raid type specific number; needed for raid10 with more than 2 data copies - remove _shift_and_rename_image_components() constraint to support more than 10 raid legs - add function to calculate total rimage length used by out-of-place reshape space allocation - add out-of-place reshape space alloc/relocate/free functions - move _data_rimages_count() used by reshape space alloc/realocate functions Related: rhbz834579 Related: rhbz1191935 Related: rhbz1191978
* lvconvert: add infrastructure for RaidLV reshaping supportHeinz Mauelshagen2017-02-241-39/+87
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In order to support striped raid5/6/10 LV reshaping (change of LV type, stripesize or number of legs), this patch introduces infrastructure prerequisites to be used by raid_manip.c extensions in followup patches. This base is needed for allocation of out-of-place reshape space required by the MD raid personalities to avoid writing over data in-place when reading off the current RAID layout or number of legs and writing out the new layout or to a different number of legs (i.e. restripe) Changes: - add members reshape_len to 'struct lv_segment' to store out-of-place reshape length per component rimage - add member data_copies to struct lv_segment to support more than 2 raid10 data copies - make alloc_lv_segment() aware of both reshape_len and data_copies - adjust all alloc_lv_segment() callers to the new API - add functions to retrieve the current data offset (needed for out-of-place reshaping space allocation) and the devices count from the kernel - make libdm deptree code aware of reshape_len - add LV flags for disk add/remove reshaping - support import/export of the new 'struct lv_segment' members - enhance lv_extend/_lv_reduce to cope with reshape_len - add seg_is_*/segtype_is_* macros related to reshaping - add target version check for reshaping - grow rebuilds/writemostly bitmaps to 246 bit to support kernel maximal - enhance libdm deptree code to support data_offset (out-of-place reshaping) and delta_disk (legs add/remove reshaping) target arguments Related: rhbz834579 Related: rhbz1191935 Related: rhbz1191978
* lvconvert: add segtypes raid6_{ls,rs,la,ra}_6 and conversions to/from itHeinz Mauelshagen2017-02-051-1/+5
| | | | | | | | | | | | Add: - support for segment types raid6_{ls,rs,la,ra}_6 (striped raid with dedicated last Q-Syndrome SubLVs) - conversion support from raid5_{ls,rs,la,ra} to/from raid6_{ls,rs,la,ra}_6 - setting convenient segtypes on conversions from/to raid4/5/6 - related tests to lvconvert-raid-takeover.sh factoring out _lvcreate,_lvconvert funxtions Related: rhbz1366296
* lvconvert: add segtype raid6_n_6 and conversions to/from itHeinz Mauelshagen2017-02-041-0/+1
| | | | | | | | | Add: - support for segment type raid6_n_6 (striped raid with dedicated last parity/Q-Syndrome SubLVs) - conversion support from striped/raid0/raid0_meta/raid4 to/from raid6_n_6 - related tests to lvconvert-raid-takeover.sh Related: rhbz1366296
* lvconvert: add segtype raid5_n and conversions to/from itHeinz Mauelshagen2017-02-031-7/+8
| | | | | | | | | Add: - support for segment type raid5_n (striped raid with dedicated last parity SubLVs) - conversion support from striped/raid0/raid0_meta/raid4 to/from raid5_n - related tests to lvconvert-raid-takeover.sh Related: rhbz1366296
* raid: avoid manipulation of segment statusZdenek Kabelac2016-12-131-1/+0
| | | | | | | | RAID is LV property TODO: only 2 flags are seg->status: PVMOVE & MERGING At least the second one should be soon elimanted as again we merge LV not a segment.
* raid: fix sync percent on large RaidLVsHeinz Mauelshagen2016-12-011-1/+1
| | | | Resolves: rhbz1400301
* raid: implement transient status checkZdenek Kabelac2016-11-231-0/+57
| | | | | Take into acount reported state from 'raid' targets. When raid leg is marked with 'D' - take it as missing leg.
* lvchange/vgchange/lvconvert: prevent raid4 creation/activation/conversion on ↵Heinz Mauelshagen2016-10-271-2/+8
| | | | | | | | | | | | non-supporting raid targets Check for dm-raid target version with non-standard raid4 mapping expecting the dedicated parity device in the last rather than the first slot and prohibit to create, activate or convert to such LVs from striped/raid0* or vice-versa in order to avoid data corruption. Add related tests to lvconvert-raid-takeover.sh Resolves: rhbz1388962
* raid: Don't monitor raid0 or raid0_meta LVs.Alasdair G Kergon2016-08-201-1/+6
|
* raid0: Add raid0_meta segment type.Alasdair G Kergon2016-07-011-15/+16
|
* raid0: Standardise meta_areas checks before access.Alasdair G Kergon2016-05-231-3/+3
|
* raid0: Add raid0 segment type.Alasdair G Kergon2016-05-231-38/+90
| | | | | This remains experimental and quite restrictive so should only be used for testing at this stage. (E.g. lvreduce is not supported.)
* segtype: check for activation2Zdenek Kabelac2016-05-061-0/+3
| | | | | Previous patch 8857b227645e97b7cb52ae8d007e87e07db58b4e missed to check for activation for raid target.
* activate: Use macros for target and module names.Alasdair G Kergon2016-03-221-2/+2
|
* gcc: cleanup some sign warningsZdenek Kabelac2016-02-231-1/+1
| | | | | | When comparing unsigned with int, the comparision is made as 'unsigned' type, so make it rather explicit which type is being compared.
* doc: change fsf addressZdenek Kabelac2016-01-212-2/+2
| | | | | Hmm rpmlint suggest fsf is using a different address these days, so lets keep it up-to-date
View Lorry Controller Status