Apr 22, 2025

This is a consequence of recent optimizations in writing the set_strong table (confirmation records), and simplification of the organization process. I also resolved the potential data integrity issue with confirmation records - confirmation index becoming inconsistent with strong following a disk full pause/restart. I ended up using a two phase commit between these records. By ensuring they are both allocated before becoming written and accessible there is no risk of an inconsistency (publicly atomic).