From: Jakob Oestergaard <jakob@unthought.net>
To: Roy Sigurd Karlsbakk <roy@karlsbakk.net>
Cc: Kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: AARGH! Please help. IDE controller fsckup
Date: Thu, 3 Oct 2002 13:40:20 +0200 [thread overview]
Message-ID: <20021003114020.GD7350@unthought.net> (raw)
In-Reply-To: <200210031225.11283.roy@karlsbakk.net>
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,
--
................................................................
: jakob@unthought.net : 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}...............:
next prev parent reply other threads:[~2002-10-03 11:34 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-02 13:16 AARGH! Please help. IDE controller fsckup Roy Sigurd Karlsbakk
2002-10-03 9:53 ` Jakob Oestergaard
2002-10-03 10:25 ` Roy Sigurd Karlsbakk
2002-10-03 11:40 ` Jakob Oestergaard [this message]
2002-10-03 13:13 ` Roy Sigurd Karlsbakk
2002-10-03 13:23 ` Jakob Oestergaard
2002-10-03 20:05 ` Andre Hedrick
2002-10-05 15:42 ` Roy Sigurd Karlsbakk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20021003114020.GD7350@unthought.net \
--to=jakob@unthought.net \
--cc=linux-kernel@vger.kernel.org \
--cc=roy@karlsbakk.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox