Hi Jeremy, Give a look at https://www.knot-dns.cz/docs/latest/singlehtml/index.html#example-4, https://www.knot-dns.cz/docs/latest/singlehtml/index.html#journal-behaviour, https://www.knot-dns.cz/docs/latest/singlehtml/index.html#journal-db-mode
Generally, you should set different https://www.knot-dns.cz/docs/latest/singlehtml/index.html#zone-journal-max-usage for small and huge zones. Knot doesn't support keeping zone changes in the memory with journal disabled. Daniel On 3/7/25 21:06, Jeremy C. Reed wrote:
I have static zones that are regenerated continually (every few seconds) with a knotc zone-reload _zonename_ after. Doing dig queries using ixfr= always used AXFR until I enabled per-zone zonefile-load: difference We saw logs periodically like: warning: [foo.bar.example.com.] failed to update zone file (operation not permitted) This is because the files created are a different user than the knotd. We are not doing automated signing nor dynamic updates. This is with Knot 3.2.6. 1) Why would it try writing to the source zone file? Anyways, we got rid of that warning with zonefile-sync: -1 And the time to between the zone-reload and serving the new zone data improved too. I noticed with experimenting with journal-db-max-size and journal-max-size the data.mdb was around 80% larger than the defined size. As I removed and added records, the number of differences reduced and I couldn't do IXFRs for many versions behind which I assume is default journal-max-depth: 20. I believe this means the journaling was dropping versions and does not require keeping at least 20 versions (not a "minimum". I am fine with that. I was able to trigger error like error: [foo.bar.example.com.] zone event 'load' failed (not enough space provided) which I assume was due to journaling even when dropping old versions still doesn't have enough space for most recent changes. We are experimenting with increasing journal-max-size to work around this. It appears that the differences are fully handled in memory first before updating to the journal file. I also see the journal file have large jump in file size and never small increments. 2) Since I have no purpose to reuse a journal file for system restart or recovery -- since I am building new zone files frequently, is there any way to not use a journal file and just have knotd do this all in memory? That way it is never writing to the journal every few seconds while I continue to offer IXFR out support? If not, maybe I will use memory file system for the journal files. By the way, this is for around ten zones varying from around 1000 records to over 8 million records for the larger zones, They are changing from a few records every few seconds to maybe a thousand records every 30 seconds. Thanks --
--
