linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jacob Schmidt Madsen <jacob@mungo.dk>
To: linux-raid@vger.kernel.org
Subject: Re: Trouble when growing a raid5 array
Date: Fri, 1 Dec 2006 12:18:29 +0100	[thread overview]
Message-ID: <200612011218.29088.jacob@mungo.dk> (raw)
In-Reply-To: <200611300804.15031.jacob@mungo.dk>

Hey again :-)

I'm starting to suspect that its a bug, since all I did was straight forward 
and it worked many times before.

When I try to stop the array by executing "mdadm -S /dev/md5", then mdadm 
stall (i'm suspecting it hit an error - maybe the same one).

I also tryed to restart the computer and made sure the array didnt auto-start. 
I then manually started it and the reshape process it shown when 
executing "cat /proc/mdstat", but it doesnt proceed (it seems stalled right 
away). When I try to stop it as shown above, it then stall mdadm like before.
So I'm able to reproduce the error.

I've tryed with kernel 2.6.18.3, 2.6.18.4 and 2.6.19 - with the same results 
as described above.

In case its a bug, then I would really like to help out, so its fixed and 
noone else will experience it (and I get my array fixed). What can I do to 
make sure its a bug and if it is, then what kind of information will be 
helpfull and where should I submit it?

I've checked the source code (raid5.c), but there's no comment included in the 
code, so I cant do much myself since my code experience with C is very small 
when it comes to kernel programming.

On Thursday 30 November 2006 08:04, Jacob Schmidt Madsen wrote:
> Hey
>
> I bought 2 new disks to be included in a big raid5 array.
>
> I executed:
> # mdadm /dev/md5 -a /dev/sdh1
> # mdadm /dev/md5 -a /dev/sdi1
> # mdadm --grow /dev/md5 --raid-disks=8
>
> After 12 hours it stalled:
> # cat /proc/mdstat
> md5 : active raid5 sdc1[6] sdb1[7] sdi1[3] sdh1[2] sdg1[1] sdf1[0] sde1[4]
> sdd1[5]
>       1562842880 blocks super 0.91 level 5, 64k chunk, algorithm 2 [8/8]
> [UUUUUUUU]
>       [===================>.]  reshape = 98.1% (306783360/312568576)
> finish=668.7min speed=144K/sec
>
> Its been stuck at 306783360/312568576 for hours now.
>
> When i check the kernel log it is full of "compute_blocknr: map not
> correct".
>
> I guess something went really bad? If someone know what is going on or if
> someone know what i can do to fix this.
> I would really be sad if all the data was gone.
>
> Thanks!
> -
> 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

  reply	other threads:[~2006-12-01 11:18 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-30  7:04 Trouble when growing a raid5 array Jacob Schmidt Madsen
2006-12-01 11:18 ` Jacob Schmidt Madsen [this message]
2006-12-08 19:29   ` Jacob Schmidt Madsen
2006-12-08 21:08     ` Jacob Schmidt Madsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200612011218.29088.jacob@mungo.dk \
    --to=jacob@mungo.dk \
    --cc=linux-raid@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).