Bookmarks

Yahoo Gmail Google Facebook Delicious Twitter Reddit Stumpleupon Myspace Digg

Search queries

078274121, info0a ip, should prodicers of software_based services be held liable or not liable for economic injuries, should producers of soft ware based services such as ATMs be held liable for economic injuries suffered when their systems fail?, nisc wwwxxx, wwwxxx0cm, should producers of software-based services, such as atms, be held liable for economic injuries suffered when their systems fail?, wwwxxx0cm, www.webdp.net, Event 9 IIS log failed to write entry

Links

XODOX
Impressum

#1: Mdadm re-add fails

Posted on 2011-08-03 10:03:23 by Jan Vejvalka

Hi *,

I'm using mdadm 3.1.5 from Slackware64 13.37, for RAID1.
After running the RAID degraded for a while, I can't bring it
back.

At boot, dmesg says (correctly]:

md: considering sdb1 ...
md: adding sdb1 ...
md: adding sda1 ...
md: created md1
md: bind<sda1>
md: bind<sdb1>
md: running: <sdb1><sda1>
md: kicking non-fresh sda1 from array!
md: unbind<sda1>
md: export_rdev(sda1)
md/raid1:md1: active with 1 out of 3 mirrors

And when I try to:~# mdadm --add /dev/md1 /dev/sda1 ,
I get
mdadm: /dev/sda1 reports being an active member for /dev/md1, but a
--re-add fails.
mdadm: not performing --add as that would convert /dev/sda1 in to a spare.
mdadm: To make this a spare, use "mdadm --zero-superblock /dev/sda1" first.

I guess that for getting the array up it doesn't make much difference
to clear /dev/sda1 and to add it clear (does it ?), but it's a bit
embarrassing to find this behaviour in a moreless standard situation.

There seems to be previous conversation on this topic between Annemarie
Schmidt and Neil Brown that ends on Fri, 27 May 2011 17:16:46 -0400,
with Msg-Id
<5AA430FFE4486C448003201AC83BC85E01B0353E@xxxxxxxxxxxxxxxxxxxxx>
(at least on http://www.spinics.net/lists/raid/thrd2.html) but I'm not
sure which version of mdadm it concerns and what is the final action.

I'm ready to test a fix.

Thanks,

Jan Vejvalka
--
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

Report this message

#2: Re: Mdadm re-add fails

Posted on 2011-08-03 11:25:41 by NeilBrown

On Wed, 03 Aug 2011 10:03:23 +0200 Jan Vejvalka
<jan.vejvalka@lfmotol.cuni.cz> wrote:

> Hi *,
>
> I'm using mdadm 3.1.5 from Slackware64 13.37, for RAID1.
> After running the RAID degraded for a while, I can't bring it
> back.
>
> At boot, dmesg says (correctly]:
>
> md: considering sdb1 ...
> md: adding sdb1 ...
> md: adding sda1 ...
> md: created md1
> md: bind<sda1>
> md: bind<sdb1>
> md: running: <sdb1><sda1>
> md: kicking non-fresh sda1 from array!
> md: unbind<sda1>
> md: export_rdev(sda1)
> md/raid1:md1: active with 1 out of 3 mirrors
>
> And when I try to:~# mdadm --add /dev/md1 /dev/sda1 ,
> I get
> mdadm: /dev/sda1 reports being an active member for /dev/md1, but a
> --re-add fails.
> mdadm: not performing --add as that would convert /dev/sda1 in to a spare.
> mdadm: To make this a spare, use "mdadm --zero-superblock /dev/sda1" first.
>
> I guess that for getting the array up it doesn't make much difference
> to clear /dev/sda1 and to add it clear (does it ?), but it's a bit
> embarrassing to find this behaviour in a moreless standard situation.

Do you have a write-intent bitmap?

If yes, please report the output of "mdadm --examine" and "mdadm
--examine-bitmap" of both devices.

If no, then this is now expected behaviour. It may be a slight inconvenience
for you to have to "--zero-superblock" first, but I have seen numerous cases
where people have "--add"ed devices when they shouldn't have and had the
device turned in to a spare when they didn't want that, and so lost valuable
information.

So if there is no write-intent bitmap, the just do as the message suggests
and have a happy array again.

NeilBrown

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

Report this message