apache/cassandra · warning

Failed to seek to next row position

Error message

Failed to seek to next row position %d

What it means

In seekToNextPartition, the BTI scrubber seeks the data file to the next index-reported position after a bad partition. If the seek itself throws (I/O error, invalid position beyond file bounds), this warning is logged, badPartitions is incremented, and the scrubber tries to advance the index iterator instead; if that also fails the scrub ends.

Solutions

  1. Let the scrub terminate gracefully; it reports unrecoverable state rather than crashing.
  2. Compact or rewrite the table after scrub so index and data are regenerated consistently.
  3. Restore Data.db/Index.db from a snapshot and run `nodetool repair`.
  4. Validate file sizes: compare Data.db length against expected sstable size; a truncated file means restore, not scrub.

Example fix

// Detect truncation before scrubbing:
// before: scrub warns 'Failed to seek to next row position <n>' (offset past EOF)
// after: check sizes then restore
$ ls -l <data_dir>/*/*-Data.db
$ sstablemetadata <path-to-Data.db>  # confirm metadata vs actual size
Defensive patterns

Strategy: validation

Validate before calling

// Detect truncated Data.db before scrubbing
long actualSize = Files.size(Paths.get(dataDbPath));
SSTableMetadataReader meta = sstablemetadata(dataDbPath);
// if actualSize is far below the recorded uncompressed/uncompressed file expectations, restore instead of scrub

Prevention

When it happens

Trigger: `nodetool scrub` recovering from a bad partition where dataFile.seek(nextRowPositionFromIndex) fails — e.g. the index points beyond the end of a truncated Data.db or the file descriptor is in an error state.

Common situations: Truncated Data.db smaller than the offsets recorded in the index; failing storage returning I/O errors on seek; severe corruption where index offsets are nonsense.

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/13f5ceb760a76848. Report an issue: GitHub.

Appendix: source

Thrown at src/java/org/apache/cassandra/io/sstable/format/bti/BtiTableScrubber.java:270

    {
        return indexIterator != null && !indexIterator.isExhausted();
    }

    private boolean seekToNextPartition()
    {
        while (indexAvailable())
        {
            long nextRowPositionFromIndex = indexIterator.dataPosition();

            try
            {
                dataFile.seek(nextRowPositionFromIndex);
                return true;
            }
            catch (Throwable th)
            {
                throwIfFatal(th);
                outputHandler.warn(th, "Failed to seek to next row position %d", nextRowPositionFromIndex);
                badPartitions++;
            }

            try
            {
                indexIterator.advance();
            }
            catch (Throwable th)
            {
                outputHandler.warn(th, "Failed to go to the next entry in index");
                throw Throwables.cleaned(th);
            }
        }

        return false;
    }

    @Override

View on GitHub (pinned to 88fd0f6a0e)