From: Hubert Verstraete <hubskml@free.fr>
To: linux-raid@vger.kernel.org
Subject: Re: RAID5 losing initial synchronization on restart when one disk is spare
Date: Tue, 10 Jun 2008 13:57:51 +0200 [thread overview]
Message-ID: <484E6C3F.4090204@free.fr> (raw)
In-Reply-To: <48466AD9.5@free.fr>
Hubert Verstraete wrote:
> Hello
>
> According to mdadm's man page:
> "When creating a RAID5 array, mdadm will automatically create a degraded
> array with an extra spare drive. This is because building the spare
> into a degraded array is in general faster than resyncing the parity on
> a non-degraded, but not clean, array. This feature can be over-ridden
> with the --force option."
>
> Unfortunately, I'm seeing a kind of bug when I create a RAID5 array with
> an internal bitmap, then stop the array before the initial
> synchronization is done and restart the array.
>
> 1° When I create the array with an internal bitmap:
> mdadm -C /dev/md_d1 -e 1.2 -l 5 -n 4 -b internal -R /dev/sd?
> I see the last disk as a spare disk. After the restart of the array, all
> disks are seen active and the array is not continuing the aborted
> synchronization!
> Note that I did not use the --assume-clean option.
>
> 2° When I create the array without a bitmap:
> mdadm -C /dev/md_d1 -e 1.2 -l 5 -n 4 -R /dev/sd?
> I see the last disk as a spare disk. After the restart of the array, the
> spare disk is still a spare disk and the array continues the
> synchronization where it had stopped.
>
> In the case 1°, is this a bug or did I miss something?
> Secondly, what could be the consequences of this non-performed
> synchronization ?
>
> Kernel version: 2.6.26-rc4
> mdadm version: 2.6.2
>
> Thanks,
> Hubert
For the record, the new stable kernel 2.6.25.6 has the same issue.
I thought maybe the patch "md: fix prexor vs sync_request race" could
have fixed this, unfortunately not.
Regards,
Hubert
--
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
next prev parent reply other threads:[~2008-06-10 11:57 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-04 10:13 RAID5 losing initial synchronization on restart when one disk is spare Hubert Verstraete
2008-06-10 11:57 ` Hubert Verstraete [this message]
2008-06-10 22:56 ` Dan Williams
2008-06-11 9:27 ` Hubert Verstraete
2008-06-11 23:40 ` Neil Brown
2008-06-11 14:44 ` Hubert Verstraete
2008-06-11 23:38 ` Neil Brown
2008-06-12 13:05 ` Hubert Verstraete
2008-06-12 16:59 ` Dan Williams
2008-06-12 18:11 ` Hubert Verstraete
2008-06-11 23:45 ` Neil Brown
2008-06-12 8:03 ` David Greaves
2008-06-12 17:01 ` Dan Williams
2008-06-12 9:12 ` Hubert Verstraete
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=484E6C3F.4090204@free.fr \
--to=hubskml@free.fr \
--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).