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

  1. Let the scrub finish — it continues without the index; verify the scrubbed output sstable afterward.
  2. Run `nodetool scrub` (or recompact) on all sstables of the table to regenerate a valid index.
  3. Check filesystem/hardware health (dmesg, SMART) for the data directory, since this indicates on-disk corruption.
  4. 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

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


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)