Is there an option to do “runtime-configuration” through scripts and scheduler?
For example I want to automatically turn on/off the led’s on my cAPs based on a time schedule as well as the 5GHz wifi. Is there an option to create only a temporary config change that is not written to the device’s flash memory? There are two points why I don’t want this configuration change in flash:
Unnecessary flash wear-out by periodically changed settings
After a reboot I want default configuration to be loaded and not my temporary changed configuration
I know this behaviour with “runtime-configuration” and “startup-configuration” well from cisco IOS. Is there an option or trick in ROS to archieve same behavior? When working with files I know its possible by not writing the files into the flash directory. But as far as I know it’s not possible for configuration changes.
Not possible afaik, safe mode does that but for whole configuration while in it. It can be that writes are handled by ROS to avoid flash wear-out, buffered in RAM and written on flash after some period. I know when device runs out of space device configuration it’s still applied, but when rebooted it logs error, I guess it’s when it tries to write config on flash.
No, all configuration changes are immediately written to flash, of course when space still permits.
However, they are also implemented in the running version even when there is no more space to store them.
That explains the behavior you are seeing.
The request above has been made before, but it isn’t implemented. The only way to control leds without flash writes is to configure them to one of the options that tracks some condition, e.g. interface up. When you have more complicated requirements there is no solution.
(I guess a change that would be compatible with the entire config infrastructure is to add a capability to have a script as source of the LED state, where that script is run every N seconds (configured) and returns a LED state)
The Cisco IOS method of doing things has disadvantages as well, like losing config changes at the next powercycle when you forget to write them.
Oh that’s a pity. The LED thing was just one example this might be useful for. What I also wanted to use this for is turning off some wifi networks and the 5GHz wifi at night. This might produce 365*2 flash writes each year, that would be absolutely unnecessary. What would be an absolutely nice feature is to mark some configuration changes as F like when applying configuration in safe mode.
I’m not sure if that’s implementable or whether the developers might come into devil’s kitchen. I think it might depend on the underlying implementation of the configuration storage.
The Cisco IOS method of doing things has disadvantages as well, like losing config changes at the next powercycle when you forget to write them.
I think this one depends on the point of view. Maybe you also want to experiment around with temporary settings and are glad that everything is restored to default when power-cycling. I personally like this approach of implementation of configuration. Of course you always have to keep in mind to save configuration in the end.
Safe mode does not reduce flash writes… it only uses the undo list to undo changes starting from “enter safe mode” when the connection is interrupted. But the changes still are written to the flash.
Try to powercycle when safe mode is active
I’ve seen that you created a feature request regarding the non-persistent configuration. I’m not sure how much work this would cause to implement, but I thinks that would be the best solution for such specific problem. Especially when having scripts that often change some parameters really frequently this might be essential to not destroy your flash.
Could you please link your Feature Request and then I would mark this topic as solved?
Even if writes per sector are evenly distributed why not to have feature to reduce them if you really not need it and also it will offload kernel I/O operations.
Why? I think reducing unnecessary writes is always a good method. Maybe I'm kind of overcautious but I think in several cases configuration changes can happen very often. And if they didn't have a gread wear-levelling algorithm, this would definitely lead to problems.
And besides the flash wear-out topic, I still see an advantage in a temporary configuration if you do e.g. some experiments and don't want to mess up your default configuration. (But i know there are other ways to accomplish this, by using backups or the history, or even safemode)
