All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Fedyk <mfedyk@matchmail.com>
To: Richard Gooch <rgooch@ras.ucalgary.ca>
Cc: Luigi Genoni <kernel@Expansa.sns.it>,
	Andreas Dilger <adilger@clusterfs.com>,
	linux-kernel@vger.kernel.org
Subject: Re: RAID superblock confusion
Date: Sat, 13 Apr 2002 17:17:43 -0700	[thread overview]
Message-ID: <20020414001743.GW23513@matchmail.com> (raw)
In-Reply-To: <20020410233641.GG23513@matchmail.com> <Pine.LNX.4.44.0204111202440.17727-100000@Expansa.sns.it> <200204131929.g3DJT5g06645@vindaloo.ras.ucalgary.ca> <20020413235538.GU23513@matchmail.com> <200204140000.g3E00DX09756@vindaloo.ras.ucalgary.ca>

On Sat, Apr 13, 2002 at 06:00:13PM -0600, Richard Gooch wrote:
> Mike Fedyk writes:
> > On Sat, Apr 13, 2002 at 01:29:05PM -0600, Richard Gooch wrote:
> > > Luigi Genoni writes:
> > > > 
> > > > > > >
> > > > > > > Ehh, I ran into this a while ago.  When you compile raid as modules
> > > > > > > it doesn't use the raid superblocks for anything except for
> > > > > > > verification.  I took a quick glance at the source and the
> > > > > > > auto-detect code is ifdefed out if you compiled as a module.
> > > > > >
> > > > > > Exactly where is this? A scan with find and grep don't reveal this.
> > > > > >
> > > > >
> > > > > drivers/md/md.c
> > > > >
> > > > > in the ifndef MODULE sectioin.
> > > > >
> > > > > > > Ever since I have had raid compiled into my kernels.
> > > > > >
> > > > > > This is my relevant .config:
> > > > > > CONFIG_MD=y
> > > > > > CONFIG_BLK_DEV_MD=y
> > > > > > CONFIG_MD_LINEAR=m
> > > > > > CONFIG_MD_RAID0=m
> > > > > > CONFIG_MD_RAID1=m
> > > > > > CONFIG_MD_RAID5=m
> > > > > > CONFIG_MD_MULTIPATH=m
> > > > > >
> > > > >
> > > > > Set this to =y and you're set.
> > > > >
> > > > > I'd like to see this working from modules though.
> > > > 
> > > > NO, please. There are hundreds of scenarios where that could be
> > > > dangerous.  Suppose you load the RAID module when all partitions are
> > > > mounted, and two partiton in mirror are mount on different mount
> > > > point (you can do this, raid module is not loaded, and so...). And
> > > > now you load the module and md device is registered. That would not
> > > > be really nice, also if it is ulikely that you could damnage your
> > > > system
> > > 
> > > The RAID code checks to see if there are busy inodes for each device
> > > in a RAID set. So your hundreds of scenarios are not a problem.
> > > 
> > 
> > I had a machine that had raid1 setup correctly but was accidentally
> > configured to root=/dev/hda1 (one member of the md0 raid1 set).
> > 
> > All was well until I noticed I wasn't rooting from md0, so reboot with new
> > root=/dev/md0 and now my filesystem is b0rked (maybe because hdc1 was the
> > primary mirror?).
> > 
> > Luckily I was still setting up that machine so I just reinstalled it.
> > 
> > This was with raid compiled into the kernel, so it's not a module checking
> > issue, and I consider it a user error.  But maybe someone else thinks
> > different...
> 
> Yep, user error. Just like if you dd if=/dev/zero of=/dev/hda2 but
> meant to write to /dev/hda1 instead, and /dev/hda2 has your OS while
> /dev/hda1 had M$ which you wanted to erase and re-install. Not much to
> be done about that. One learns best by fucking up :-)
> 

One can also argue that raid (sh|c)ould lock the devices that it has been
started on also...

But it is the unix way to give the root user lots of rope to hang
him/herself, and what keeps the root user from trying to erase the entire
drive (hda instead of hda1) instead of just the locked partition?

  reply	other threads:[~2002-04-14  0:15 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-04-10 15:33 RAID superblock confusion Richard Gooch
2002-04-10 18:40 ` Andreas Dilger
2002-04-10 19:24   ` Richard Gooch
2002-04-10 19:38     ` Andreas Dilger
2002-04-10 20:37       ` Richard Gooch
2002-04-10 21:36         ` Mike Fedyk
2002-04-10 21:39           ` Richard Gooch
2002-04-10 22:09             ` Mike Fedyk
2002-04-10 22:49               ` Richard Gooch
2002-04-10 23:36                 ` Mike Fedyk
2002-04-11 10:07                   ` Luigi Genoni
2002-04-13 19:29                     ` Richard Gooch
2002-04-13 23:55                       ` Mike Fedyk
2002-04-14  0:00                         ` Richard Gooch
2002-04-14  0:17                           ` Mike Fedyk [this message]
2002-04-11  1:38         ` Neil Brown
2002-04-11  2:41           ` Mike Fedyk
2002-04-11  6:42             ` Keith Owens
2002-04-11  8:37             ` Helge Hafting
2002-04-13 19:26           ` Richard Gooch
2002-04-18  1:54             ` Neil Brown
2002-04-18  2:10               ` Mike Fedyk
2002-04-18  2:23                 ` Neil Brown
2002-04-18  2:59                   ` Mike Fedyk
2002-04-18 14:49                   ` Richard Gooch
2002-04-19 13:42                     ` Luigi Genoni
2002-04-19 13:48                       ` Richard Gooch
2002-04-20  0:50                         ` Luigi Genoni
  -- strict thread matches above, loose matches on Subject: below --
2002-04-11  3:18 Neil Brown
2002-04-11 10:19 ` Luigi Genoni
2002-04-11 20:18   ` Mike Fedyk
2002-04-18  3:05 Neil Brown

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=20020414001743.GW23513@matchmail.com \
    --to=mfedyk@matchmail.com \
    --cc=adilger@clusterfs.com \
    --cc=kernel@Expansa.sns.it \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rgooch@ras.ucalgary.ca \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.