On 12/08/2013 09:12 PM, Adam Goryachev wrote:

Probably the best option is to follow Neil's advise to use mdadm from git....

The alternative as I mentioned is to backup the data, re-create the raid +
filesystem, and then restore the data.

quoted

quoted

BTW, the bitmap location looks.... strange...

   I thought so too, but checking the other arrays, /dev/md2 has a negative
number as well:

nemtemp:/mnt # mdadm -E /dev/sda7
/dev/sda7:
<snip>
Internal Bitmap : -213 sectors from superblock
     Update Time : Mon Dec  9 02:14:18 2013

It looks strange when I first saw it, but now that I think about it, it is
probably right (correct) since 1.0 metadata is at the very end of the drive, so
the bitmap is probably before the metadata, hence negative offset.

I have an install cd with mdadm 3.3.2 on it, I'll give that a go and see what it
does with the array. The partition is only 20G, so I can just copy it to a new
drive to backup. It almost seems like I should be able to change the Events
number with a low level tool on one drive and see if that would fix the problem.

I suspect the problem is with the older mdadm. Searching, there were several
posts very similar to mine in the 2008/2009 time frame. The older mdadm probably
does not handle recovery very well.

If I do get the drive to assemble/run under mdadm 3.3.2, then is there anything
I need to do before shutting down the box to insure it will work again under 2.6
so I can at least boot it before updating mdadm? If it assembles under 3.3.2,
then I should be able to assemble/run it under 2.6.4 since the Event count would
match -- right?

-- 
David C. Rankin, J.D.,P.E.