Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Thu, 10 Nov 2011 19:16:51 +0000 (UTC)
From: "Sylvain Lebresne (Updated) (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: 
 <1847611345.18519.1320952611969.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1312571541.618.1320432831712.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Updated] (CASSANDRA-3456) Automatically create SHA1 of new
 sstables
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/CASSANDRA-3456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sylvain Lebresne updated CASSANDRA-3456:
----------------------------------------

    Attachment: 0001-Fix-pattern-under-window.patch

Note sure about the deletion problem but it's likely related to the other exception. I was using a split(File.separator), which won't work well on windows. Attaching patch to use Pattern.quote.
                
> 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
>             Fix For: 1.0.3
>
>         Attachments: 0001-Fix-pattern-under-window.patch, 3456.patch, system.log
>
>
> 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