From: Chris Murphy <lists@colorremedies.com>
To: Graham Cobb <g.btrfs@cobb.uk.net>
Cc: Chris Murphy <lists@colorremedies.com>,
Btrfs BTRFS <linux-btrfs@vger.kernel.org>,
Qu Wenruo <quwenruo.btrfs@gmx.com>
Subject: Re: MD RAID 5/6 vs BTRFS RAID 5/6
Date: Sun, 20 Oct 2019 23:41:54 +0200 [thread overview]
Message-ID: <CAJCQCtSKTJKj5xTk2aUyXCrSZ2LOCfjyB400He3Be79Vz0OUug@mail.gmail.com> (raw)
In-Reply-To: <be2aa15e-0539-219f-c2d6-fdb01297351e@cobb.uk.net>
On Thu, Oct 17, 2019 at 8:23 PM Graham Cobb <g.btrfs@cobb.uk.net> wrote:
>
> On 17/10/2019 16:57, Chris Murphy wrote:
> > On Wed, Oct 16, 2019 at 10:07 PM Jon Ander MB <jonandermonleon@gmail.com> wrote:
> >>
> >> It would be interesting to know the pros and cons of this setup that
> >> you are suggesting vs zfs.
> >> +zfs detects and corrects bitrot (
> >> http://www.zfsnas.com/2015/05/24/testing-bit-rot/ )
> >> +zfs has working raid56
> >> -modules out of kernel for license incompatibilities (a big minus)
> >>
> >> BTRFS can detect bitrot but... are we sure it can fix it? (can't seem
> >> to find any conclusive doc about it right now)
> >
> > Yes. Active fixups with scrub since 3.19. Passive fixups since 4.12.
>
> Presumably this is dependent on checksums? So neither detection nor
> fixup happen for NOCOW files? Even a scrub won't notice because scrub
> doesn't attempt to compare both copies unless the first copy has a bad
> checksum -- is that correct?
Normal read (passive) it can't be detected if nocow, since nocow means
nodatasum. If the problem happens in metadata, it's detected because
metadata is always cow and always has csum.
I'm not sure what the scrub behavior is for nocow. There's enough
information to detect a mismatch if in normal (not degraded)
operation. But I don't know if Btrfs scrub warns on this case.
> If I understand correctly, metadata always has checksums so that is true
> for filesystem structure. But for no-checksum files (such as nocow
> files) the corruption will be silent, won't it?
Corruption is always silent for nocow data. Same as any other
filesystem, it's up to the application layer to detect it.
--
Chris Murphy
next prev parent reply other threads:[~2019-10-20 21:42 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-16 15:40 MD RAID 5/6 vs BTRFS RAID 5/6 Edmund Urbani
2019-10-16 19:42 ` Zygo Blaxell
2019-10-21 15:27 ` Edmund Urbani
2019-10-21 19:34 ` Zygo Blaxell
2019-10-23 16:32 ` Edmund Urbani
2019-10-26 0:01 ` Zygo Blaxell
2019-10-17 4:07 ` Jon Ander MB
2019-10-17 15:57 ` Chris Murphy
2019-10-17 18:23 ` Graham Cobb
2019-10-20 21:41 ` Chris Murphy [this message]
2019-10-18 22:19 ` Supercilious Dude
[not found] ` <CAGmvKk4wENpDqLFZG+D8_zzjhXokjMfdbmgTKTL49EFcfdVEtQ@mail.gmail.com>
2019-10-20 21:43 ` 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=CAJCQCtSKTJKj5xTk2aUyXCrSZ2LOCfjyB400He3Be79Vz0OUug@mail.gmail.com \
--to=lists@colorremedies.com \
--cc=g.btrfs@cobb.uk.net \
--cc=linux-btrfs@vger.kernel.org \
--cc=quwenruo.btrfs@gmx.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).