Re: Does data checksumming remain for files with No_COW file attribute?

[Adam Borowski <kilobyte@angband.pl>]

On Sat, Sep 24, 2016 at 08:09:26PM +0200, Christoph Anton Mitterer wrote:
> On Sat, 2016-09-24 at 17:40 +0500, Roman Mamedov wrote:
> > Yes. IIRC the reasoning was that it's more difficult to track checksums
> > of data which is being overwritten in-place (as opposed to CoW).
> AFAIU it wouldn't be more difficult, since the meta-data itself is
> still subject to CoW...
> 
> There's just no guarantee in the case of a crash, that checksum and
> data match (which is IMO however a small price to pay - especially as
> the data is in that case and without CoW anyway not guaranteed to be
> valid - compared to all sorts of other silent corruptions against which
> checksums protect... not to talk about the ability to actually repair
> files in case of RAID inconsistencies.

This would require teaching btrfs that, in some cases, a csum mismatch is no
big thing and it can legitimately return junk data (like most other
filesystems) rather than complaining.  Same for scrub and btrfs check.
For now, there's a nice simple rule: bad csum is bad.

> > You can't apply chattr +C to any files of non-zero length, so by
> > definition there won't be any pre-existing checksummed extents in that
> > file.
> 
> Speaking of which,... can't one modify chattr properly so that it gives
> an error message and $? != 0 in that case?

chattr has no knowledge of btrfs whatsoever, and has no filesystem-specific
code.  It comes from e2fsprogs and from its internal naming of flags, I see
it believes everything to be ext* -- but it doesn't actually have anything
specific to ext*, either.

Thus, any other filesystem can make use of +C (FS_NOCOW_FL), and there's no
reason the "+C doesn't work on non-empty files" rule needs to hold on btrfs
in the future.


Meow!
-- 
An imaginary friend squared is a real enemy.