[
https://issues.apache.org/jira/browse/CASSANDRA-1717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13081629#comment-13081629
]
Sylvain Lebresne commented on CASSANDRA-1717:
---------------------------------------------
What are the chance we'll switch from CRC32 any time soon ? And even if we do,
why would that help us to save 4 bytes of 0's right now ? We will still have to
bump the file format versioning and to keep the code to be compatible with the
old CRC32 format if we do so. It's not like the only difference between
checksum algorithms is the size of the checksum.
So yes, 4 bytes out of 64K is not a lot of data, but to knowingly write 4 bytes
of 0's every 64k every time for the vague remote chance that it may save us 1
or 2 lines of code someday (again, that even remains to be proven) feels
ridiculous to me. But if I'm the only one to feel that way, fine, it's not a
big deal.
> Cassandra cannot detect corrupt-but-readable column data
> --------------------------------------------------------
>
> Key: CASSANDRA-1717
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1717
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Jonathan Ellis
> Assignee: Pavel Yaskevich
> Fix For: 1.0
>
> Attachments: CASSANDRA-1717-v2.patch, CASSANDRA-1717.patch,
> checksums.txt
>
>
> Most corruptions of on-disk data due to bitrot render the column (or row)
> unreadable, so the data can be replaced by read repair or anti-entropy. But
> if the corruption keeps column data readable we do not detect it, and if it
> corrupts to a higher timestamp value can even resist being overwritten by
> newer values.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
