Aug 31, 2026

After some more travel I'm back to it. I previously (8/18-19) cleared these items from the punch list:

[x] Linux OOM kill at store creation on 8GB (initialize on disk)
[x] restore after height index regress (change to headers)
[x] broken store with no snap should create empty store
[x] restore after prevouts prune (unsafe)
[x] archive immutable store settings in genesis
[x] API from ultrafast to detect GPU usability
[x] milestone prompt when not explicitly configured

Also as of today, hashmap tables carry an expected element count, from which the store derives optimal boom filter k at create (formerly suboptimal), persisted via the settings envelope across load/restore. The bs defaults are recalibrated to a mainnet 950k basis: expected element counts, buckets sized for a 2.5 load factor, and minimum body allocations at 1% of the pruned body with 1% growth. I am continuing to optimize the custom posix mmap implementations, which has resulted in more performance improvement at the low RAM end*. The default allocations and growth rates are dramatically smaller than previous defaults. They no longer have a significant impact on sync performance, and this is a much more flexible configuration. With this done I'll be moving on to default store config automation as a function of available RAM. (*) e.g. Linux 8 GB RAM mini pruned with full address index now completes a 950k milestone run on 2.5Gbps in 38 minutes. Also removed the slab scan (-a) command line option, as it has been obsoleted for some time due to a redesign of the ins/points tables. ins and outs are an association record table that each point to inputs and outputs slab tables. So in/out element counts are simply array size.