linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christian Iversen <chrivers@iversen-net.dk>
To: Holger Kiehl <Holger.Kiehl@dwd.de>
Cc: NeilBrown <neilb@suse.de>, linux RAID <linux-raid@vger.kernel.org>
Subject: Re: Should "mdadm --add" complain if the new device appears to have a filesystem on it?
Date: Tue, 23 Jul 2013 12:18:35 +0200	[thread overview]
Message-ID: <51EE587B.8060209@iversen-net.dk> (raw)
In-Reply-To: <alpine.LRH.2.02.1307230734590.12531@praktifix.dwd.de>

On 2013-07-23 09:41, Holger Kiehl wrote:
> Hello Neil,
>
> first, many many thanks for all your good work on MD and always helping
> us here on this list!
>
> On Tue, 23 Jul 2013, NeilBrown wrote:
>
>>
>> As you probably know, when you use "mdadm -C" to create an array, it will
>> check if the devices appear to contain a filesystem or similar already
>> and
>> will complain if they do - requiring you do say "yes" or use "--run"
>> to avoid
>> the warning.
>>
>> However if you use "--add" to add a device to an existing array no such
>> checks are done.  So it isn't too hard to destroy all those cat photos
>> you
>> have saved on a USB drive (because device names change every time you
>> boot
>> and you got confused).
>>
>>
>> I could easily change "--add" to be more cautious, but that might break
>> existing scripts, which I would rather not do.
>>
>> Or I could add a "policy" line to mdadm.conf which would indicate the
>> policy
>> for "--add" - either "spare" or "force-spare".  But then I would need to
>> decide on a default.  The default should probably be safe otherwise
>> people
>> probably won't change it until they get burned.  So people with
>> scripts would
>> still experience breakage, but could now fix it easily with a "policy"
>> line.
>>
>> Or maybe "--add" should be deprecated so people have to choose between
>> "--re-add" or a new "--spare" with --spare requiring "--force" to destroy
>> data.
>> Then "--add" would generate a deprecation message which scripts could
>> ignore
>> but people might learn from.
>>
>>
>> I don't think there is an obviously-correct answer here so I'm open to
>> suggestions.  What do people think?
>>
> I first thought of a --initialize, but I do not think it is any better.
> So I would vote for the second solution, depreciating --add and using
> --spare plus --force.

If we have to change the options anyway, then I'm more in the mood for 
--add --force for new volumes, and --add for existing ones. It would be 
more in line with what we have now, IMHO.

(please CC, not on the list)

-- 
Med venlig hilsen
Christian Iversen

  reply	other threads:[~2013-07-23 10:18 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-23  1:39 Should "mdadm --add" complain if the new device appears to have a filesystem on it? NeilBrown
2013-07-23  7:41 ` Holger Kiehl
2013-07-23 10:18   ` Christian Iversen [this message]
2013-07-23 17:17 ` Piergiorgio Sartor

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=51EE587B.8060209@iversen-net.dk \
    --to=chrivers@iversen-net.dk \
    --cc=Holger.Kiehl@dwd.de \
    --cc=linux-raid@vger.kernel.org \
    --cc=neilb@suse.de \
    /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).