* split brain mode after reboot
@ 2012-11-20 14:08 Carsten Aulbert
2012-11-20 21:22 ` NeilBrown
0 siblings, 1 reply; 3+ messages in thread
From: Carsten Aulbert @ 2012-11-20 14:08 UTC (permalink / raw)
To: linux-raid; +Cc: gerrit.kuehn@aei.mpg.de
[-- Attachment #1: Type: text/plain, Size: 1294 bytes --]
Hi all
a colleague of mine created a raid 1 on a fairly recent machine
Kernel 3.5.0-sabayon
mdadm - v3.2.3 - 23rd December 2011
During operation sda seemed to have been disconnected by the
system/motherboard/whatever but this was not detected before a reboot
was done, after the reboot, sda re-appeared but of course with a much
older version of the mirror:
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5]
[raid4] [multipath] [faulty]
md126 : active raid1 sdb1[1]
4194240 blocks [2/1] [_U]
md127 : active raid1 sdb3[1]
235808704 blocks [2/1] [_U]
md0 : active raid1 sda1[0]
4194240 blocks [2/1] [U_]
md1 : active raid0 sda2[0] sdb2[1]
8387584 blocks 512k chunks
md2 : active raid1 sda3[0]
235808704 blocks [2/1] [U_]
unused devices: <none>
As no vital information were on these disks, my question for the list is
just if this is an expected/wanted behavior after such an event and what
one could do to prevent this (besides monitoring via mdadm).
Cheers
Carsten
--
Dr. Carsten Aulbert - Max Planck Institute for Gravitational Physics
Callinstrasse 38, 30167 Hannover, Germany
phone/fax: +49 511 762-17185 / -17193
https://wiki.atlas.aei.uni-hannover.de/foswiki/bin/view/ATLAS/WebHome
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2044 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: split brain mode after reboot
2012-11-20 14:08 split brain mode after reboot Carsten Aulbert
@ 2012-11-20 21:22 ` NeilBrown
2012-11-22 6:20 ` Carsten Aulbert
0 siblings, 1 reply; 3+ messages in thread
From: NeilBrown @ 2012-11-20 21:22 UTC (permalink / raw)
To: Carsten Aulbert; +Cc: linux-raid, gerrit.kuehn@aei.mpg.de
[-- Attachment #1: Type: text/plain, Size: 1602 bytes --]
On Tue, 20 Nov 2012 15:08:45 +0100 Carsten Aulbert
<Carsten.Aulbert@aei.mpg.de> wrote:
> Hi all
>
> a colleague of mine created a raid 1 on a fairly recent machine
>
> Kernel 3.5.0-sabayon
>
> mdadm - v3.2.3 - 23rd December 2011
>
> During operation sda seemed to have been disconnected by the
> system/motherboard/whatever but this was not detected before a reboot
> was done, after the reboot, sda re-appeared but of course with a much
> older version of the mirror:
>
> Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5]
> [raid4] [multipath] [faulty]
> md126 : active raid1 sdb1[1]
> 4194240 blocks [2/1] [_U]
>
> md127 : active raid1 sdb3[1]
> 235808704 blocks [2/1] [_U]
>
> md0 : active raid1 sda1[0]
> 4194240 blocks [2/1] [U_]
>
> md1 : active raid0 sda2[0] sdb2[1]
> 8387584 blocks 512k chunks
>
> md2 : active raid1 sda3[0]
> 235808704 blocks [2/1] [U_]
>
> unused devices: <none>
>
> As no vital information were on these disks, my question for the list is
> just if this is an expected/wanted behavior after such an event and what
> one could do to prevent this (besides monitoring via mdadm).
>
Expected - probably.
Wanted - no.
I think one half gets assembled by "mdadm --incremental" run from udev, and
the other by a subsequence "mdadm -As" or similar.
mdadm-3.3, which is still under development, has a fix for this so that
--incremental and --assemble don't trip over each other.
http://git.neil.brown.name/?p=mdadm.git;a=commitdiff;h=0431869cec4c673309d9aa
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2012-11-22 6:20 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-11-20 14:08 split brain mode after reboot Carsten Aulbert
2012-11-20 21:22 ` NeilBrown
2012-11-22 6:20 ` Carsten Aulbert
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).