On Thu, Oct 17, 2019 at 8:23 PM Graham Cobb <g.bt...@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 <jonandermonl...@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
