[
https://issues.apache.org/jira/browse/CASSANDRA-10534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Thompson updated CASSANDRA-10534:
----------------------------------------
Reproduced In: 2.1.9
Fix Version/s: 2.1.x
> CompressionInfo not being fsynced on close
> ------------------------------------------
>
> Key: CASSANDRA-10534
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10534
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Sharvanath Pathak
> Fix For: 2.1.x
>
>
> I was seeing SSTable corruption due to a CompressionInfo.db file of size 0,
> this happened multiple times in our testing with hard node reboots. After
> some investigation it seems like these file is not being fsynced, and that
> can potentially lead to data corruption. I am wroking with version 2.1.9.
> I checked for fsync calls using strace, and found them happening for all but
> the following components: CompressionInfo, TOC.txt and digest.sha1. All seem
> tolerable but the CompressionInfo seem tolerable. Also a quick look through
> the code and did not revealed any fsync calls. Moreover, I suspect the commit
> 4e95953f29d89a441dfe06d3f0393ed7dd8586df
> (https://github.com/apache/cassandra/commit/4e95953f29d89a441dfe06d3f0393ed7dd8586df#diff-b7e48a1398e39a936c11d0397d5d1966R344)
> to have caused the regression. Which removed the
> {noformat}
> getChannel().force(true);
> {noformat}
> from CompressionMetadata.Writer.close.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
