Bug 832596
| Summary: | --alloc anywhere only works with raid1, not raid4, raid5, or raid6 | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Corey Marthaler <cmarthal> |
| Component: | lvm2 | Assignee: | Alasdair Kergon <agk> |
| Status: | CLOSED ERRATA | QA Contact: | Cluster QE <mspqa-list> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 6.3 | CC: | agk, dwysocha, heinzm, jbrassow, msnitzer, nperic, prajnoha, prockai, thornber, zkabelac |
| Target Milestone: | rc | Keywords: | ZStream |
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | lvm2-2.02.97-2.el6 | Doc Type: | Bug Fix |
| Doc Text: |
A bug in the space allocation logic meant that the '--alloc anywhere' option sometimes failed as it tried to allocate space on devices that were already full. This has been fixed. raid4/5/6 were particularly affected.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-02-21 08:10:44 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 852440 | ||
|
Description
Corey Marthaler
2012-06-15 21:24:13 UTC
1) The allocation section of the -vvvv trace will show what the code is actually doing. (The pasted messages are just some internal checks that detect something went wrong earlier.) 2) Let's see what the simplest failure case is. These ones have --raid4 *and* --stripes as well as the anywhere policy. Are all those parts required for this sort of failure? First idea: I induced a simple test case to add empty areas to allocated_areas[s] - which is nonsensical. (It found 1 extent for each metadata area, but nothing for any data areas.)
--- a/lib/metadata/lv_manip.c
+++ b/lib/metadata/lv_manip.c
@@ -1110,9 +1122,14 @@ static int _alloc_parallel_area(struct alloc_handle *ah, uint32_t max_to_allocat
dm_list_add(&ah->alloced_areas[s], &aa[s].list);
s -= ah->area_count + ah->parity_count;
}
+
+ aa[s].len = (ah->alloc_and_split_meta) ? len - ah->log_len : len;
+ /* Skip empty allocations */
+ if (!aa[s].len)
+ continue;
+
aa[s].pv = pva->map->pv;
aa[s].pe = pva->start;
- aa[s].len = (ah->alloc_and_split_meta) ? len - ah->log_len : len;
log_debug("Allocating parallel area %" PRIu32
" on %s start PE %" PRIu32 " length %" PRIu32 ".",
Output without the above patch: notice the incorrect allocations listed with 'length 0'. Allocating parallel metadata area 0 on /dev/loop2 start PE 3 length 1. Allocating parallel area 0 on /dev/loop2 start PE 4 length 0. Allocating parallel metadata area 1 on /dev/loop2 start PE 0 length 1. Allocating parallel area 1 on /dev/loop2 start PE 0 length 0. Allocating parallel metadata area 2 on /dev/loop3 start PE 3 length 1. Allocating parallel area 2 on /dev/loop3 start PE 4 length 0. Verified by running raid_sainty tests, except the tests which needed a missing PV due to Bug 867644 which crashes kernel if attempt is made at aprtially activating a raid LV. Verified with: lvm2-2.02.98-2.el6.x86_64 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-0501.html |