All of lore.kernel.org
 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 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.