apache/cassandra · warning
First position reported by index should be 0, was
Error message
First position reported by index should be 0, was %d, continuing without index.
What it means
During a BTI (trie-indexed) sstable scrub, the first entry of the partition index must point to data file position 0 (the start of the first partition). If the index iterator reports any other position, the index is deemed misaligned/corrupt, so the scrubber closes it and falls back to scrubbing the data file without index assistance. This is a warning, not a fatal error: scrubbing continues in a slower, index-less mode.
Solutions
- Let the scrub finish — it continues without the index; verify the scrubbed output sstable afterward.
- Run `nodetool scrub` (or recompact) on all sstables of the table to regenerate a valid index.
- Check filesystem/hardware health (dmesg, SMART) for the data directory, since this indicates on-disk corruption.
- If reproducible on fresh writes, upgrade or check the Cassandra version for known BTI index bugs before re-enabling the format.
Example fix
// No caller-side code fix; recovery is operational. // before: sstable with corrupt BTI index reports first position != 0 // after: nodetool scrub regenerates the sstable and index without the bad index $ nodetool scrub <keyspace> <table>
Defensive patterns
Strategy: fallback
Validate before calling
// Verify sstable integrity before scrubbing
SSTableReader sstable = ...;
if (!sstable.isIndexPresent()) System.out.println("Index missing; scrub will run without index");
// or via tooling:
// sstablemetadata <Data.db> -> confirm consistent index component Prevention
- Always snapshot sstables before copying or restoring them.
- Never kill -9 during flush/compaction; drain first (nodetool drain).
- Monitor disk health (SMART/fsck) on data directories.
- Run nodetool verify periodically to catch index corruption early.
When it happens
Trigger: Running `nodetool scrub` on a BTI-format sstable whose PartitionIndex trie returns a first dataPosition() != 0, typically after partial index writes, crash mid-flush/compaction, or disk corruption affecting the index file.
Common situations: Nodes crashed or killed during memtable flush or compaction leaving a truncated/incorrect index; bit-rot or corrupted SSTable files restored from a bad backup; copying sstable files without freezing them first.
Understand the failure class
Background: Checksum mismatch errors: "checksum verification failed", "digest mismatch", "expected vs actual checksum" — what they mean and how to fix them — this error's family across 41 libraries.
Related errors
- Failed to advance to the next index position. Index is…
- Failed to go to the next entry in index
- Data file partition position
- Data file partition position
- Error reading partition
AI-assisted analysis of apache/cassandra@88fd0f6a0e (2026-09-10).
Data as JSON: /api/errors/bb7cec27a597b385.
Report an issue: GitHub.
Appendix: source
Thrown at src/java/org/apache/cassandra/io/sstable/format/bti/BtiTableScrubber.java:100
catch (Throwable t)
{
outputHandler.warn(t, "Index is unreadable, scrubbing will continue without index.");
}
return null;
}
@Override
protected UnfilteredRowIterator withValidation(UnfilteredRowIterator iter, String filename)
{
return options.checkData && !isIndex ? UnfilteredRowIterators.withValidation(iter, filename) : iter;
}
@Override
public void scrubInternal(SSTableRewriter writer)
{
if (indexAvailable() && indexIterator.dataPosition() != 0)
{
outputHandler.warn("First position reported by index should be 0, was " +
indexIterator.dataPosition() +
", continuing without index.");
indexIterator.close();
indexIterator = null;
}
DecoratedKey prevKey = null;
while (!dataFile.isEOF())
{
if (scrubInfo.isStopRequested())
throw new CompactionInterruptedException(scrubInfo.getCompactionInfo());
// position in a data file where the partition starts
long dataStart = dataFile.getFilePointer();
outputHandler.debug("Reading row at %d", dataStart);
DecoratedKey key = null;View on GitHub (pinned to 88fd0f6a0e)