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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1088532

Title:
  pluging in a missing raid member does not (re)add it to array

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/1088532/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to