Re: AARGH! Please help. IDE controller fsckup

[Jakob Oestergaard]

On Thu, Oct 03, 2002 at 12:25:11PM +0200, Roy Sigurd Karlsbakk wrote:
> > > so - now - the CMD649 has suddenly begun to fail - losing contact with
> > > one or two drives, and I _really_ need to get what's on /data (RAID-5 on
> > > hd[efghijklmnop]) out. Problem is - the replacement controller I've got
> > > from the vendor works fine (turns up as controller 3 serving hd[mnop]).
> > > How can I revert this most easily to be able to boot again?
> >
> > Hindsight:  had you used persistent superblocks, this would not have
> > been a problem.  The kernel would know the correct ordering from the
> > superblocks, not the device names.
> 
> I have used presistent superblocks, but md0,1,2,3 will be differently ordered 
> if I change the disk order... At least I think so. It surely didn't work.

No. md0 would stay md0.  This is another effect of using superblocks,
and in fact this is also (ironically) more or less the only argument
*against* using them   :)

(Imagine inserting a disk which knows that it is disk 0 of md0 into some
machine that already has a perfectly fine md0 running)

> 
> > Solution 1: Write to the RAID mailing list and have one of the mdadm
> > gurus give you a one-liner to initialize the array with the proper
> > ordering.
> >
> > Solution 2: Edit your /etc/raidtab to reflect the new device naming and
> > run raidstart.
> 
> ok. but this won't be neccecary with persistent superblocks? right?

right

> 
> > If you start up the array with a bad ordering, no amount of magic is
> > going to bring back you data (after parity has been "reconstructed" on
> > various chunks of your existing data).
> 
> But ... with persistent superblock - is it possible to fsckup the raid?

You're root, it is indeed possible  :)

But you would not need to perform any of the special operations that you
need to now.

Persistent superblocks saves you from a number of "bad" situations you
can encounter with normal production systems (such as replacing a
controller or moving disks around).

One should be careful when moving disks with persistent superblocks
between systems though. You don't want the kernel to autodetect the
"wrong" md0 on boot   :)    I consider this problem nonexistent in the
production environment that I administer, but I know that some people
feel differently about it.  You should consider these pros and cons in
relation to your environment and make a decision based on that.

Cheers,

-- 
................................................................
:   [e-mail]   : And I see the elder races,         :
:.........................: putrid forms of man                :
:   Jakob Østergaard      : See him rise and claim the earth,  :
:        OZ9ABN           : his downfall is at hand.           :
:.........................:............{Konkhra}...............: