[
https://issues.apache.org/jira/browse/CASSANDRA-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782539#action_12782539
]
Jun Rao commented on CASSANDRA-193:
-----------------------------------
Some comments:
10. AES.validator.prepare() requires buffering all keys in a node in memory.
Can you push sampling into the key iterator?
11. I still think using XOR to combine MD5 for each row is simpler. In
MerkleTree.TreeRange.validateHelper(), you can compute the hash directly at
each leaf node, instead of having to descend to hashdepth.
12. Could you add some comments in MerkleTree that describe the flow of
TableRepair?
13. Some suggestions for notation changes : Node --> INode, Hash -- > LNode.
> Proactive repair
> ----------------
>
> Key: CASSANDRA-193
> URL: https://issues.apache.org/jira/browse/CASSANDRA-193
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Jonathan Ellis
> Assignee: Stu Hood
> Fix For: 0.5
>
> Attachments: 193-1-tree-preparation.diff,
> 193-1-tree-preparation.diff, 193-1-tree-preparation.diff, 193-2-tree.diff,
> 193-2-tree.diff, 193-2-tree.diff, 193-3-aes-preparation.diff,
> 193-3-aes-preparation.diff, 193-3-aes-preparation.diff, 193-4-aes.diff,
> 193-4-aes.diff, 193-4-aes.diff, 193-5-manual-repair.diff,
> 193-5-manual-repair.diff, 193-6-inverted-filter.diff,
> 193-6-inverted-filter.diff, 193-7-disable-caching-and-fix-minimum-token.diff,
> 193-breakdown.txt, 193-breakdown.txt, mktree-and-binary-tree.png
>
>
> Currently cassandra supports "read repair," i.e., lazy repair when a read is
> done. This is better than nothing but is not sufficient for some cases (e.g.
> catastrophic node failure where you need to rebuild all of a node's data on a
> new machine).
> Dynamo uses merkle trees here. This is harder for Cassandra given the CF
> data model but I suppose we could just hash the serialized CF value.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
