@grahamc ping

Re. the limits, the question is really how much speed/load saving is won from doing a small gc. If it's slow and expensive anyway (ie. if the constant cost of doing any size GC is high,) we should increase max-free a lot. This should probably receive testing on a cross section of the machine types, but this is a starting point.

My feeling from GC on rotating drives is that vast majority of time is taken by unlinking files. (I guess tweaking commit=foo mount option might help overall, but I'm digressing.)

@vcunat That sounds like a small GC is indeed preferable. :)

Seems like a good way to give the auto-GC feature some testing :-)

BTW, on t2a I've seen running out of inodes while having plenty of free space (more than half). I plan to work around that just by collecting everything relatively often (once a day or so), since the machine won't benefit much from caching. Only the metrics job is ran there and that's rather special; it seems unlikely to happen on other machines.

I want to deploy this soon. It requires some careful manual rolling deployment to avoid breaking all of the nodes.

Any update on this?

I haven't touched the NixOS infra in a long time now. Somebody else should probably take over.