"
Thanks for sharing your findings. I can add some further real-world data points that seem to support the same pattern:
I am seeing the same behaviour on three additional production systems with essentially the same system design. The absolute write volumes differ somewhat, but the result is consistent: when the Zenarmor engine is running, SSD host writes increase by approximately 4–5x compared with the baseline without Zenarmor.
Based on the measured write rates and the respective SSD endurance ratings (TBW), the specified endurances would be reached after approximately 2–4 years of operation, depending on the SSD and system.
For comparison, on my own system with the 320 TBW rating of my Kingston NV3, that corresponds to roughly 9.1 years at the baseline write rate, compared with only 2.3 years with Zenarmor enabled. (TBH: are endurance projections, not predictions of actual SSD failure.)
What makes this particularly concerning is that these are Proxmox hosts running several other servers and services, which already generate a substantial amount of disk I/O. Nevertheless, the additional write load associated with Zenarmor exceeds the combined baseline workload by several times. Essentially for the purpose of persisting reporting and connection metadata!
At this point, the consistency across multiple systems makes me strongly suspect a fundamental design or implementation issue in how much data Zenarmor writes and how those writes are performed. Whether the main contributor is the record volume, SQLite WAL/checkpointing, cleanup operations, write amplification, or a combination of these still needs to be investigated. But the resulting sustained write load seems difficult to justify for a reporting feature, particularly on appliances with limited SSD endurance.
I would therefore really like to see Zenarmor investigate the root cause and provide a technical explanation and mitigation for the local reporting backend. Ideally, there should also be an option to disable persistent reporting entirely while keeping the filtering/security engine active, for users who do not need historical reporting data.
I am seeing the same behaviour on three additional production systems with essentially the same system design. The absolute write volumes differ somewhat, but the result is consistent: when the Zenarmor engine is running, SSD host writes increase by approximately 4–5x compared with the baseline without Zenarmor.
Based on the measured write rates and the respective SSD endurance ratings (TBW), the specified endurances would be reached after approximately 2–4 years of operation, depending on the SSD and system.
For comparison, on my own system with the 320 TBW rating of my Kingston NV3, that corresponds to roughly 9.1 years at the baseline write rate, compared with only 2.3 years with Zenarmor enabled. (TBH: are endurance projections, not predictions of actual SSD failure.)
What makes this particularly concerning is that these are Proxmox hosts running several other servers and services, which already generate a substantial amount of disk I/O. Nevertheless, the additional write load associated with Zenarmor exceeds the combined baseline workload by several times. Essentially for the purpose of persisting reporting and connection metadata!
At this point, the consistency across multiple systems makes me strongly suspect a fundamental design or implementation issue in how much data Zenarmor writes and how those writes are performed. Whether the main contributor is the record volume, SQLite WAL/checkpointing, cleanup operations, write amplification, or a combination of these still needs to be investigated. But the resulting sustained write load seems difficult to justify for a reporting feature, particularly on appliances with limited SSD endurance.
I would therefore really like to see Zenarmor investigate the root cause and provide a technical explanation and mitigation for the local reporting backend. Ideally, there should also be an option to disable persistent reporting entirely while keeping the filtering/security engine active, for users who do not need historical reporting data.
