All of lore.kernel.org
 help / color / mirror / Atom feed
From: <ian_bruce@mail.ru>
To: linux-raid@vger.kernel.org
Subject: Re: [BUG] non-metadata arrays cannot use more than 27 component devices
Date: Fri, 24 Feb 2017 08:40:24 -0800	[thread overview]
Message-ID: <20170224084024.4dfe83a2.ian_bruce@mail.ru> (raw)
In-Reply-To: <41ea334c-ae1c-dac6-e1a1-480d3700a588@turmel.org>

On Fri, 24 Feb 2017 10:20:52 -0500
Phil Turmel <philip@turmel.org> wrote:

> Considering the existence of --build is strictly to support arrays
> that predate MD raid, it seems a bit of a stretch to claim this as a
> bug instead of a feature request.

quoting from the mdadm manual page:

    *Build*
    
    Build an array that doesn't have per-device metadata (superblocks).
    For these sorts of arrays, mdadm cannot differentiate between
    initial creation and subsequent assembly of an array. It also cannot
    perform any checks that appropriate components have been requested.
    Because of this, the Build mode should only be used together with a
    complete understanding of what you are doing.

No mention of "arrays that predate MD RAID" there. Nor any mention of a
27-component limit, either. Nor does the eventual error message mention
any such thing (although "mdadm --create --metadata=0 --raid-devices=28"
does). I'd call that a bug.

Since there's no pre-existing superblock, and the kernel has to create
one, it could just as easily use the v1.2 format as the v0.90 format, as
it does with "mdadm --create". Why shouldn't the v1.2 format be the
default for "mdadm --build" as well? That would be more consistent --
why should these two options behave differently in this regard, in the
absence of any material reason to do so?

--create : initialize v1.2 kernel superblock and write to disk

--build  : initialize v1.2 kernel superblock but don't write to disk

It seems like it would actually be simpler to treat the two cases the
same, rather than differently.


-- Ian Bruce

  reply	other threads:[~2017-02-24 16:40 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-24 12:08 [BUG] non-metadata arrays cannot use more than 27 component devices ian_bruce
2017-02-24 15:20 ` Phil Turmel
2017-02-24 16:40   ` ian_bruce [this message]
2017-02-24 20:46     ` Phil Turmel
2017-02-25 20:05       ` Anthony Youngman
2017-02-25 22:00         ` Phil Turmel
2017-02-25 23:30           ` Wols Lists
2017-02-25 23:41             ` Phil Turmel
2017-02-25 23:55               ` Wols Lists
2017-02-26  0:07                 ` Phil Turmel
2017-03-01 15:02                   ` Wols Lists
2017-03-01 17:23                     ` Phil Turmel
2017-03-01 18:13                       ` Phil Turmel
2017-03-01 19:50                         ` Anthony Youngman
2017-03-01 22:20                           ` Phil Turmel
2017-02-27  5:55 ` NeilBrown
2017-02-28 10:25   ` ian_bruce
2017-02-28 20:29     ` NeilBrown
2017-03-01 13:05       ` ian_bruce

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=20170224084024.4dfe83a2.ian_bruce@mail.ru \
    --to=ian_bruce@mail.ru \
    --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.