From: Dexter Filmore <Dexter.Filmore@gmx.de>
To: Neil Brown <neilb@suse.de>, linux-raid@vger.kernel.org
Subject: Re: softraid and multiple distros
Date: Mon, 15 May 2006 14:54:27 +0200 [thread overview]
Message-ID: <200605151454.27974.Dexter.Filmore@gmx.de> (raw)
In-Reply-To: <17511.46222.221460.337788@cse.unsw.edu.au>
> I always use entire disks if I want the entire disks raided (sounds
> obvious, doesn't it...) I only use partitions when I want to vary the
> raid layout for different parts of the disk (e.g. mirrored root, mirrored
> swap, raid6 for the rest). But that certainly doesn't mean it is
> wrong to use partitions for the whole disk.
The idea behind this is: let's say a disk fails, and you get a replacement,
but it has a different geometry or a few blocks less - won't work.
Even the same disk model might vary after a while.
So I made 0xfd partitions of the size (whole disk minus few megs).
>
> > Now the devices have all two superblocks, the one left from the first try
> > which are now kinda orphaned and those now active.
> > Can I trust mdadm to handle this properly on its own?
>
> You can tell mdadm where to look. If you want to be sure that it
> won't look at entire drives, only partitions, then a line like
> DEVICES /dev/[hs]d*[0-1]
> in /etc/mdadm.conf might be what you want.
> However as you should be listing the uuids in /etc/mdadm.conf, any
Umm... yeah, should I?
> superblock with an unknown uuid will easily be ignored.
>
> If you are relying nf 0xfd autodetect to assemble your arrays, then
> obviously the entire-disk superblock will be ignored (because they
> wont be in the right place in any partition).
So mdadm --assemble --scan is fine for my scenario even with those orphaned
superblocks.
Should get me some sedatives for the day when this all explodes :P
--
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d--(+)@ s-:+ a- C+++(++++) UL+>++++ P+>++ L+++>++++ E-- W++ N o? K-
w--(---) !O M+ V- PS++(+) PE(-) Y++ PGP t++(---)@ 5 X+(++) R+(++) tv--(+)@
b++(+++) DI+++ D G++ e* h>++ r%>* y?
------END GEEK CODE BLOCK------
http://www.stop1984.com
http://www.againsttcpa.com
next prev parent reply other threads:[~2006-05-15 12:54 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-14 13:47 softraid and multiple distros Dexter Filmore
2006-05-14 14:50 ` Mark Hahn
2006-05-14 18:00 ` Dexter Filmore
2006-05-14 18:42 ` Mark Hahn
2006-05-15 11:50 ` Dexter Filmore
2006-05-15 12:16 ` Mark Hahn
2006-05-14 22:51 ` Neil Brown
2006-05-15 12:54 ` Dexter Filmore [this message]
2006-05-15 22:08 ` Neil Brown
2006-05-16 10:16 ` Dexter Filmore
2006-05-16 11:32 ` Neil Brown
2006-05-16 12:24 ` Dexter Filmore
2006-05-14 22:47 ` 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=200605151454.27974.Dexter.Filmore@gmx.de \
--to=dexter.filmore@gmx.de \
--cc=linux-raid@vger.kernel.org \
--cc=neilb@suse.de \
/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.