Re: md: bug in file md.c, line 1440 (2.4.22)

Re: md: bug in file md.c, line 1440 (2.4.22)

[Neil Brown]

On Saturday August 30, andre@tomt.net wrote:
> Heya :-)
> 
> Having a funny showstopper problem here with md, the autostart fails 
> miserably with "md: bug in file md.c, line 1440"
> 
> Here's the story;
and a sad one it is...

> md:	**********************************
> md:	* <COMPLETE RAID STATE PRINTOUT> *
> md:	**********************************
> md5: <hda9> array superblock:
> md:  SB: (V:0.90.0) ID:<80012e77.b449af86.6bccffae.ddda9474> CT:3e4caa02
> md:     L1 S24394560 ND:-22 RD:2 md5 LO:0 CS:32768
> md:     UT:3f50117d ST:1 AD:2 WD:2 FD:-24 SD:0 CSUM:a62f39ca E:0000006d
>      D  0:  DISK<N:0,hdc9(22,9),R:0,S:6>
>      D  1:  DISK<N:1,hda9(3,9),R:1,S:6>
>      D  2:  DISK<N:2,[dev 00:00](0,0),R:2,S:9>
>      D  3:  DISK<N:0,[dev 00:00](0,0),R:0,S:9>
>      D  4:  DISK<N:0,[dev 00:00](0,0),R:0,S:9>

Your problem is that these extra slots (N:0) are flagged as failed
(S:9) and this confuses md.c.

If you get mdadm 1.3.0 and apply the three patches that can be found
in
   http://cgi.cse.unsw.edu.au/~neilb/source/mdadm/patch/applied/

and then stop the array and use:
   mdadm --assemble --update=summaries /dev/md5 /dev/sda9 /dev/sdc9

then it should fix things up for you.
You will need to do a similar thing for all of the arrays.
This will be difficult for md2 as it is 'root'.  You will need to boot
a rescue disc to fix this one.

I have not idea how it got the failed flag.

NeilBrown

Re: md: bug in file md.c, line 1440 (2.4.22)

[Mike Fedyk]

On Wed, Sep 03, 2003 at 10:47:41AM +1000, Neil Brown wrote:
> I have not idea how it got the failed flag.
> 
> NeilBrown

Andre, is there any chance you ran a 2.6 kernel on that raid array?

Re: md: bug in file md.c, line 1440 (2.4.22)

[Lars Marowsky-Bree]

On 2003-09-03T10:47:41,
   Neil Brown <neilb@cse.unsw.edu.au> said:

> I have not idea how it got the failed flag.

What's proven very helpful to figure out these things is to run a
test script against md, and just trying all the various possible actions
via mdadm or raidtools randomly.

I've done that for m-p, and while it's not pretty, it is _really_
helpful and has found all sorts of weird accounting bugs in the md code
(2.4 has many): ftp://ftp.suse.com/pub/people/lmb/md-mp/mp-test.sh - if
anyone feels like extending it to include raid5/raid1 etc, that would be
cool ;-)



Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
High Availability & Clustering		ever tried. ever failed. no matter.
SuSE Labs				try again. fail again. fail better.
Research & Development, SuSE Linux AG		-- Samuel Beckett

-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: md: bug in file md.c, line 1440 (2.4.22)

[Andre Tomt]

Neil Brown wrote:
> Your problem is that these extra slots (N:0) are flagged as failed
> (S:9) and this confuses md.c.
> 
> If you get mdadm 1.3.0 and apply the three patches that can be found
> in
>    http://cgi.cse.unsw.edu.au/~neilb/source/mdadm/patch/applied/
> 
> and then stop the array and use:
>    mdadm --assemble --update=summaries /dev/md5 /dev/sda9 /dev/sdc9
> 
> then it should fix things up for you.
> You will need to do a similar thing for all of the arrays.
> This will be difficult for md2 as it is 'root'.  You will need to boot
> a rescue disc to fix this one.
> 
> I have not idea how it got the failed flag.

I didn't read this in time to get this tested - I did a full backup and 
restore earlier, zeroing all sectors on both drives. All is fine now, 
however I have no idea how this has happened. I'll set one partition 
faulty, re-add it and reboot later just to make sure it really works.

2.6 has never been booted on that machine, or disks.

Thanks, I'll keep mdadm in mind next time something like this happens ;-)

-- 
Cheers,
André Tomt
andre@tomt.net