On Mon, 2017-08-14 at 14:36 +0800, Qu Wenruo wrote: > > And how are you going to write your data and checksum atomically > > when > > doing in-place updates? > > Exactly, that's the main reason I can figure out why btrfs disables > checksum for nodatacow.
Still, I don't get the problem here... Yes it cannot be done atomically (without workarounds like a journal or so), but this should be only an issue in case of a crash or similar. And in this case nodatacow+nochecksum is anyway already bad, it's also not atomic, so data may be completely garbage (e.g. half written)... just that no one will ever notice. The only problem that nodatacow + checksuming + nonatomic should give is when the data was actually correctly written at a crash, but the cheksum was not, in which case the bogus checksum would invalidate the good data on next read. Or do I miss something? To me that sounds still much better than having no protection at all. Cheers, Chris.
smime.p7s
Description: S/MIME cryptographic signature
