[ 
https://issues.apache.org/jira/browse/CASSANDRA-3456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13146534#comment-13146534
 ] 

Sylvain Lebresne commented on CASSANDRA-3456:
---------------------------------------------

Patch attached. It creates a new component, say Standard1-h-16-Digest.sha1, 
that is can be directly checked by sha1sum ({{ sha1sum -c 
Standard1-h-16-Digest.sha1 }}).

Not that the sha1 is only created for non-compressed files since compressed 
files have more fine-grained checksums, but we could change it easily. I also 
didn't added anything in Cassandra itself that check the sha1 sum. We can add 
it to say scrub, but we would have to read entirely the file before the scrub 
to compute the sha1, and I don't see the point of adding that time to scrub (at 
least until CASSANDRA-3406 while scrub is used for much more that corruption 
detection/correction). Besides, sha1sum does that well already.
                
> 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

        

Reply via email to