cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-3456) Automatically create SHA1 of new sstables
Date Tue, 08 Nov 2011 14:07:51 GMT

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

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

I don't think the fd thing is a real problem, because we won't need to open this component
very much, and even if we do it for scrub, we will open-read-close very quickly. I would agree
though that having too many components can get annoying. But that being said, I kind of think
this is one where having it separate does make sense for the purpose of external checking.
It is true we can have a simple external tool, but that add something to maintain that we
could avoid. So I guess I'm also a little torn though I'm leaning toward 'having a separate
component is the better choice' (but putting it in -Statistics is not much more work so if
there is preference for that, so be it).
                
> 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
>
> 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

        

Mime
View raw message