Re: Raid1 where Event Count off my 1 cannot assemble --force

["David C. Rankin" <drankinatty@suddenlinkmail.com>]

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.
>>> 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.