apache/cassandra · critical · CorruptSSTableException

CorruptSSTableException (wrapped IOException from IOError, w

Error message

CorruptSSTableException (wrapped IOException from IOError, with sstable filename)

What it means

In SSTableIdentityIterator.next(), an IOError caused by an IOException during row computation is converted to CorruptSSTableException (with the sstable filename) after marking the sstable suspect; IErrors with non-IOException causes are rethrown as-is. This surfaces storage read failures during row reads as corruption errors.

Source

Thrown at src/java/org/apache/cassandra/io/sstable/SSTableIdentityIterator.java:240

            return doCompute();
        }
        catch (IndexOutOfBoundsException | VIntOutOfRangeException | AssertionError e)
        {
            sstable.markSuspect();
            throw new CorruptSSTableException(e, filename);
        }
        catch (CorruptSSTableException e) // to ensure that we marked the sstable as suspected if CorruptSSTableException is thrown from lower levels
        {
            sstable.markSuspect();
            throw e;
        }
        catch (IOError e)
        {
            if (e.getCause() instanceof IOException)
            {
                sstable.markSuspect();
                throw new CorruptSSTableException((Exception)e.getCause(), filename);
            }
            else
            {
                throw e;
            }
        }
    }

    protected Unfiltered doCompute()
    {
        Unfiltered unfiltered = iterator.next();
        UnfilteredValidation.maybeValidateUnfiltered(unfiltered, metadata(), key, sstable);
        return unfiltered;
    }

    public void close()
    {
        // creator is responsible for closing file when finished

View on GitHub (pinned to 88fd0f6a0e)

Solutions

  1. Scrub the affected table (`nodetool scrub`) to deal with the corrupt sstable named in the error
  2. Repair (`nodetool repair`) or restore the sstable from a good backup to recover the data
  3. Inspect system logs for I/O errors and remediate failing storage
  4. Prevent external modification/deletion of sstable files by non-Cassandra processes

Example fix

// before: node repeatedly failing on the same sstable
// after: scrub + repair
nodetool scrub -- keyspace table
nodetool repair -- keyspace table
Defensive patterns

Strategy: try-catch

Validate before calling

// pre-flight: confirm file readable end-to-end
// nodetool verify reads full sstables and reports I/O problems before serving traffic
verifySstableReadable(filename);

Try / catch

try {
    Row row = iter.next();
} catch (CorruptSSTableException e) {
    logger.error("I/O failure reading sstable {}", e.getPath(), e.getCause());
    // fall back to another replica; schedule repair
} catch (IOError e) {
    throw e; // non-IO failures propagate
}

Prevention

When it happens

Trigger: Calling next() when the wrapped file reader throws IOError whose cause is an IOException — e.g. underlying channel read failure, file truncated under the reader, or decompression IOException raised inside the row computation.

Common situations: Host disk or storage-backend I/O errors during reads; sstable removed/truncated by an external process; failing network-attached storage; corrupted compression chunks.

Understand the failure class

Background: "failed to read file", EACCES, ENOENT and "could not read <path>" errors: when a program can't read a file from disk — this error's family across 49 libraries.

Related errors


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