3

Today i was solving raid failure on raid10-far with four disks. One disk failed and another wasn't re-added after a hard reboot. The mdadm -D was reporting it's clean and running with only two out of four disks. When i tried to read the md array using dd if=/dev/md1 of=/dev/null, the reading failed exactly after 1.5MB with "Buffer I/O error on device md1, logical block XXX" in dmesg. Assuming I use default 512KB chunks, the inevitable thing happened: every fourth chunk, which is located on one of that two missing disks, was unavailable, according to chunk distribution in raid10-FAR http://goo.gl/5Xl7k.

Does it have some purpose, that the array can be assembled in such a bad way, or is it a bug in md-raid10-far implementation? Raid10-near can be assembled in some cases in this way, so maybe developers forgot to modify the code that decides whether it can or can't be asembled?

I use Ubuntu Server 12.04, kernel 3.2.0-26-generic, mdadm v3.2.3

Koubas
  • 51
  • 3
  • need some clarification: you're saying that mdadm reports the array as clean, but you still can't access the data? yes, i would call that a bug. – longneck Sep 10 '12 at 20:48
  • Exactly, it even caused some minor data corruption, because before i noticed what happened, i started some Xen domU from that array. I'll probably fill some bug report, wen i find where. – Koubas Sep 10 '12 at 20:56

0 Answers0