[
https://issues.apache.org/jira/browse/CASSANDRA-3456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13146536#comment-13146536
]
Sylvain Lebresne commented on CASSANDRA-3456:
---------------------------------------------
That was fast :)
bq. Guava provides MessageDigestAlgorithm so you don't have to do the try/catch
business for built-ins
Nice, I'll update
bq. "This can only be called before any data is written to this write" sounds
like "this should be a constructor parameter" to me
It does, but given that we don't want to compute a digest for say the commit
log or other uses of SequentialWriter, pushing this in the constructor required
creating a bunch of new 'constructors' and/or have the creation
SequentialWriter takes one more boolean flag. I started with that, but it
didn't felt so beautiful.
> Automatically create SHA1 of new sstables
> -----------------------------------------
>
> Key: CASSANDRA-3456
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3456
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Sylvain Lebresne
> Assignee: Sylvain Lebresne
> Priority: Minor
> Attachments: 3456.patch
>
>
> Compressed sstables have block checksums which is great but non-compressed
> sstables don't for technical/compatibility reasons that I'm not criticizing.
> It's a bit annoying because when someone comes up with a corrupted file, we
> really have nothing to help discarding it as bitrot or not. However, it would
> be fairly trivial/cheap to compute the SHA1 (or other) of whole sstables when
> creating them. And if it's a new, separate, sstable component, we don't even
> have to implement anything to check the hash. It would only be there to
> (manually) check for bitrot when corruption is suspected by the user, or to
> say check the integrity of backups.
> I'm absolutely not pretending that it's a perfect solution, and for
> compressed sstables the block checksums are clearly more fine grained, but
> it's easy to add and could prove useful for non compressed files.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
