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 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.