linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* MD uses wrong disks to assemble an array?
@ 2004-06-11  3:22 Michael Tokarev
  2004-06-14  8:40 ` Luca Berra
  0 siblings, 1 reply; 2+ messages in thread
From: Michael Tokarev @ 2004-06-11  3:22 UTC (permalink / raw)
  To: linux-raid

A scenario happened here:

md1 (raid1) was built from 3 partitions, sd[abc]1.

Disk sdc failed, and we got a replacement, which
wasn't new, but it was a drive where I experimented
with various stuff, and it's first partition actually
was a part of another raid1 array.

Next, kernel tried to assemble the array using
START_ARRAY ioctl with /dev/sda1 as the argument.

But instead of using /dev/sda1 and /dev/sdb1, the
kernel assembled the device from /dev/sdc1 (the
replacement disk), and even assigned different
minor number to it.

And since it was root filesystem, obviously the
system was not able to boot.

I understand why it choosed the "wrong" disk:
it read superblock on the /dev/sda1, discovered
other two parts of the array, examined superblocks
there, and choosed the "freshest" component (the
one that had largest `event' counter), and next
it used all available parts of the array with
GUUID stored in that device.

Yes, START_ARRAY (used by raidtools) is deprecated,
but I understand also that mdadm in such a situation
will refuse to bring the array up, because the
GUUIDs will be different.

And I also understand that it was our mistake to
try to use disk which contained raid component on
this same partition (it was going to be repartitioned
anyway).

So the question.  What is the Right Thing (tm) to
do in such a situation?  Using the "wrong" device
as kernel did is wrong.  Refusing to run the array,
when the *specified* components are ok but other,
found by examining the superblock, component belongs
to another disk array, also seems to be wrong.  Both
ways will result in unbootable system, which is esp.
bad if a system is remote (as was in our case, and
the guy who replaced the disk was not competent
enouth to deal with this lowlevel stuff using
very limited tools available inside the initrd).
It *seems* it should be safe to bring the array
up out of the existing components, by examining
only superblocks with the same GUUID as on the
disk specified), leaving the new disk alone (if
it was the first disk which was replaced, the
system will not boot off the new disk anyway and
other existing disks should be swapped so that
the disk from current system is on sda).

Comments?

/mjt

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: MD uses wrong disks to assemble an array?
  2004-06-11  3:22 MD uses wrong disks to assemble an array? Michael Tokarev
@ 2004-06-14  8:40 ` Luca Berra
  0 siblings, 0 replies; 2+ messages in thread
From: Luca Berra @ 2004-06-14  8:40 UTC (permalink / raw)
  To: linux-raid

On Fri, Jun 11, 2004 at 07:22:17AM +0400, Michael Tokarev wrote:
>Yes, START_ARRAY (used by raidtools) is deprecated,
>but I understand also that mdadm in such a situation
>will refuse to bring the array up, because the
>GUUIDs will be different.
it depends on what you tell mdadm to do.
i created mdassemble for this very purpose, it scans a configuration
file where you should put the uids for your root md component,
in this case mdassemble will bring your root array up, even if degraded.

regards,
L.

-- 
Luca Berra -- bluca@comedia.it
        Communication Media & Services S.r.l.
 /"\
 \ /     ASCII RIBBON CAMPAIGN
  X        AGAINST HTML MAIL
 / \

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2004-06-14  8:40 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-06-11  3:22 MD uses wrong disks to assemble an array? Michael Tokarev
2004-06-14  8:40 ` Luca Berra

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