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
next prev parent 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 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.