[jira] [Comment Edited] (CASSANDRA-21694) Corrupt sstables can be zero-copy streamed to replicas

["Nivy Kani (Jira)" <ji...@apache.org>]

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

Nivy Kani edited comment on CASSANDRA-21694 at 9/28/26 8:56 PM:
----------------------------------------------------------------

Fixed to construct `FileDigestValidator` in a try-with-resources block in 4.0/4.1, which calls `close()` automatically. Also added unit tests for `DataIntegrityMetadata` in 5.0/6.0/7.0 to cover the NumberFormatException path, as suggested [here|https://github.com/apache/cassandra/pull/5182#discussion_r4117586626]. 


was (Author: JIRAUSER311854):
Fixed to construct `FileDigestValidator` in a try-with-resources block, which calls `close()` automatically. Also added unit tests for `DataIntegrityMetadata` to cover the NumberFormatException path, as suggested [here|https://github.com/apache/cassandra/pull/5182#discussion_r4117586626]. 

> Corrupt sstables can be zero-copy streamed to replicas
> ------------------------------------------------------
>
>                 Key: CASSANDRA-21694
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-21694
>             Project: Apache Cassandra
>          Issue Type: Bug
>          Components: Consistency/Streaming
>            Reporter: Nivy Kani
>            Assignee: Nivy Kani
>            Priority: Normal
>             Fix For: 4.0.x, 4.1.x, 5.0.x, 6.0-alpha3, 7.x
>
>         Attachments: 4.0-ci_summary.html, 4.0-result_details.tar.gz, 4.1-ci_summary.html, 5.0-ci_summary.html, 5.0-result_details.tar.gz, 6.0-ci_summary.html, 6.0-result_details.tar.gz, ci_summary.html, result_details.tar.gz
>
>          Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> Currently, the zero-copy path for streaming sstables differs from the chunk-based streaming path in that it doesn’t verify checksums.
> This means we have a potential data-loss bug where an sstable becomes corrupt on node A, and then zero-copy streams that sstable to node B during its bootstrap, and now the corruption exists on multiple replicas. Even though compaction catches the corruption (and excludes that sstable from future compactions, so the CRC itself isn’t rewritten), it doesn’t stop the sstable from being streamed.
> The fix is to check Digest.crc32 after zero-copy streaming but before the sstable is made visible. The digest is written when the sstable is first created on the sender, so it describes the original bytes. We maintain the benefits of zero-copy streaming, since we still never parse the sstable contents. It also makes sense to compute the checksum on only the receiver’s side so that the sender doesn’t have to read the file into user space. The cost is one re-read of the Data.db file on the receiver, which will likely be in the cache since we just wrote it. 
> Note that although we always write a Digest.32, nothing currently fails if it doesn’t exist, so this check will be fail-open. There’s also a known gap where this won’t catch if any files other than Data.db is corrupt, or if the CRC was written for a corrupt table to begin with.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org