| Summary: | Adding disk to container causes assemblation and rebuild of stopped IMSM RAID volume | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Lukasz Dorau <lukasz.dorau> |
| Component: | mdadm | Assignee: | Doug Ledford <dledford> |
| Status: | CLOSED WONTFIX | QA Contact: | Red Hat Kernel QE team <kernel-qe> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.2 | CC: | anna.czarnowska, maciej.patelczyk |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-09-30 14:31:05 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
It is caused by 65-md-incremental.rules udev's rule:
# In case the initramfs only started some of the arrays in our container,
# run incremental assembly on the container itself. Note: we ran mdadm
# on the container in 64-md-raid.rules, and that's how the MD_LEVEL
# environment variable is already set. If that disappears from the other
# file, we will need to add this line into the middle of the next rule:
# IMPORT{program}="/sbin/mdadm -D --export $tempnode", \
SUBSYSTEM=="block", ACTION=="add|change", KERNEL=="md*", \
ENV{MD_LEVEL}=="container", RUN+="/sbin/mdadm -I $env{DEVNAME}"
As a result the command "mdadm -I /dev/md127" is issued by udev - volume is assembled and rebuild is started.
If the "change" action were removed, all would work good...
Well, we can't have it both ways. Either this acts like you want, or LVM on top of imsm arrays and stacked arrays and partially assembled arrays work properly. The md raid system first creates a raid device. That's when we get the add event. But the raid device isn't live yet (at least during incremental assembly). Only when we get enough drives to be started at least in degraded mode does the array go live, and then we don't get an add event, we get a change event. If we don't trigger an autoassemble on change events, then we will never start the arrays properly. My understanding of imsm arrays is that all discs in a container must also be included in all sub-arrays. So the fact that sdd was automatically added to and extended your raid1 array is correct. The fact that we started the rebuild from disc sdc (the one you didn't fail) is also correct. The fact that we are rebuilding onto sdd and not trying to touch sdb (the failed drive) is also correct. So, really, the only thing happening here that you don't like is that we automatically did it. And like I said, if we remove the change portion of that line, it breaks other things, most importantly degraded array startup. So, closing as WONTFIX. On SCU controller it behaves just the opposite that is just like Lukasz suggested. So is it correct in both cases? Maciej: Please check with the latest version of mdadm. Specifically, the 6.2 mdadm package contains an updated 65-md-incremental.rules file that includes the lines listed in comment #1, where as previous mdadm packages did not include the change action on the same lines in the rules file. This change was made for 6.2 specifically because devices were not getting started once the raid array went live. So, if you are using a pre-6.2 mdadm, you would not see this behavior, where as with a 6.2 mdadm, you would. The 6.2 mdadm behavior is the correct behavior in order to get various other raid bringup scenarios to work properly. |
Description of problem: Adding disk to container with no volumes inside causes assemblation and rebuild of previously stopped (degraded) IMSM RAID volume. Version-Release number of selected component (if applicable): mdadm - v3.2.2 - 17th June 2011 (Red Hat Enterprise Linux 6.2 Alpha 1) How reproducible: Always Steps to Reproduce: 1. Issue the following commands: mdadm -Ss mdadm --zero-superblock /dev/sd[b-d] mdadm -C /dev/md/imsm0 -amd -e imsm -n 2 /dev/sdb /dev/sdc -R mdadm -C /dev/md/r1d2n1s0-45 -amd -l1 --size 1G -n 2 /dev/sdb /dev/sdc -R -f mdadm --wait /dev/md/r1d2n1s0-45 mdadm -Ebs > /etc/mdadm.conf mdadm -f /dev/md/r1d2n1s0-45 /dev/sdb mdadm -S /dev/md/r1d2n1s0-45 mdadm --add /dev/md/imsm0 /dev/sdd Actual results: Stopped IMSM RAID volume is assembled and rebuild is started: # cat /proc/mdstat Personalities : [raid1] md126 : active raid1 sdd[2] sdc[0] 1048576 blocks super external:/md127/0 [2/1] [_U] [>....................] recovery = 0.0% (1024/1048576) finish=16.7min speed=1024K/sec md127 : inactive sdd[2](S) sdc[1](S) sdb[0](S) 3315 blocks super external:imsm Expected results: The disk is added to container only. The stopped IMSM RAID volume is not assembled and rebuild is not started: # cat /proc/mdstat Personalities : [raid1] md127 : inactive sdd[2](S) sdc[1](S) sdb[0](S) 3315 blocks super external:imsm