[Bug 1088532] [NEW] pluging in a missing raid member does not (re)add it to array
ceg
1088532 at bugs.launchpad.net
Mon Dec 10 16:04:37 UTC 2012
Public bug reported:
12.04.1 regression (worked before, maybe without the mentioned safety
check, but it worked)
(re-add refers to speeding up the sync using a bitmap)
The --incremental (udev) call refuses to (re)add a temporarily
diconnected member back to an already restarted (active) raid. (Even
thought the event count clearly shows its state is equal or older than
at the time the array was started (run) degraded.)
And manually:
# mdadm /dev/md2 --re-add /dev/sda6
mdadm: --re-add for /dev/sda6 to /dev/md2 is not possible
# mdadm /dev/md2 --add /dev/sda6
mdadm: /dev/sda6 reports being an active member for /dev/md2, but a --re-add fails.
mdadm: not performing --add as that would convert /dev/sda6 in to a spare.
mdadm: To make this a spare, use "mdadm --zero-superblock /dev/sda6" first.
This is not how things are supposed to work in times of hotpluging.
A warning/question if the device that is to be added contains newer data
than at its time of failure is appropriate, but otherwise, get the job
of adding that device back to its raid done!
** Affects: mdadm (Ubuntu)
Importance: Undecided
Status: Confirmed
** Tags: regression-release
** Description changed:
-
+ 12.04.1
(re-add refers to speed up the sync using a bitmap)
The --incremental (udev) call refuses to (re)add the temporarily
diconnected member back to a restarted (active) raid. (Even thought the
event count clearly shows its state is equal or older than at the time
the array was started (run) degraded.)
And manually:
# mdadm /dev/md2 --re-add /dev/sda6
mdadm: --re-add for /dev/sda6 to /dev/md2 is not possible
# mdadm /dev/md2 --add /dev/sda6
mdadm: /dev/sda6 reports being an active member for /dev/md2, but a --re-add fails.
mdadm: not performing --add as that would convert /dev/sda6 in to a spare.
mdadm: To make this a spare, use "mdadm --zero-superblock /dev/sda6" first.
This is not how things are supposed to work in times of hotpluging. A
warning/question if the device that is to be added contains newer data
is appropriate, but otherwise get the job of adding that device back to
its raid done.
** Description changed:
12.04.1
(re-add refers to speed up the sync using a bitmap)
- The --incremental (udev) call refuses to (re)add the temporarily
- diconnected member back to a restarted (active) raid. (Even thought the
- event count clearly shows its state is equal or older than at the time
- the array was started (run) degraded.)
+ The --incremental (udev) call refuses to (re)add a temporarily
+ diconnected member back to an already restarted (active) raid. (Even
+ thought the event count clearly shows its state is equal or older than
+ at the time the array was started (run) degraded.)
And manually:
# mdadm /dev/md2 --re-add /dev/sda6
mdadm: --re-add for /dev/sda6 to /dev/md2 is not possible
# mdadm /dev/md2 --add /dev/sda6
mdadm: /dev/sda6 reports being an active member for /dev/md2, but a --re-add fails.
mdadm: not performing --add as that would convert /dev/sda6 in to a spare.
mdadm: To make this a spare, use "mdadm --zero-superblock /dev/sda6" first.
- This is not how things are supposed to work in times of hotpluging. A
- warning/question if the device that is to be added contains newer data
- is appropriate, but otherwise get the job of adding that device back to
- its raid done.
+ This is not how things are supposed to work in times of hotpluging.
+
+ A warning/question if the device that is to be added contains newer data
+ than at its time of failure is appropriate, but otherwise, get the job
+ of adding that device back to its raid done!
** Description changed:
- 12.04.1
- (re-add refers to speed up the sync using a bitmap)
+ 12.04.1 regression (worked before, maybe without the mentioned safety
+ check, but it worked)
+
+ (re-add refers to speeding up the sync using a bitmap)
The --incremental (udev) call refuses to (re)add a temporarily
diconnected member back to an already restarted (active) raid. (Even
thought the event count clearly shows its state is equal or older than
at the time the array was started (run) degraded.)
And manually:
# mdadm /dev/md2 --re-add /dev/sda6
mdadm: --re-add for /dev/sda6 to /dev/md2 is not possible
# mdadm /dev/md2 --add /dev/sda6
mdadm: /dev/sda6 reports being an active member for /dev/md2, but a --re-add fails.
mdadm: not performing --add as that would convert /dev/sda6 in to a spare.
mdadm: To make this a spare, use "mdadm --zero-superblock /dev/sda6" first.
This is not how things are supposed to work in times of hotpluging.
A warning/question if the device that is to be added contains newer data
than at its time of failure is appropriate, but otherwise, get the job
of adding that device back to its raid done!
** Tags added: regression-release
** Changed in: mdadm (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to mdadm in Ubuntu.
https://bugs.launchpad.net/bugs/1088532
Title:
pluging in a missing raid member does not (re)add it to array
Status in “mdadm” package in Ubuntu:
Confirmed
Bug description:
12.04.1 regression (worked before, maybe without the mentioned safety
check, but it worked)
(re-add refers to speeding up the sync using a bitmap)
The --incremental (udev) call refuses to (re)add a temporarily
diconnected member back to an already restarted (active) raid. (Even
thought the event count clearly shows its state is equal or older than
at the time the array was started (run) degraded.)
And manually:
# mdadm /dev/md2 --re-add /dev/sda6
mdadm: --re-add for /dev/sda6 to /dev/md2 is not possible
# mdadm /dev/md2 --add /dev/sda6
mdadm: /dev/sda6 reports being an active member for /dev/md2, but a --re-add fails.
mdadm: not performing --add as that would convert /dev/sda6 in to a spare.
mdadm: To make this a spare, use "mdadm --zero-superblock /dev/sda6" first.
This is not how things are supposed to work in times of hotpluging.
A warning/question if the device that is to be added contains newer
data than at its time of failure is appropriate, but otherwise, get
the job of adding that device back to its raid done!
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/1088532/+subscriptions
More information about the foundations-bugs
mailing list