From: Tsutomu Itoh <t-itoh@jp.fujitsu.com>
To: Dave Chinner <david@fromorbit.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 17:53:49 +0900 [thread overview]
Message-ID: <512C781D.1090309@jp.fujitsu.com> (raw)
In-Reply-To: <20130226070525.GP5551@dastard>
On 2013/02/26 16:05, Dave Chinner wrote:
> 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.
I apologize for my childish expression.
I'll also defer to Chris's judgement.
Thanks,
Tsutomu
>
> 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 donMy childish expression is mistaken. '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.
>
next prev parent reply other threads:[~2013-02-26 8:54 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
2013-02-26 8:53 ` Tsutomu Itoh [this message]
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=512C781D.1090309@jp.fujitsu.com \
--to=t-itoh@jp.fujitsu.com \
--cc=chris.mason@fusionio.com \
--cc=david@fromorbit.com \
--cc=dsterba@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
--cc=sandeen@redhat.com \
--cc=sbehrens@giantdisaster.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.