apache/cassandra · warning · IOException

Rebuilding index summary because offset value

Error message

Rebuilding index summary because offset value (%d) at position: %d is Big Endian while Little Endian is expected

What it means

Thrown by IndexSummary.deserialize as a heuristic endianness check: the first offset in a natively-written (little-endian) summary is inspected, and if it looks byte-reversed (Big Endian) the summary is rejected so it will be rebuilt. The on-disk summary must use little-endian (native on LE machines) offsets.

Solutions

Let Cassandra rebuild the summary (delete Summary.db for the sstable or run upgradesstables so the summary is regenerated on the local architecture)
Do not copy sstables across different-endian architectures; re-stream data via repair instead
Restore summaries only from backups taken on the same architecture

Example fix

// before: copying files from big-endian host
scp old-powerpc:/data/*.db /var/lib/cassandra/data/ks/t/
// after: rebuild summaries locally
rm /var/lib/cassandra/data/ks/t/*-Summary.db; nodetool refresh ks t

Defensive patterns

Strategy: fallback

Validate before calling

// skip regeneration: delete Summary.db when moving sstables across architectures
if (archOfSource != archOfLocal) Files.deleteIfExists(descriptor.fileFor(Components.SUMMARY).toPath());

Try / catch

try { summary.deserialize(in, partitioner, minInterval, maxInterval); } catch (IOException e) { regenerateSummaryOnLocalArch(descriptor); }

Prevention

Never copy raw sstables between big-endian and little-endian hosts; stream via repair
Delete Summary.db components when in doubt — they regenerate
Pin architecture when restoring backups

When it happens

Trigger: Loading an IndexSummary.db written on a Big Endian machine (or by a non-native-ordering writer) onto a little-endian host; first offset value fails the sanity check offsetReversed > 0 && offset > offsetReversed, or first offset negative.

Common situations: Copying sstable files between architectures (e.g. POWER/SPARC big-endian hosts to x86), corrupted summary bytes coincidentally passing the check incorrectly.

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

Appendix: source

Thrown at src/java/org/apache/cassandra/io/sstable/indexsummary/IndexSummary.java:469

                FBUtilities.copy(in, new MemoryOutputStream(offsets), offsets.size());
                FBUtilities.copy(in, new MemoryOutputStream(entries), entries.size());
            }
            catch (IOException ioe)
            {
                offsets.free();
                entries.free();
                throw ioe;
            }

            // Before 5.0 offsets were written using Native Endian, now they are stored as Little Endian,
            // so we apply a heuristic here to detect
            // if the loading index summary was created on a Big Endian machine using Native Endian format
            if (offsets.size() > 0)
            {
                int offset = offsets.getInt(0);
                int offsetReversed = Integer.reverseBytes(offset);
                if (offsetReversed > 0 && offset > offsetReversed || offset - offsets.size() < 0)
                    throw new IOException(String.format("Rebuilding index summary because offset value (%d) at position: %d " +
                                                        "is Big Endian while Little Endian is expected", offset, 0));
            }
            // our on-disk representation treats the offsets and the summary data as one contiguous structure,
            // in which the offsets are based from the start of the structure. i.e., if the offsets occupy
            // X bytes, the value of the first offset will be X. In memory we split the two regions up, so that
            // the summary values are indexed from zero, so we apply a correction to the offsets when de/serializing.
            // In this case subtracting X from each of the offsets.
            for (int i = 0 ; i < offsets.size() ; i += 4)
                offsets.setInt(i, (int) (offsets.getInt(i) - offsets.size()));
            return new IndexSummary(partitioner, offsets, offsetCount, entries, entries.size(), fullSamplingSummarySize, minIndexInterval, samplingLevel);
        }

        /**
         * Deserializes the first and last key stored in the summary
         * <p>
         * Only for use by offline tools like SSTableMetadataViewer, otherwise SSTable.first/last should be used.
         */
        public Pair<DecoratedKey, DecoratedKey> deserializeFirstLastKey(DataInputStreamPlus in, IPartitioner partitioner) throws IOException

View on GitHub (pinned to 88fd0f6a0e)