Bug 795266
| Summary: | mdadm tries to assemble arrays on partition changes | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Alexander Murashkin <alexandermurashkin> |
| Component: | mdadm | Assignee: | Doug Ledford <dledford> |
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 16 | CC: | agk, dledford, Jes.Sorensen, mbroz |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-02-21 14:15:21 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Alexander, What you are experiencing here is due to udev receiving a change event. We need to assemble on change events for various reasons, amongst others being able to run raids on top of encrypted devices. Unfortunately we cannot distinguish between a change event from a partition table update and a change event from another reason, such as an encrypted device becoming available. If you don't want arrays to be auto-assembled they need to be configured so via your /etc/mdadm.conf This is expected behaviour and not a bug. Best regards, Jes |
Description of problem: If disk partition table is updated (for example, after adding new partition) mdadm tries to incrementally assemble arrays using the disk partitions as member devices. If some of the partitions are already (or were) members of some arrays the following happens - the partition devices become open (in use) - the arrays become partially assembled (and marked inactive) - also sometimes the member devices are marked with flag S in mdstat (spare?) mdadm should ignore partition table updates (see justification below). Version-Release number of selected component (if applicable): mdadm-3.2.3-3.fc16.x86_64 mdadm-3.2.3-5.fc16.x86_64 How reproducible: Steps to Reproduce: 1. Create a partition on a disk. Create a RAID1 arrays. mdadm --create /dev/md21 --raid-devices=2 --level=raid1 /dev/sdc1 /dev/sdd1 2. Stop the arrays mdadm --stop /dev/md21 3. Update partition table on 1st disk fdisk /dev/sdc w 4. Check /proc/mdstat Actual results: md21 : inactive sdc1[0](S) 145989663 blocks super 1.2 Note that flag (S) sometimes is not shown - do not know in what cases. Expected results: mdstat shows nothing about sdc Additional info: An attempt to update disk partition table while arrays (containing the partitions) are running produces an error "Device or resource busy". So it is necessary to stop the arrays before the update. If arrays are stopped they shall remain stopped until explicitly assembled. There are following side-effects of current implementation - not possible to continue to edit partition table as partition devices become open - unexpected recovery/rebuild of arrays that were stopped on purpose - sysadm heart-attack :) when mdstat shows only one member disk in prod arrays Arrays are incrementally assembled in /lib/udev/rules.d/65-md-incremental.rules. I am not sure at the moment how to discrimanate between partition table first read (for example, at boot time) and partition table update.