Erik Schubert

Didn't look deeply into the topic. Can we achieve better cache usage with multiple draws, if the user calls `GlyphBrush::cleanup_frame()` explicitly when finishing a frame? Currently the cache is trimmed...

We are affected by this is well. Some seconds of sleep after draining, like in https://github.com/flatcar-linux/flatcar-linux-update-operator/pull/62 would help mitigating.

Could not reproduce it using QEMU so far. I tried plenty of reboots and letting the VM ran for while using one of our ignition templates. Also starting with 3227.2.1...

We experienced the issue with ext4 on vmware disks.

> We can reproduce it as soon as we generate a lot of IO on the hard disk. Any specific you executed for that? I shuffled around some 100 GB's...

Closing in favor of #719 .

I have played around with dynamically growing the texture atlas. There is two ways to do this: 1. Allocate a larger texture, drop `glyph_cache`, `packer` and `texture_pending` and rerasterize/reupload every...

We only use the update-agent. When upgrading to 0.9.0 I forgot to update the rolebinding to include evictions, which in turn caused no pods to be evicted and the drain...

I think exit and restart is fine as that would surface an issue via the `CrashLoopBackoff` pod status in Kubernetes.

Same issue for me with a 5500 XT on Arch.