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