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. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
