apache/cassandra · critical · IOError
Impossible partition size (greater than file length):
Error message
Impossible partition size (greater than file length):
What it means
Thrown during BTI scrub when the partition size recorded in the index (dataSizeFromIndex) is larger than the whole data file length — an impossible value. It guards the scrubber against reading past end-of-file and indicates a corrupt index entry or truncated data file.
Source
Thrown at src/java/org/apache/cassandra/io/sstable/format/bti/BtiTableScrubber.java:182
}
}
String keyName = key == null ? "(unreadable key)" : keyString(key);
outputHandler.debug("partition %s is %s", keyName, FBUtilities.prettyPrintMemory(dataSizeFromIndex));
try
{
if (key == null)
throw new IOError(new IOException("Unable to read partition key from data file", keyReadError));
if (currentIndexKey != null && !key.getKey().equals(currentIndexKey))
{
throw new IOError(new IOException(String.format("Key from data file (%s) does not match key from index file (%s)",
ByteBufferUtil.bytesToHex(key.getKey()), ByteBufferUtil.bytesToHex(currentIndexKey))));
}
if (indexIterator != null && dataSizeFromIndex > dataFile.length())
throw new IOError(new IOException("Impossible partition size (greater than file length): " + dataSizeFromIndex));
if (indexIterator != null && dataStart != dataStartFromIndex)
outputHandler.warn("Data file partition position %d differs from index file row position %d", dataStart, dataStartFromIndex);
if (tryAppend(prevKey, key, writer))
prevKey = key;
}
catch (Throwable th)
{
throwIfFatal(th);
outputHandler.warn(th, "Error reading partition %s (stacktrace follows):", keyName);
if (currentIndexKey != null
&& (key == null || !key.getKey().equals(currentIndexKey) || dataStart != dataStartFromIndex))
{
// position where the row should start in a data file (right after the partition key)
long rowStartFromIndex = dataStartFromIndex + TypeSizes.SHORT_SIZE + currentIndexKey.remaining();View on GitHub (pinned to 88fd0f6a0e)
Solutions
- Verify file sizes on disk (ls -l) against the snapshot/original; restore missing/truncated data files from backup
- Drop the corrupt sstable and run `nodetool repair` to re-stream from replicas
- Scrub with --no-validate to salvage readable partitions
- Check storage subsystem for truncating faults
Defensive patterns
Strategy: validation
Validate before calling
// sanity check before scrub
if (dataSizeFromIndex > dataFile.length()) throw new IOException("truncated data file: index claims " + dataSizeFromIndex + " but file is " + dataFile.length()); Prevention
- Verify sstable file sizes against snapshots after restores
- Avoid killing the process during flush/compaction
- Monitor for truncated files on shared/network storage
- Run scrub with -n to keep unsalvageable files
When it happens
Trigger: Scrubbing a sstable whose Index.db entry claims a partition size exceeding the actual Data.db length, typically after data-file truncation or index corruption.
Common situations: Truncated Data.db from a crash or incomplete copy, corrupt index entries, partial restore of sstable backups.
Understand the failure class
Background: "File too large" / "file size exceeds limit" errors: why libraries cap file sizes and how to fix them — this error's family across 46 libraries.
Related errors
- Corrupt flags value for clustering prefix (isStatic flag set
- Corrupted sstable. Invalid flags found deserializing Deletio
- Failed to import sstable <filename>
- Seeking to a partition at: ${position} did not land after an
- CorruptSSTableException wrapping IOException for ${path}
AI-assisted analysis of apache/cassandra@88fd0f6a0e (2026-09-10).
Data as JSON: /api/errors/3231dbece9557ce1.
Report an issue: GitHub.