Cassandra RC2 fixes first-start direct I/O detection
Cassandra 5.0 RC2 corrects a capability probe that ran before its directory existed. A second fix maps a supported memtable allocation mode to its buffer type.
A missing directory can make a capability check answer the wrong question. Cassandra 5.0's second release candidate fixes direct I/O detection during a node's first start, when the commit log directory may not yet exist. A failed probe in that state does not establish that the filesystem lacks support. It establishes that the probe ran before its prerequisite was ready.
The release record dates 5.0-rc2 to August 22. Its versioned changelog lists the direct I/O correction and an assertion involving a memtable allocation mode, plus a test-configuration change inherited from 4.0. This is a small stabilization candidate, rather than another announcement of the major version's feature set.
I am interested in Cassandra for workloads that justify its distributed operating model. A candidate like this is useful because deployment behavior includes the first initialization of a node, not only steady operation after its directories and metadata already exist. A working restart can conceal a first-start defect.
A filesystem probe needs somewhere to run
CASSANDRA-19779 begins with warnings from tools run immediately after extracting a distribution archive. The code tried to create a temporary file in the commit log directory so it could determine the file store's block size. Before Cassandra had ever started, that directory did not exist.
The immediate symptom was a warning that the block size could not be determined. The release's changelog describes the broader first-start consequence as direct I/O support being evaluated false. Treating an initialization-order failure as a capability result can select a different access mode without the operator having deliberately chosen that difference.
The issue discusses skipping the check in some tool contexts or guarding the absent directory. The released configuration implementation shows the actual candidate behavior. It creates the commit log directory if necessary before asking for its block size.
This is why the versioned code matters alongside the original report. A report can contain several proposed remedies. The released implementation identifies the one an operator actually receives with RC2.
Automatic selection depends on several conditions
The implementation starts with direct I/O support false, then updates that result from the block-size probe. When the configured access mode is auto, compression and encryption influence the chosen path. Without those settings, direct I/O support and the SSD optimization strategy participate in choosing direct access instead of the legacy path.
Fixing the directory prerequisite therefore does not mean every RC2 node will use direct I/O. It makes one input to the selection accurate in the first-start case. The other configuration conditions still matter, and the implementation validates combinations separately.
That is a practical difference between detecting a capability and requiring a mode. A capability probe supplies information for policy. It should not fail simply because the policy-resolution code runs before ordinary directory creation, but passing it does not override every other setting.
I find the correction useful because it removes an accidental dependence on deployment history. A fresh node and a node whose directory already exists should not report different filesystem capabilities solely because one has completed startup before. The same storage environment should reach the same probe with its prerequisites satisfied.
One allocation mode lacked a buffer mapping
The other runtime fix concerns unslabbed_heap_buffers_logged. CASSANDRA-19835 reports an assertion when that memtable allocation setting reaches trie-related code. Its stack trace includes the SAI segment builder calling a conversion from allocation type to buffer type.
The released configuration enum maps the setting to BufferType.ON_HEAP, alongside the other heap-buffer modes. Off-heap allocation modes map to BufferType.OFF_HEAP. A default assertion remains for an unhandled case.
The defect therefore concerns a missing interpretation of a named configuration value. It is not evidence that every trie memtable fails or that the application supplied an arbitrary unknown string. A supported mode needed a complete mapping at a later internal boundary.
The stack trace also explains why reading the setting at startup is not enough to establish that a combination works. An allocation mode can become relevant again when an index constructs its buffers. Configuration flows through more than one component before all of its consequences are exercised.
The candidate repairs initialization assumptions
The two fixes operate at different boundaries. The direct I/O probe needs its directory before it can characterize the filesystem. Buffer conversion needs a case for the selected allocation mode before trie-related work can allocate the expected buffer kind.
For deployments evaluating Cassandra 5.0, RC2 supplies concrete corrections to those paths while retaining release-candidate status. First-start testing and the selected allocation configuration exercise behavior that a generic query against an already initialized node would not cover. The candidate's small changelog makes those particular differences from RC1 clear.