Qu Wenruo wrote: >Although Btrfs can disable data CoW, nodatacow also disables data >checksum, which is another main feature for btrfs.
Then decoupling of the two should probably decoupled and support for notdatacow+checksumming be implemented?! I'm not an expert, but I wouldn't see why this shouldn't be possible (especially since metadata is AFAIC anyway *always* CoWed + checksummed). Nearly a year ago I had some off-list mails exchanged with CM and AFAIU he said it would technically be possible... What's the worst thing that can happen?! IMO, that noCoWed data would have been correctly written on a crash, but not the checksum, thereby the (bad) checksum would invalidate the actually good data. How likely is that compared to the other way round? I'd guess not so much. And even if, it's IMO still better to have then false positives (which the higher application layers should take care of anyway) than to not notice silent data corruption at all. Of course checksuming would possibly impact performance, but anyway could still use nodatacow+nochecksum (or any other fs) if he focuses more on performance than data integrity. But all those who focus on integrity would get that, even in the nodatacow case. IIRC, CM brought as an argument, that some people rather get the bad data than nothing at all (respectively EIO)... but for those btrfs is probably anyway a bad choice (at least in the normal non-nodatacow case),... also any application should properly deal with EIO... and last but not least, one could still provide a special tool that, after crash (with possibly non-matching data/csum) allows a user to find such cases and decide what to do,... so a user/admin who rather takes the bad data an tries for forensical recovery could be given a tool like btrfs csum --recompute-invalid-csums (or some better name), in which either all (or just some paths) csums are re-written in case they don't match. Cheers, Chris.
smime.p7s
Description: S/MIME cryptographic signature
