What causes "CorruptBlockException" in apache/cassandra?

Identify the file from the exception; the chunk offset/size pinpoint the corrupt region

apache/cassandra · critical · CorruptBlockException

CorruptBlockException

Error message

CorruptBlockException

What it means

During resetAndTruncate(), CompressedSequentialWriter re-reads and validates already-written chunks from disk before rewinding the file. If decompressing a chunk (compressor.uncompress) fails with an IOException, the writer throws CorruptBlockException identifying the file, chunk offset and size, indicating the on-disk data for that chunk cannot be decompressed.

Solutions

Identify the file from the exception; the chunk offset/size pinpoint the corrupt region
Run nodetool scrub (or sstablescrub) on the table to isolate/discard the corrupt chunk and rebuild readable data
Restore the affected SSTable from a backup or repair from replicas (nodetool repair)
Check disk health (smartctl/dmesg) to rule out ongoing hardware corruption

Example fix

// before
// truncate after failed flush -> uncompress of on-disk chunk fails -> CorruptBlockException
// after
nodetool scrub ks tbl
nodetool repair ks tbl

Defensive patterns

Strategy: try-catch

Validate before calling

// Validate SSTable integrity proactively
nodetool verify ks tbl
# or: sstableverify ks tbl

Try / catch

try {
    writer.resetAndTruncate(truncateLength);
} catch (CorruptSSTableException e) {
    // discard the corrupt file; recover data via scrub/repair from replicas
    filesRecovery.handleCorrupt(e.getPath());
}

Prevention

Use UPS-backed power and journaling filesystems to avoid torn writes
Run regular nodetool verify/scrub to catch corruption early
Keep replication factor >= 3 so corrupt data can be repaired from replicas
Do not change table compression parameters without rewriting existing SSTables

When it happens

Trigger: Truncating/rewinding a compressed SSTable writer (e.g. on a failed flush retry or sstable rewrite) when the chunk at the target offset is corrupt: partial write from a crash, bit rot, or a chunk written by a mismatched compressor class/params.

Common situations: Power loss or OS crash leaving partially written chunks; storage-level corruption; compression parameter changes on a table between write and truncate/replay.

Related errors

AI-assisted analysis of apache/cassandra@88fd0f6a0e (2026-09-10). Data as JSON: /api/errors/3e6f18e262cab642. Report an issue: GitHub.

Appendix: source

Thrown at src/java/org/apache/cassandra/io/compress/CompressedSequentialWriter.java:339

        {
            compressed.clear();
            compressed.limit(chunkSize);
            fchannel.position(chunkOffset);
            fchannel.read(compressed);

            try
            {
                // Repopulate buffer from compressed data
                buffer.clear();
                compressed.flip();
                if (chunkSize < maxCompressedLength)
                    compressor.uncompress(compressed, buffer);
                else
                    buffer.put(compressed);
            }
            catch (IOException e)
            {
                throw new CorruptBlockException(getPath(), chunkOffset, chunkSize, e);
            }

            CRC32 checksum = new CRC32();
            compressed.rewind();
            checksum.update(compressed);

            crcCheckBuffer.clear();
            fchannel.read(crcCheckBuffer);
            crcCheckBuffer.flip();
            if (crcCheckBuffer.getInt() != (int) checksum.getValue())
                throw new CorruptBlockException(getPath(), chunkOffset, chunkSize);
        }
        catch (CorruptBlockException e)
        {
            throw new CorruptSSTableException(e, getPath());
        }
        catch (EOFException e)
        {

View on GitHub (pinned to 88fd0f6a0e)