From: Dave Chinner <david@fromorbit.com>
To: Tsutomu Itoh <t-itoh@jp.fujitsu.com>
Cc: Eric Sandeen <sandeen@redhat.com>,
chris.mason@fusionio.com,
linux-btrfs <linux-btrfs@vger.kernel.org>,
Stefan Behrens <sbehrens@giantdisaster.de>,
David Sterba <dsterba@suse.cz>
Subject: Re: [PATCH, RFC] btrfs-progs: require mkfs -f force option to overwrite filesystem or partition table
Date: Tue, 26 Feb 2013 18:05:25 +1100 [thread overview]
Message-ID: <20130226070525.GP5551@dastard> (raw)
In-Reply-To: <512C3927.2080708@jp.fujitsu.com>
On Tue, Feb 26, 2013 at 01:25:11PM +0900, Tsutomu Itoh wrote:
> On 2013/02/26 13:06, Eric Sandeen wrote:
> >On 2/25/13 9:55 PM, Tsutomu Itoh wrote:
> >>EXPERIMENTAL... It's certainly so.
> >>However, I think that we should not add the option that it troubles
> >>a lot of people.
> >
> >Well, I sent it as an RFC. Chris merged it; I'll defer to his judgement.
>
> Agreed. So, I sent revert request to Chris :)
Where? I want to NACK the revert - this is not a matter to joke
about.
You're all smart enough to know how to use shell aliases and script
variables, so this "need to type -f all the time" argument holds
absolutely no weight at all. Further, most of the time you're
working on systems that don't hold any data you care about and so
the consequences of a mistake are very minor.
However, users often make mistakes and we have to take that into
account when deciding on the default behaviour of our tools.
Tools that destroy data *must* err on the side of conservative
default behaviour simply because of the fact that destroying the
wrong data can have catastrophic consequences. It's not your data
that is being destroyed, but it is data that you have a
*responsibility to safeguard* as a filesystem developer.
Think about it this way: how happy would an important customer be if
they decided that *you* were directly responsible for a major data
loss incident because they found it would have been prevented by the
"-f" patch? I don't think that the explanation of "it was
inconvenient to me" would be an acceptable answer.....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2013-02-26 7:05 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-14 18:30 [PATCH, RFC] btrfs-progs: require mkfs -f force option to overwrite filesystem or partition table Eric Sandeen
2013-02-14 20:23 ` Chris Mason
2013-02-14 21:20 ` Eric Sandeen
2013-02-20 15:37 ` Stefan Behrens
2013-02-25 23:39 ` Tsutomu Itoh
2013-02-26 0:07 ` Eric Sandeen
2013-02-26 3:55 ` Tsutomu Itoh
2013-02-26 4:06 ` Eric Sandeen
2013-02-26 4:25 ` Tsutomu Itoh
2013-02-26 7:05 ` Dave Chinner [this message]
2013-02-26 8:53 ` Tsutomu Itoh
2013-02-28 16:30 ` mpbtr
2013-02-26 10:37 ` Martin Steigerwald
2013-02-26 19:12 ` Goffredo Baroncelli
2013-02-26 21:16 ` Martin Steigerwald
2013-02-26 12:43 ` David Sterba
2013-02-26 20:23 ` Eric Sandeen
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=20130226070525.GP5551@dastard \
--to=david@fromorbit.com \
--cc=chris.mason@fusionio.com \
--cc=dsterba@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
--cc=sandeen@redhat.com \
--cc=sbehrens@giantdisaster.de \
--cc=t-itoh@jp.fujitsu.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;
as well as URLs for NNTP newsgroup(s).