[ https://issues.apache.org/jira/browse/CASSANDRA-5220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14659416#comment-14659416 ]
Stefania commented on CASSANDRA-5220: ------------------------------------- Thanks, I made a couple more really tiny changes [here|https://github.com/stef1927/cassandra/commit/dbd5c88c6f89ff303f4fece9bb8c5ffa6c3825a1]. The TODO comment above was misplaced sorry, I meant it for {{MerkleTrees}}. You're quite right that we don't need to change the existing trunk behavior. About _repair_history_, I verified it would result in an exception when upgrading from 2.2 with some sstables already on disk. Although I believe we could ask people to wipe this data on a major upgrade, I don't see why inconvenience people and so I went ahead and reverted the old format and inserted one line per rage, see commit [here|https://github.com/stef1927/cassandra/commit/92bd923a8b2d9976dc711f1b7007d25db30d06f9]. Thanks for spotting this. If you confirm these final changes are OK, then I am +1 to commit once CI completes. [~jbellis] I assume we want this on 3.0? If so I ported the patch to _cassandra-3.0_ [here|https://github.com/stef1927/cassandra/commits/5220-3.0]. It is identical to the [trunk patch|https://github.com/stef1927/cassandra/commits/5220] as it applied with no conflicts. You can pick whichever you need depending on where you want to commit to and discard the other one. CI results for trunk will appear here: http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-5220-testall/ http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-5220-dtest/ CI results for 3.0 are instead here: http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-5220-3.0-testall/ http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-5220-3.0-dtest/ > Repair improvements when using vnodes > ------------------------------------- > > Key: CASSANDRA-5220 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5220 > Project: Cassandra > Issue Type: Improvement > Components: Core > Affects Versions: 1.2.0 beta 1 > Reporter: Brandon Williams > Assignee: Marcus Olsson > Labels: performance, repair > Attachments: 5220-yourkit.png, 5220-yourkit.tar.bz2, > cassandra-3.0-5220-1.patch, cassandra-3.0-5220-2.patch, > cassandra-3.0-5220.patch > > > Currently when using vnodes, repair takes much longer to complete than > without them. This appears at least in part because it's using a session per > range and processing them sequentially. This generates a lot of log spam > with vnodes, and while being gentler and lighter on hard disk deployments, > ssd-based deployments would often prefer that repair be as fast as possible. -- This message was sent by Atlassian JIRA (v6.3.4#6332)