How do you permanently set sequential cutoff values?

[miversen33]

Question

I have recently started exploring OpenCAS and so far I am very impressed with it. I am coming from configuration/testing hell with bcache and so OpenCAS is a breath of fresh air!

That said, while configuration for opencas is much better than bcache, it does have some quirks that I am unsure about.

As an example, how would I go about saving the following casadm command to my opencas.conf?

# casadm --set-param --name seq-cutoff --promotion-count 4 --cache-id 1 --core-id 1
# casadm --set-param --name seq-cutoff --promotion-count 4 --cache-id 1 --core-id 3

I took a look at the source for loading the configuration (I believe this is where that happens?)

        def validate_parameter(self, param_name, param_value):
            if param_name == 'ioclass_file':
                if not os.path.exists(param_value):
                    raise ValueError('Invalid path to io_class file')
            elif param_name == 'cleaning_policy':
                self.check_cleaning_policy_valid(param_value)
            elif param_name == 'promotion_policy':
                self.check_promotion_policy_valid(param_value)
            elif param_name == 'cache_line_size':
                self.check_cache_line_size_valid(param_value)
            elif param_name == "lazy_startup":
                self.check_lazy_startup_valid(param_value)
            elif param_name == "target_failover_state":
                self.check_failover_state_valid(param_value)
            else:
                raise ValueError(f'{param_name} is invalid parameter name')

And that is pretty clearly ensuring that there is no way for me to set things like seq-cutoff (or the promotion threshold). Am I missing something or is the configuration limited on what it can apply?

[robertbaldyga]

Hi @miversen33 ! You are right, seq-cutoff seems to be missing in the config file.
In general that should not be a big deal, as cache saves those settings in metadata on the cache drive when they are changed. So when you seq-cutoff params with casadm command and then stop the cache, on the next start (with --load) your configuration will be restored.

As for availability of those options in opencas.conf, I think the key here is that nobody before asked for it. The project development is more or less driven by the user needs, so that may be the moment we add it to our todo list.

[miversen33]

That makes sense. So can we consider this issue a request for that? Or maybe we close this issue in favor of #1625 and have all configurable options added to the configuration?

After all the documentation very clearly states you should be using /etc/opencas.conf instead of using casadm, yet we are expected to use casadm to configure things because not all configuration options are available in /etc/opencas.conf

While configuration of Open CAS Linux via the opencas.conf file is highly recommended, the following sections detail how to manually configure Open CAS Linux options using casadm. For more details on available commands for the casadm utility, see the section Configuration Tool Details.

[robertbaldyga]

We created #1625 as a more general change request, so I think it should cover this one and we can close it.

The original reason for /etc/opencas.conf to exist was a need to detect cache/core devices at the boot time. So you need to have you configuration reflected in /etc/opencas.conf for it to work. But that applies only to the topology, not all the config options.
The other configuration options were added later on for convenience, and casctl init was introduces as well, so that users did not need to create everything using casadm and then write it down to the config (which is not only tedious but also error prone). Based on that concept of having the configuration in one place, the comment in the documentation was added.

At some point had an idea of completely replacing casadm with /etc/opencas.conf, but that proved to be too complex. Especially is situations when we needed to apply a set of changes to running caches. So it stayed like that in this state somewhere in the middle, where using /etc/opencas.conf is necessary for recreating caches after the reboot, and using casadm is necessary for runtime reconfiguration.