[
https://issues.apache.org/jira/browse/CASSANDRA-19812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17873958#comment-17873958
]
Stefan Miklosovic edited comment on CASSANDRA-19812 at 8/15/24 1:39 PM:
------------------------------------------------------------------------
Well ... my thinking behind not putting that into 5.0.0 is that if somebody
wants "direct" they probably pretty much know that their filesystem supports
direct so it does not fail. I do not think that somebody would configure it to
direct while their filesystem would not support that so it is just a bug in
that regard.
If we put that to 5.0.0, it would fail to start Cassandra too. It would just
fail sooner, like this
{code}
org.apache.cassandra.exceptions.ConfigurationException:
commitlog_disk_access_mode can not be set to direct when direct IO is not
supported by the file system.
at
org.apache.cassandra.config.DatabaseDescriptor.validateCommitLogWriteDiskAccessMode(DatabaseDescriptor.java:1512)
at
org.apache.cassandra.config.DatabaseDescriptor.initializeCommitLogDiskAccessMode(DatabaseDescriptor.java:2893)
at
org.apache.cassandra.config.DatabaseDescriptor.applySimpleConfig(DatabaseDescriptor.java:645)
at
org.apache.cassandra.config.DatabaseDescriptor.applyAll(DatabaseDescriptor.java:462)
at
org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:270)
at
org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:254)
at
org.apache.cassandra.service.CassandraDaemon.applyConfig(CassandraDaemon.java:787)
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:730)
at
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:888)
{code}
instead of like this (current state):
{code}
INFO [main] 2024-08-15 15:36:17,210 NativeLibrary.java:186 - JNA mlockall
successful
INFO [main] 2024-08-15 15:36:17,394 MonotonicClock.java:208 - Scheduling
approximate time conversion task with an interval of 10000 milliseconds
INFO [main] 2024-08-15 15:36:17,395 MonotonicClock.java:351 - Scheduling
approximate time-check task with a precision of 2 milliseconds
Exception (java.lang.UnsupportedOperationException) encountered during startup:
null
ERROR [main] 2024-08-15 15:36:17,815 CassandraDaemon.java:910 - Exception
encountered during startup
java.lang.UnsupportedOperationException: null
at
org.apache.cassandra.io.util.FileUtils.getBlockSize(FileUtils.java:822)
at
org.apache.cassandra.db.commitlog.DirectIOSegment$DirectIOSegmentBuilder.<init>(DirectIOSegment.java:166)
at
org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager.createSegmentBuilder(AbstractCommitLogSegmentManager.java:135)
at
org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager.start(AbstractCommitLogSegmentManager.java:154)
at org.apache.cassandra.db.commitlog.CommitLog.start(CommitLog.java:147)
at
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:268)
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:734)
at
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:888)
{code}
The difference is that if we merged this into 5.0.0, it would just failed
sooner, there is other logic involved in the meanwhile until it comes to the
point where it fails when this patch is not applied.
was (Author: smiklosovic):
Well ... my thinking behind not putting that into 5.0.0 is that if somebody
wants "direct" the probably pretty much know that their filesystem supports
direct so it does not fail. I do not think that somebody would configure it to
direct while their filesystem would not support that so it is just a bug in
that regard.
If we put that to 5.0.0, it would fail to start Cassandra too. It would just
fail sooner, like this
{code}
org.apache.cassandra.exceptions.ConfigurationException:
commitlog_disk_access_mode can not be set to direct when direct IO is not
supported by the file system.
at
org.apache.cassandra.config.DatabaseDescriptor.validateCommitLogWriteDiskAccessMode(DatabaseDescriptor.java:1512)
at
org.apache.cassandra.config.DatabaseDescriptor.initializeCommitLogDiskAccessMode(DatabaseDescriptor.java:2893)
at
org.apache.cassandra.config.DatabaseDescriptor.applySimpleConfig(DatabaseDescriptor.java:645)
at
org.apache.cassandra.config.DatabaseDescriptor.applyAll(DatabaseDescriptor.java:462)
at
org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:270)
at
org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:254)
at
org.apache.cassandra.service.CassandraDaemon.applyConfig(CassandraDaemon.java:787)
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:730)
at
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:888)
{code}
instead of like this (current state):
{code}
INFO [main] 2024-08-15 15:36:17,210 NativeLibrary.java:186 - JNA mlockall
successful
INFO [main] 2024-08-15 15:36:17,394 MonotonicClock.java:208 - Scheduling
approximate time conversion task with an interval of 10000 milliseconds
INFO [main] 2024-08-15 15:36:17,395 MonotonicClock.java:351 - Scheduling
approximate time-check task with a precision of 2 milliseconds
Exception (java.lang.UnsupportedOperationException) encountered during startup:
null
ERROR [main] 2024-08-15 15:36:17,815 CassandraDaemon.java:910 - Exception
encountered during startup
java.lang.UnsupportedOperationException: null
at
org.apache.cassandra.io.util.FileUtils.getBlockSize(FileUtils.java:822)
at
org.apache.cassandra.db.commitlog.DirectIOSegment$DirectIOSegmentBuilder.<init>(DirectIOSegment.java:166)
at
org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager.createSegmentBuilder(AbstractCommitLogSegmentManager.java:135)
at
org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager.start(AbstractCommitLogSegmentManager.java:154)
at org.apache.cassandra.db.commitlog.CommitLog.start(CommitLog.java:147)
at
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:268)
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:734)
at
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:888)
{code}
The difference is that if we merged this into 5.0.0, it would just failed
sooner, there is other logic involved in the meanwhile until it comes to the
point where it fails when this patch is not applied.
> We should throw exception when commitlog 's DiskAccessMode is direct but
> direct io is not support
> -------------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-19812
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19812
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Commit Log
> Reporter: Maxwell Guo
> Assignee: Maxwell Guo
> Priority: Normal
> Fix For: 5.0.x, 5.x
>
>
> Looking into the code below :
> {code:java}
> private static DiskAccessMode
> resolveCommitLogWriteDiskAccessMode(DiskAccessMode providedDiskAccessMode)
> {
> boolean compressOrEncrypt = getCommitLogCompression() != null ||
> (getEncryptionContext() != null && getEncryptionContext().isEnabled());
> boolean directIOSupported = false;
> try
> {
> directIOSupported = FileUtils.getBlockSize(new
> File(getCommitLogLocation())) > 0;
> }
> catch (RuntimeException e)
> {
> logger.warn("Unable to determine block size for commit log
> directory: {}", e.getMessage());
> }
> if (providedDiskAccessMode == DiskAccessMode.auto)
> {
> if (compressOrEncrypt)
> providedDiskAccessMode = DiskAccessMode.legacy;
> else
> {
> providedDiskAccessMode = directIOSupported &&
> conf.disk_optimization_strategy == Config.DiskOptimizationStrategy.ssd ?
> DiskAccessMode.direct
>
> :
> DiskAccessMode.legacy;
> }
> }
> if (providedDiskAccessMode == DiskAccessMode.legacy)
> {
> providedDiskAccessMode = compressOrEncrypt ?
> DiskAccessMode.standard : DiskAccessMode.mmap;
> }
> return providedDiskAccessMode;
> }
> {code}
> We should throw exception when user set the DiskAccessMode to direct for
> commitlog but the directIOSupported return false after the judgement of
> "FileUtils.getBlockSize(new File(getCommitLogLocation())) > 0;" instead of
> waiting for the system to start and accepting reads and writes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
