"
I noticed unusually high SSD wear on an OPNsense system and started tracing the write activity.
A controlled A/B test using the NVMe SMART [tt]Data Units Written[/tt] counter showed a very large difference depending on whether the Zenarmor engine was running.
Zenarmor OFF, 16 minutes
212,834,990 -> 212,837,079
= 2,089 data units
≈ 1.07 GB written in 16 minutes
≈ 96 GB/day extrapolated
Zenarmor ON, 16 minutes
212,837,079 -> 212,845,277
= 8,198 data units
≈ 4.20 GB written in 16 minutes
≈ 378 GB/day extrapolated
So in this test, enabling Zenarmor increased total SSD writes by roughly 4x, corresponding to about 282 GB/day additional writes.
Zenarmor is using the local SQLite reporting backend. While the engine is running, the SQLite databases and WAL files under:
/usr/local/datastore/sqlite
are continuously updated, especially files such as:
conn_all.sqlite(-wal)
dns_all.sqlite(-wal)
tls_all.sqlite(-wal)
alert_all.sqlite(-wal)
http_all.sqlite(-wal)
What makes this concerning is SSD endurance.
The SSD in this system is rated for 320 TBW. At around 378 GB/day, the rated write endurance would be reached after only about 2.3 years of continuous 24/7 operation.
The additional writes attributable to Zenarmor alone are roughly 282 GB/day, which corresponds to more than 100 TB/year.
I do not actually need historical Zenarmor reporting and would prefer to keep only the filtering/security engine active.
Environment:
OPNsense: OPNsense 26.7.3_8-amd64 FreeBSD 15.1-RELEASE-p3
Zenarmor Engine: 2.6.2
Zenarmor Database: 2.0.26071708
Reporting backend: Local SQLite
Has anyone else on OPNsense measured similar write volumes with Zenarmor?
I am especially interested in whether:
A controlled A/B test using the NVMe SMART [tt]Data Units Written[/tt] counter showed a very large difference depending on whether the Zenarmor engine was running.
Zenarmor OFF, 16 minutes
212,834,990 -> 212,837,079
= 2,089 data units
≈ 1.07 GB written in 16 minutes
≈ 96 GB/day extrapolated
Zenarmor ON, 16 minutes
212,837,079 -> 212,845,277
= 8,198 data units
≈ 4.20 GB written in 16 minutes
≈ 378 GB/day extrapolated
So in this test, enabling Zenarmor increased total SSD writes by roughly 4x, corresponding to about 282 GB/day additional writes.
Zenarmor is using the local SQLite reporting backend. While the engine is running, the SQLite databases and WAL files under:
/usr/local/datastore/sqlite
are continuously updated, especially files such as:
conn_all.sqlite(-wal)
dns_all.sqlite(-wal)
tls_all.sqlite(-wal)
alert_all.sqlite(-wal)
http_all.sqlite(-wal)
What makes this concerning is SSD endurance.
The SSD in this system is rated for 320 TBW. At around 378 GB/day, the rated write endurance would be reached after only about 2.3 years of continuous 24/7 operation.
The additional writes attributable to Zenarmor alone are roughly 282 GB/day, which corresponds to more than 100 TB/year.
I do not actually need historical Zenarmor reporting and would prefer to keep only the filtering/security engine active.
Environment:
OPNsense: OPNsense 26.7.3_8-amd64 FreeBSD 15.1-RELEASE-p3
Zenarmor Engine: 2.6.2
Zenarmor Database: 2.0.26071708
Reporting backend: Local SQLite
Has anyone else on OPNsense measured similar write volumes with Zenarmor?
I am especially interested in whether:
- this level of write activity is considered normal,
- there are OPNsense/FreeBSD-specific factors that significantly amplify these writes,
- there is a supported way to disable or strongly reduce Zenarmor reporting persistence while keeping the engine active,
- or whether this could indicate an issue in the SQLite/reporting pipeline.
