[
https://issues.apache.org/jira/browse/CASSANDRA-12682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16175926#comment-16175926
]
Jeff Jirsa commented on CASSANDRA-12682:
----------------------------------------
[~aganesan] - thank you for the post. [~jasobrown] and I were actually
discussing the acknowledgements in [your
paper|https://www.usenix.org/system/files/conference/fast17/fast17-ganesan.pdf]
today and it's a shame your ticket somehow went unnoticed. I'd like to blame it
on the fact that it happened during a busy time of the year for everyone last
year (immediately after the 2016 Cassandra Summit), but the real answer is that
JIRA is high noise, and it's easy to miss tickets - for future reference, dev @
cassandra.apache.org is a much better place for feedback.
{quote}
Also, the read repair or anti-entropy can propagate the corrupted data to
other intact replicas when the corrupted value is lexically greater
{quote}
If the table is uncompressed and crc check chance is less than 1, yes. The
default config in modern versions is compression enabled and crc check chance
set to 1, so the default install SHOULD protect against that ON THE READ PATH.
{quote}
Why does Cassandra not use the CRC and digests to verify the integrity of data
in the SStables on read?
{quote}
It CAN for the compressed sstables, for uncompressed sstables we don't
currently keep checksums in small enough data chunks to make it viable at high
request rates (we'd have to amend the sstable format to embed checksums for the
uncompressed sstables - which we could certainly do)
{quote}
Are the digest.crc32 and CRC.db files ever used?
{quote}
There exists a tool that allows you to check the whole-file checksum, though
it's only used on operator demand (and it's probably likely that few operators
really use it in practice)
> Silent data corruption and corruption propagation in Cassandra
> --------------------------------------------------------------
>
> Key: CASSANDRA-12682
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12682
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Aishwarya Ganesan
> Priority: Critical
> Labels: Correctness
> Fix For: 4.x
>
>
> Corruptions in Cassandra's SSTable data can be silently returned to users if
> SSTable compression is disabled.
> Cassandra maintains a digest.crc32 and CRC.db in the sstable directory but
> fails to detect the corruptions to SSTable Data.db. Without this, Cassandra
> is vulnerable to silent corruptions resulting from underlying problems in
> disks and file systems atop them. Studies support the need for end to end
> integrity:
> https://research.cs.wisc.edu/wind/Publications/zfs-corruption-fast10.pdf
> http://www.cs.toronto.edu/~bianca/papers/fast08.pdf
> In a small test case where the underlying disk/FS corrupts a particular block
> holding the user data, Cassandra can silently return corrupted user data on a
> read request. Also, the read repair or anti-entropy can propagate the
> corrupted data to other intact replicas when the corrupted value is lexically
> greater. This is because a corruption doesn't change the timestamps and
> timestamp conflicts are resolved by choosing the data with the highest value.
> (We reproduced this scenario using our testing framework)
> Why does Cassandra not use the CRC and digests to verify the integrity of
> data in the SStables on read? Are the digest.crc32 and CRC.db files ever used?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
