If, for example, you disable-enable some settings every 10 seconds, for example a hundred lines of firewall, etc., then how long will the router’s flash memory resource last, in which these changes will be constantly written?
Is this practice generally welcomed? Or is it wrong?
Is there some way to not save settings to flash if they are implemented from a script launched from the scheduler?
Depends on what do you want to achieve with firewall. In case you want to block or unblock some specific addresses, you can use address lists with dynamic attribute. Such entries are not written to flash and will be lost on next reboot.
Welcomed ? Definitely not.
Flash storage is typically going between 10.000 and 100.000 erase cycles (reading is never a problem, erasing for write is).
Do the math.
So this brings the question … why should you want to change config that often ?
As suggested, use features which are stored in memory, not written to flash.
Or you can use CHR, runs in RAM. No write cycle limit there.
I gave the firewall as an example.
In reality, I need to disable and enable entries in netwatch to reset network test counters.
I need to disable and enable entries in netwatch to reset network test counters.
Just to put this matter to rest, I’m willing to publicly do the math. As an example let’s look at a recent device with 128 MB of flash.
The number of sector writes is available in System->Resources. Let’s assume 10k / day.
Then flash lifetime can be approximately calculated as:
128 MB / 4 k * 100 000 / 10 000 = 327 680 days = 897 years
128 MB - size of flash
4k - program page size
100 000 - Mikrotik uses code flash memory specified for 100 000 erase/program cycles
10 000 - assumed page erases per day
I think it’s valid only in ideal conditions, when a memory is evenly overwritten. I don’t know, if such algorithms are used, but if fact, if the same sector is continuously overwritten by enabling/disabling some rule or whatever, you’ll start to have problems much earlier than in 897 years. I was already forced to replace flash chip after 4 years of usage (my bad, The Dude was running on it that time…). And many other devices also had flash issues and NetInstall was required. So, it’s not something that can be ignored.
Ah, someone who is able to count 
People worry too much about write cycles.
I know. They are used.
Enabling and disabling a rule doesn’t result in the same data in the dame file being overwritten. Even if it was, the new copy of that sector is not stored in the same place in the flash.
Netinstall is usually required because of corruption, not wear-out.
All of the vendors who use alike or similar flash technologies warn about collecting and storing data, logs (especially security and monitoring logs) on these devices. The suggestion is always the same: use proper SSDs for this. It’s a pity that few Mikrotik devices offer these slots, but that’s a request for another day.
And why do you think it becomes corrupted?
The two usual ones:
BTW: Of the devices I’ve overseen, Mikrotik has proven exceptionally resilient. As always, your anecdotes may paint a different picture.
I would ask: “How many times did you dump unrecoverable devices beacause of flash memory problems?”.
Is it addressed to me? If yes, I said above, that I was forced to replace a memory chip once. The device was completely unusable, it worked 1-2 days and then became a brick until next NetInstall. And so on. After chip replacement everything is fine until today. But those, who can’t do chip replacement, would probably dump it.
Yep, but you’ll have to put it in context:
a. 1 out of 1 tested device
b. 1 out of 10 tested devices
c. 1 out of 100 tested devices
d. 1 out of 1000 tested devices
e. 1 out of …
No, it’s an open question. I wonder if it’s a 1% or 1%% or 1%% of 1%% …lucky me, never had the problem. Think that lightning or power spikes do more damage than worn Flash.
Toggling Netwatch is probably doing minuscule amount of writes. I’m curious why you need to toggle it every 10 seconds. There must be a better way to achieve your goals.