Bookmarks

Yahoo Gmail Google Facebook Delicious Twitter Reddit Stumpleupon Myspace Digg

Search queries

www.webdp.net, Event 9 IIS log failed to write entry, wwwxxx jeffs, Catastrophic failure Unexpected method call sequence. 0x8000ffff (-2147418113)., ksh lock a file, [unixODBC][Driver Manager]Driver's SQLAllocHandle on SQL_HANDLE_DBC failed, sed: -e expression #1, char 1: unterminated address regex, procmail + change subject, w2ksp4.exe download, /proc/kallsyms format

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