From: Neil Brown <neilb@suse.de>
To: Piergiorgio Sartor <piergiorgio.sartor@nexgo.de>
Cc: linux-raid@vger.kernel.org
Subject: Re: [Patch] mdadm ignoring homehost?
Date: Mon, 20 Apr 2009 15:58:08 +1000 [thread overview]
Message-ID: <18924.3824.677493.129885@notabene.brown> (raw)
In-Reply-To: message from Piergiorgio Sartor on Saturday April 18
On Saturday April 18, piergiorgio.sartor@nexgo.de wrote:
> On Sat, Apr 18, 2009 at 12:19:54PM +0200, Luca Berra wrote:
> > i believe the num-devices is redundant since this value is already
> > stored in the superblock
>
> I believe too. As I mentioned, it would be possible
> to edit the outcome of "--examine --scan", but not
> really wanted.
>
> > we could change the way mdadm outputs data to put _all_ redundant
> > information in subsequent lines and keep the only required info in the
> > 'ARRAY' line,
> > so mdadm --examine --scan | grep ARRAY would be suitable for initial
> > configuration
> > or even print it only if a --verbose flag is added
> > so mdadm --examine --scan by itself would suit most need
>
> This second option I would prefer in one way or the other.
> I mean, either "mdadm --verbose --examine --scan": all info,
> or "mdadm --quiet --examine --scan": minimal info.
> One of the two would be OK, I guess (not necessarly both).
mdadm --verbose --examine (or --detail) --scan
already provided extra info not included without --verbose, that being
the list of devices that currently comprise the array.
I have just made a modification the 3.0-devel so that level= and
devices= are not reported unless --examine is given.
That just leaves metadata=, UUID= and possibly name= container=
member=, which should all be safe to have in mdadm.conf.
Thanks for the suggestion.
>
> > for the time being some akw magic can be used to parse 'mdadm --examine
> > --scan' and make it suitable for inclusion in mdadm.conf
>
> This is a possibility. It would be also OK to have a
> script, delivered together with mdadm, doing this.
> I can script myself, but a "standard solution" might
> be better.
>
> One question somehow related to this thread.
>
> I would like to have my "fixed" RAIDs as devices with a
> specific name.
> That is, something like /dev/md/root and /dev/md/lvm (for
> /dev/md0 and /dev/md1).
> In this context, I would also like to have /dev/md0 and
> /dev/md1 free to be used by other RAID.
> Of course, I've no problem in using mdadm.conf for this,
> but it seems that it is only possible something like
> /dev/mdX or /dev/md/X.
>
> Is this correct or there is some way to "personalize" the
> created device name?
Yes. If you use 0.90 metadata (still the default ... I wonder if I
should change that for 3.0..) then you need to list the name in
mdadm.conf, but
ARRAY /dev/md/foo UUID=whatever
should do what you want.
If you use 1.x metadata (e.g. 1.0), then this works nicely.
mdadm --create /dev/md/foo --metadata 1.0 --level .....
This will store the name 'foo' in the metadata and when you assemble
the array, it will be called /dev/md/foo.
This will be a symlink to /dev/md125 or something like that, but you
don't need to care.
NeilBrown
next prev parent reply other threads:[~2009-04-20 5:58 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-24 16:57 mdadm ignoring homehost? Jon Nelson
2009-04-01 15:15 ` Jon Nelson
2009-04-01 22:46 ` Neil Brown
2009-04-06 14:47 ` [Patch] " Doug Ledford
2009-04-06 19:33 ` Luca Berra
2009-04-17 3:49 ` Neil Brown
2009-04-17 7:08 ` Gabor Gombas
2009-04-20 5:23 ` Neil Brown
2009-04-21 6:34 ` Gabor Gombas
2009-04-21 7:06 ` Luca Berra
2009-04-17 18:17 ` Doug Ledford
2009-04-17 18:40 ` Piergiorgio Sartor
2009-04-18 7:54 ` Luca Berra
2009-04-18 8:36 ` Piergiorgio Sartor
2009-04-18 10:19 ` Luca Berra
2009-04-18 13:06 ` Piergiorgio Sartor
2009-04-20 5:58 ` Neil Brown [this message]
2009-04-20 12:29 ` Doug Ledford
2009-04-20 18:17 ` Piergiorgio Sartor
2009-04-20 19:49 ` Leslie Rhorer
2009-04-20 20:04 ` Piergiorgio Sartor
2009-04-20 21:18 ` Luca Berra
2009-04-20 21:13 ` Luca Berra
2009-04-20 21:24 ` Piergiorgio Sartor
2009-04-20 23:47 ` Doug Ledford
2009-04-21 0:00 ` Doug Ledford
2009-04-21 8:57 ` Michal Soltys
2009-04-21 6:29 ` Luca Berra
2009-04-21 18:15 ` Piergiorgio Sartor
2009-04-22 16:06 ` Andrew Burgess
2009-04-23 1:20 ` Doug Ledford
2009-04-23 5:51 ` Luca Berra
2009-04-23 6:09 ` Luca Berra
2009-04-23 11:05 ` Doug Ledford
2009-04-23 21:31 ` Luca Berra
2009-04-24 16:46 ` Doug Ledford
2009-04-24 19:15 ` Piergiorgio Sartor
2009-04-26 11:52 ` Doug Ledford
2009-04-26 12:14 ` Piergiorgio Sartor
2009-04-26 12:58 ` Piergiorgio Sartor
2009-04-26 18:06 ` Doug Ledford
2009-04-26 19:08 ` Piergiorgio Sartor
2009-04-26 21:37 ` Michal Soltys
2009-04-18 14:34 ` Andrew Burgess
2009-04-18 8:12 ` Luca Berra
2009-04-18 8:44 ` Piergiorgio Sartor
2009-04-18 13:35 ` Doug Ledford
2009-04-18 13:52 ` Piergiorgio Sartor
2009-04-18 14:50 ` Doug Ledford
2009-04-18 14:48 ` Jon Nelson
2009-04-20 6:08 ` Neil Brown
2009-04-20 12:26 ` Luca Berra
2009-04-20 12:36 ` Doug Ledford
2009-04-18 13:58 ` Bill Davidsen
2009-04-20 7:23 ` Neil Brown
2009-04-20 13:15 ` Doug Ledford
2009-04-21 6:54 ` Neil Brown
2009-05-11 6:47 ` Neil Brown
2009-04-01 22:47 ` Michal Soltys
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=18924.3824.677493.129885@notabene.brown \
--to=neilb@suse.de \
--cc=linux-raid@vger.kernel.org \
--cc=piergiorgio.sartor@nexgo.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 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).