linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

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