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

  1. Verify file sizes on disk (ls -l) against the snapshot/original; restore missing/truncated data files from backup
  2. Drop the corrupt sstable and run `nodetool repair` to re-stream from replicas
  3. Scrub with --no-validate to salvage readable partitions
  4. 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

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


AI-assisted analysis of apache/cassandra@88fd0f6a0e (2026-09-10). Data as JSON: /api/errors/3231dbece9557ce1. Report an issue: GitHub.