From: Michael Tokarev <mjt@tls.msk.ru>
To: Janek Kozicki <janek_listy@wp.pl>
Cc: linux-raid@vger.kernel.org
Subject: Re: Auto generation of mdadm.conf
Date: Tue, 05 Feb 2008 18:34:47 +0300 [thread overview]
Message-ID: <47A88217.8070003@msgid.tls.msk.ru> (raw)
In-Reply-To: <20080205154713.0ccae001@szpak>
Janek Kozicki wrote:
> Michael Tokarev said: (by the date of Tue, 05 Feb 2008 16:52:18 +0300)
>
>> Janek Kozicki wrote:
>>> I'm not using mdadm.conf at all.
>> That's wrong, as you need at least something to identify the array
>> components.
>
> I was afraid of that ;-) So, is that a correct way to automatically
> generate a correct mdadm.conf ? I did it after some digging in man pages:
>
> echo 'DEVICE partitions' > mdadm.conf
> mdadm --examine --scan --config=mdadm.conf >> ./mdadm.conf
>
> Now, when I do 'cat mdadm.conf' i get:
>
> DEVICE partitions
> ARRAY /dev/md/0 level=raid1 metadata=1 num-devices=3 UUID=75b0f87879:539d6cee:f22092f4:7a6e6f name='backup':0
> ARRAY /dev/md/2 level=raid1 metadata=1 num-devices=3 UUID=4fd340a6c4:db01d6f7:1e03da2d:bdd574 name=backup:2
> ARRAY /dev/md/1 level=raid5 metadata=1 num-devices=3 UUID=22f22c3599:613d5231:d407a655:bdeb84 name=backup:1
Hmm. I wonder why the name for md/0 is in quotes, while others are not.
> Looks quite reasonable. Should I append it to /etc/mdadm/mdadm.conf ?
Probably... see below.
> This file currently contains: (commented lines are left out)
>
> DEVICE partitions
> CREATE owner=root group=disk mode=0660 auto=yes
> HOMEHOST <system>
> MAILADDR root
>
> This is the default content of /etc/mdadm/mdadm.conf on fresh debian
> etch install.
But now I wonder HOW your arrays gets assembled in the first place.
Let me guess... mdrun? Or maybe in-kernel auto-detection?
The thing is that mdadm will NOT assemble your arrays given this
config.
If you have your disk/controller and md drivers built into the
kernel, AND marked the partitions as "linux raid autodetect",
kernel may assemble them right at boot. But I don't remember
if the kernel will even consider v.1 superblocks for its auto-
assembly. In any way, don't rely on the kernel to do this
work, in-kernel assembly code is very simplistic and works
up to a moment when anything changes/breaks. It's almost
the same code as was in old raidtools...
Another possibility is mdrun utility (shell script) shipped
with Debian's mdadm package. It's deprecated now, but still
provided for compatibility. mdrun is even worse, it will
try to assemble ALL arrays found, giving them random names
and numbers, not handling failures correctly, and failing
badly in case of, e.g. a "foreign" disk is found which
happens to contain a valid raid superblock somewhere...
Well. There's another, 3rd possibility: mdadm can assemble
all arrays automatically (even if not listed explicitly in
mdadm.conf) using homehost (only available with v.1 superblock).
I haven't tried this option yet, so don't remember how it
works. From the mdadm(8) manpage:
Auto Assembly
When --assemble is used with --scan and no devices are listed, mdadm
will first attempt to assemble all the arrays listed in the config
file.
If a homehost has been specified (either in the config file or on the
command line), mdadm will look further for possible arrays and will try
to assemble anything that it finds which is tagged as belonging to the
given homehost. This is the only situation where mdadm will assemble
arrays without being given specific device name or identity information
for the array.
If mdadm finds a consistent set of devices that look like they should
comprise an array, and if the superblock is tagged as belonging to the
given home host, it will automatically choose a device name and try to
assemble the array. If the array uses version-0.90 metadata, then the
minor number as recorded in the superblock is used to create a name in
/dev/md/ so for example /dev/md/3. If the array uses version-1 meta‐
data, then the name from the superblock is used to similarly create a
name in /dev/md (the name will have any ’host’ prefix stripped first).
So.. probably this is the way your arrays are being assembled, since you
do have HOMEHOST in your mdadm.conf... Looks like it should work, after
all... ;) And in this case there's no need to specify additional array
information in the config file.
/mjt
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2008-02-05 15:34 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-05 10:42 Deleting mdadm RAID arrays Marcin Krol
2008-02-05 11:43 ` Moshe Yudkowsky
2008-02-06 9:35 ` Marcin Krol
2008-02-05 12:27 ` Janek Kozicki
2008-02-05 13:52 ` Michael Tokarev
2008-02-05 14:33 ` Moshe Yudkowsky
2008-02-05 15:16 ` Michael Tokarev
2008-02-05 14:47 ` Auto generation of mdadm.conf (was: Deleting mdadm RAID arrays) Janek Kozicki
2008-02-05 15:34 ` Michael Tokarev [this message]
2008-02-05 18:39 ` Auto generation of mdadm.conf Janek Kozicki
2008-02-05 20:12 ` Deleting mdadm RAID arrays Neil Brown
2008-02-06 9:55 ` Marcin Krol
2008-02-06 10:11 ` Peter Rabbitson
2008-02-06 10:32 ` Marcin Krol
2008-02-06 10:43 ` Neil Brown
2008-02-06 12:03 ` Marcin Krol
2008-02-07 2:36 ` Neil Brown
2008-02-07 9:56 ` Marcin Krol
2008-02-07 21:35 ` Bill Davidsen
2008-02-08 9:35 ` Marcin Krol
2008-02-08 12:44 ` Bill Davidsen
2008-02-08 12:52 ` Marcin Krol
2008-02-06 19:03 ` Bill Davidsen
2008-02-06 11:22 ` David Greaves
2008-02-06 11:56 ` Marcin Krol
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=47A88217.8070003@msgid.tls.msk.ru \
--to=mjt@tls.msk.ru \
--cc=janek_listy@wp.pl \
--cc=linux-raid@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).