[
https://issues.apache.org/jira/browse/CASSANDRA-1717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13081685#comment-13081685
]
Sylvain Lebresne commented on CASSANDRA-1717:
---------------------------------------------
As previously said, I both disagree on using 8 bytes when we need 4 and that
using 4 is a matter for another ticket, but since this is probably me being too
anal as usual, +1 on the rest of the patch, modulo a small optional nitpick:
the toLong() function is a bit hard to read imho. It's hard to see where the
parenthesis are, and if it does the right thing. It seems ok though, I just
think a simple for loop on the bytes would be more readable. We also
historically keep ByteBufferUtil for ByteBuffer manipulations and use
FBUtilities for byte[] manipulation.
> 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
