Skip to content

CASSANDRA-20570: Fixed Leveled Compaction doesn't validate maxBytesFo… #4259

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: cassandra-4.1
Choose a base branch
from

Conversation

nikhilkumawat03
Copy link

Issue Description:

Fuzz testing revealed a RuntimeException in LeveledManifest.maxBytesForLevel during repair operations when compaction parameters cause the calculated maximum bytes for a level to exceed Long.MAX_VALUE (9,223,372,036,854,775,807). The error occurs with inputs like fanout_size=90, sstable_size_in_mb=1088, and level=8, resulting in Math.pow(90, 8) * 1141899264 ≈ 4.9155 × 10²⁴, which exceeds Long.MAX_VALUE. The issue arises because LeveledCompactionStrategy does not validate these parameters during table creation, allowing invalid configurations to persist until repair.

The original error (from LeveledManifest.java):

java.lang.RuntimeException: At most 9223372036854775807 bytes may be in a compaction level; your maxSSTableSize must be absurdly high to compute 4.915501902751334E24

This PR adds proactive validation in LeveledCompactionStrategy.validateOptions to ensure fanout_size and sstable_size_in_mb do not cause an overflow, throwing a ConfigurationException during CREATE TABLE or ALTER TABLE instead of failing later during repair.

Example which created issue during fuzz testing (CASSANDRA-20570)

CREATE KEYSPACE test WITH replication = {'class': 'SimpleStrategy', 'replication_factor': 1};
CREATE TABLE test.table1 (k int PRIMARY KEY, v int)
    WITH compaction = {
        'class': 'LeveledCompactionStrategy',
        'fanout_size': '90',
        'sstable_size_in_mb': '1088'
    };

Patch by: Nikhil Kumawat;
Reviewed by: TBD
JIRA: CASSANDRA-20570

@nikhilkumawat03 nikhilkumawat03 force-pushed the cassandra-20570-4.1 branch 2 times, most recently from 39f914f to 3c43f59 Compare July 17, 2025 15:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant