Re: RedHat 7.4 Release Notes: "Btrfs has been deprecated" - wut?

["Austin S. Hemmelgarn" <ahferroin7@gmail.com>]

On 2017-08-14 08:24, Christoph Anton Mitterer wrote:
> 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.
Assume you have higher level verification.  Would you rather not be able 
to read the data regardless of if it's correct or not, or be able to 
read it and determine yourself if it's correct or not?  For almost 
anybody, the answer is going to be the second case, because the 
application knows better than the OS if the data is correct (and 
'correct' may be a threshold, not some binary determination).  At that 
point, you need to make the checksum error a warning instead of 
returning -EIO.  How do you intend to communicate that warning back to 
the application?  The kernel log won't work, because on any reasonably 
secure system it's not visible to anyone but root.  There's also no side 
channel for the read() system calls that you can utilize.  That then 
means that the checksums end up just being a means for the administrator 
to know some data wasn't written correctly, but they should know that 
anyway because the system crashed.  As a result, the whole thing ends up 
reduced to some extra work for a pointless notification that some people 
may not even see.

Looking at this from a different angle: Without background, what would 
you assume the behavior to be for this?  For most people, the assumption 
would be that this provides the same degree of data safety that the 
checksums do when the data is CoW.  We already have enough issues with 
people misunderstanding how things work and losing data as a result 
(keep in mind that the average user doesn't read documentation and will 
often blindly follow any random advice they see online), and we don't 
need more that are liable to cause data loss.