[ https://issues.apache.org/jira/browse/CASSANDRA-10534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sharvanath Pathak updated CASSANDRA-10534: ------------------------------------------ Component/s: Core > 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 > > 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 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)