From: Molle Bestefich <molle.bestefich@gmail.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: MD or MDADM bug?
Date: Tue, 6 Sep 2005 12:17:55 +0200 [thread overview]
Message-ID: <62b0912f05090603173d2c7ad2@mail.gmail.com> (raw)
In-Reply-To: <17180.62221.163087.348031@cse.unsw.edu.au>
Neil Brown wrote:
> On Monday September 5, molle.bestefich@gmail.com wrote:
> > But I definitely like autodetection a lot.
>
> Have you head the lines by Henry Wadsworth Longfellow:
> There was a little girl
> Who had a little curl
> Right in the middle of her forehead;
> And when she was good
> She was very, very good,
> But when she was bad she was horrid.
:-D. Point taken.
> > > You run
> > > mdadm -As --config=partitions --hostid=notabene
> > >
> > > then it scans all partitions for md arrays, looks at those with
> > > 'notabene' as the hostname in the 'name' field, and assembles them,
> >
> > So if you change your hostname, you have to modify your initrd?
>
> No. hostid can be a kernel parameter. Or it can be extracted from
> the hardware somehow (MAC address).
Ah, ok!
So the concept is that only the arrays "belonging" to the box will be
automatically assembled.
That's a relief, thanks for the explanation.
> I have two boxed with raid arrays. One dies. I plug the drives
> into the other and reboot it. It comes up with some bits from one
> machines and some bits from the other.
Hopefully it doesn't mix real bits from two arrays onto the same device.
> > The current implementation in MD needs a brush up in those areas too,
> > doesn't it?
> > Would something like
> >
> > [pseudo]
> >
> > // nFATLOAT: newlyFoundArraysThatLookOkAndThusShouldBeAssembled
> > MdDevice[] nFATLOAT = null;
> > do {
> > if (nFATLOAT != null) assembleArrays(nFATLOAT);
> > nFATLOAT = findUnassembledButOkArrays();
> > } while (nFATLOAT.length > 0);
> >
> > [/pseudo]
> >
> > work?
> >
>
> Should a raid5 be assembled when you have found n-1 devices,
> or do you wait for all n?
Hm, that wasn't the point of the algorithm, the point was to
correctly (and non-infinitely-looping-ly) assemble layered MD
devices automatically.
To answer your question, I'd wait till the relevant bus(s)
has been scanned before assembling n-1 arrays.
(In the context of the above pseudo code, that wait would occur
in findUnassembledButOkArrays()..)
> If you assemble as soon as you find n-1, what do you
> do when the n'th turns up?
I'd consider that a hot-add event: if the other disks have not
been modified, just add the new disk as-is, otherwise kick off
the reconstruction logic.
> I've had thoughts about allowing read-only assembly to which drives
> can be added if they are found, but nothing concrete yet.
Sounded real good when I first read it, but now I'm having
difficulties deciding whether I like the idea or not :-).
(If the context of the feature is 'automatic assembly at boot-time',
then all it would give is a small speed gain when booting. At the
expense of modifying a lot of software to be able to cope.. hmm)
> Why is it that people never complain about having to put information
> in /etc/fstab about what to mount, but they cannot cope with having to
> put similar information in /etc/mdadm.conf about what to assemble??
They've gotten a taste of the promised land.
You should've never given them autodetection in the first place :-).
Luca Berra wrote:
> in any case autodetection does not belong in the kernel.
> it is far easier to implement and maintain in userspace.
Yes, you're absolutely right. Hadn't thought of that.
next prev parent reply other threads:[~2005-09-06 10:17 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-01 21:26 MD or MDADM bug? David M. Strang
2005-09-02 6:36 ` Claas Hilbrecht
2005-09-02 6:42 ` Claas Hilbrecht
2005-09-02 8:15 ` Neil Brown
2005-09-02 8:33 ` David M. Strang
2005-09-02 8:45 ` Neil Brown
2005-09-02 8:48 ` David M. Strang
2005-09-02 9:34 ` Neil Brown
2005-09-02 9:41 ` David M. Strang
2005-09-02 10:03 ` Neil Brown
2005-09-02 10:08 ` David M. Strang
2005-09-02 11:18 ` Neil Brown
2005-09-02 21:22 ` David M. Strang
2005-09-02 21:49 ` Neil Brown
2005-09-02 23:34 ` David M. Strang
2005-09-03 3:52 ` Neil Brown
2005-09-03 8:21 ` Tyler
2005-09-04 6:18 ` Neil Brown
2005-09-05 9:20 ` danci
2005-09-05 9:35 ` Mario 'BitKoenig' Holbe
2005-09-05 16:45 ` Molle Bestefich
2005-09-05 21:13 ` Luca Berra
2005-09-06 1:38 ` Neil Brown
2005-09-06 6:38 ` bart
2005-09-06 10:17 ` Molle Bestefich [this message]
2005-09-07 2:04 ` berk walker
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=62b0912f05090603173d2c7ad2@mail.gmail.com \
--to=molle.bestefich@gmail.com \
--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).