On Sat, 2016-09-24 at 23:44 +0200, Adam Borowski wrote: > 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. Well, I see no point in returning data that is not "guaranteed" to be valid. In case of a crash, one must assume that the data is bogus, and that's what the program should get. > 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. Well chattr must probably call some btrfs ioctl or so... and that should simply give an error back... and chattr at least print some generic error message. Or this should be rather replaced with a btrfs specific tool. Cheers, Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
