Linux RAID subsystem development
 help / color / mirror / Atom feed
From: Joshua Kinard <kumba@gentoo.org>
To: Chris Murphy <lists@colorremedies.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: Metadata > 0.90 and auto-assemble
Date: Sun, 22 Feb 2015 16:54:12 -0500	[thread overview]
Message-ID: <54EA5004.3090104@gentoo.org> (raw)
In-Reply-To: <CAJCQCtSPPm3ipb49SCeNFvgQ21y4HseqovBPg28LKXzvP5PY8Q@mail.gmail.com>

On 02/22/2015 16:29, Chris Murphy wrote:
> On Sun, Feb 22, 2015 at 11:54 AM, Joshua Kinard <kumba@gentoo.org> wrote:
>> I'd like to
>> avoid this if possible, as I haven't had to use an initramfs for normal booting
>> in the past, as long as I stay on metadata 0.90.  So I thought I'd ask what the
>> official stance is on this.
> 
> https://raid.wiki.kernel.org/index.php/Autodetect
> 
> Official stance is that it's deprecated, but people still use it.

Yeah, but it's a pretty useful feature.  I can't see why autodetect for simple
setups (several disks or partitions and building a basic array out of them) is
maintained, while userspace autodetect is required for the more complex setups.

But I suppose this has been discussed before in detail, though I cannot find
said discussion.  The RAID Boot page has this one example only:

"This approach can cause problems in several situations (imagine moving part of
an old array onto another machine before wiping and repurposing it: reboot and
watch in horror as the piece of dead array gets assembled as part of the
running RAID array, ruining it); kernel autodetect is correspondingly deprecated."

Which I find to be rather unconvincing.  The cited example is a fault of the
user not torching the superblock before moving the disks or trying to use
them...and I've done this to myself on several occasions.  mdadm --misc
--zero-superblock and 'dd' saved the day in less than ~30s.

Are there any other discussions that might be more convincing, or offer up
other points of view?  Perhaps there's a point I've yet to consider that might
be enlightening.

Thanks!,

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

  reply	other threads:[~2015-02-22 21:54 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-22 18:54 Metadata > 0.90 and auto-assemble Joshua Kinard
2015-02-22 21:29 ` Chris Murphy
2015-02-22 21:54   ` Joshua Kinard [this message]
2015-02-23  0:17     ` NeilBrown
2015-02-22 22:19 ` Mark Knecht

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=54EA5004.3090104@gentoo.org \
    --to=kumba@gentoo.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=lists@colorremedies.com \
    /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