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
- Let the scrub terminate gracefully; it reports unrecoverable state rather than crashing.
- Compact or rewrite the table after scrub so index and data are regenerated consistently.
- Restore Data.db/Index.db from a snapshot and run `nodetool repair`.
- 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
- Compare sstable file sizes against sstablemetadata output after any abnormal shutdown.
- Restore from snapshots when Data.db is truncated; scrub cannot fix missing bytes.
- Enable disk-level monitoring to catch I/O error bursts early.
- Gracefully drain nodes before maintenance reboots.
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
- Data file partition position
- Data file partition position
- Error reading partition
- Error reading partition
- Failed to advance to the next index position. Index is…
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;
}
@OverrideView on GitHub (pinned to 88fd0f6a0e)