Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- Author here - Just wanted to add this Disclaimer: AI was used extensively here, both to debug the cluster and to write this article.
I support responsible use of A.I I understand the discourse around Slop/Vibe code etc… Personally as long as the slop / vide code does the job securely, reliably and is maintainable does not matter if you hand write the code or use A.I. I prefer to use all the tooling available to me build things.
by humbfool2 - Have encountered this too - esp lack of plp combined with zfs and dramless can be deathly slow.
For kubernetes Etcd I’ve found those cheap m10 optanes to be great. No PLP but seems to work fine anyway presumably due to low latency.
by Havoc - I don't know which filesystem was used. But if ext4 was used, it will be one of reasons. When you random write on ext4, and then do fsync, ext4 fast commit (introduced in 5.10) will combine them into a whole range from the lowest address to highest address, so it will sync far more data from actual modified data for random write. And even worse, if the range is larger than EXT4_FC_SNAPSHOT_MAX_RANGES, it will fallback to old full commit behavior and got worse result. There is a patch to fix this issue but it's still not merged. https://lore.kernel.org/all/20260730003715epcms2p54b7e3cc340...by Coelacanthus