From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Remi Gauvin <remi@georgianit.com>, linux-btrfs@vger.kernel.org
Subject: Re: Major design flaw with BTRFS Raid, temporary device drop will corrupt nodatacow files
Date: Thu, 28 Jun 2018 10:55:09 +0800 [thread overview]
Message-ID: <4852d583-4bdb-bb43-76a3-d14c9ef3f66e@gmx.com> (raw)
In-Reply-To: <3cac9d11-27f4-2d1f-c980-09cfeafa6003@georgianit.com>
[-- Attachment #1.1: Type: text/plain, Size: 1248 bytes --]
On 2018年06月28日 10:10, Remi Gauvin wrote:
> On 2018-06-27 09:58 PM, Qu Wenruo wrote:
>>
>>
>> On 2018年06月28日 09:42, Remi Gauvin wrote:
>>> There seems to be a major design flaw with BTRFS that needs to be better
>>> documented, to avoid massive data loss.
>>>
>>> Tested with Raid 1 on Ubuntu Kernel 4.15
>>>
>>> The use case being tested was a Virtualbox VDI file created with
>>> NODATACOW attribute, (as is often suggested, due to the painful
>>> performance penalty of COW on these files.)
>>
>> NODATACOW implies NODATASUM.
>>
>
> yes yes,, none of which changes the simple fact that if you use this
> option, which is often touted as outright necessary for some types of
> files, BTRFS raid is worse than useless,, not only will it not protect
> your data at all from bitrot, (as expected), it will actively go out of
> it's way to corrupt it!
>
> This is not expected behaviour from 'Raid', and I despair that seems to
> be something that I have to explain!
Nope, all normal raid1 is the same, if you corrupt one copy, you won't
know which one is correct.
Btrfs csum is already doing much better job than plain raid1.
Please get yourself clear of what other raid1 is doing.
Thanks,
Qu
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2018-06-28 2:55 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-28 1:42 Major design flaw with BTRFS Raid, temporary device drop will corrupt nodatacow files Remi Gauvin
2018-06-28 1:58 ` Qu Wenruo
2018-06-28 2:10 ` Remi Gauvin
2018-06-28 2:55 ` Qu Wenruo [this message]
2018-06-28 3:14 ` remi
2018-06-28 5:39 ` Qu Wenruo
2018-06-28 8:16 ` Andrei Borzenkov
2018-06-28 8:20 ` Andrei Borzenkov
2018-06-28 9:15 ` Qu Wenruo
2018-06-28 11:12 ` Austin S. Hemmelgarn
2018-06-28 11:46 ` Qu Wenruo
2018-06-28 12:20 ` Austin S. Hemmelgarn
2018-06-28 17:10 ` Andrei Borzenkov
2018-06-29 0:07 ` Qu Wenruo
2018-06-28 22:00 ` Remi Gauvin
2018-06-28 13:24 ` Anand Jain
2018-06-28 14:17 ` Chris Murphy
2018-06-28 15:37 ` Remi Gauvin
2018-06-28 22:04 ` Chris Murphy
2018-06-28 17:37 ` Goffredo Baroncelli
2018-06-28 22:27 ` Chris Murphy
2018-06-29 15:15 ` james harvey
2018-06-29 17:09 ` Austin S. Hemmelgarn
2018-06-29 17:58 ` james harvey
2018-06-29 18:31 ` Austin S. Hemmelgarn
2018-06-30 6:33 ` Duncan
2018-07-02 12:03 ` Austin S. Hemmelgarn
2018-06-29 18:40 ` Chris Murphy
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=4852d583-4bdb-bb43-76a3-d14c9ef3f66e@gmx.com \
--to=quwenruo.btrfs@gmx.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=remi@georgianit.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).