May 23, 2026
Delete to accelerate
We made our filesystem 47× faster by deleting it
They sped things up by scrapping the slow part—and commenters are roasting how obvious it was
TLDR: The company rebuilt its tool so files are handled the simple way, making it far faster—47 times faster on average, with huge wins in worst cases. Commenters were split between impressed and merciless, with many saying the slow design choice should have been an obvious red flag from the start.
A startup just pulled the most chaotic-yet-satisfying stunt in tech: it made its sandboxing tool dramatically faster by deleting the very file system setup it had built. The team says its new version is 47 times faster on average, with some tasks improving by more than 1,000 times, after ditching a painfully slow middleman that kept sending tiny file requests back and forth. In plain English: the app was taking the scenic route for every little file check, and users were absolutely feeling it.
And the comments? Pure popcorn material. One of the loudest reactions was basically, “well… yeah.” Hacker News readers were not exactly shocked. One commenter laughed that using FUSE—software that lets ordinary apps pretend to be a file system—was the original sin here, saying everyone knows it can crawl with lots of small files. Another went even harder, asking if it wasn’t “really obvious” this would be slow and saying the whole story didn’t inspire confidence. Ouch.
Still, there was some admiration mixed into the snark. People loved the headline’s energy—“That’s such a HN title!”—and the engineering fix itself is undeniably bold: throw away the slow custom layer, build the disk image ahead of time, and let the system handle files directly. Meanwhile, one poor commenter just wanted to ask how anyone actually uses the product with coding assistants and editors… then got downvoted and posted a mini-meltdown. So yes, the real story here is speed, but the real real story is the internet gleefully debating whether this was a brilliant simplification or an extremely expensive lesson in learning the obvious.
Key Points
- •Microsandbox says v0.4 improved guest-visible filesystem performance by a 47× geometric mean and more than 1,000× in some worst-case rows by replacing its user-space filesystem with a VM-mounted Linux disk image.
- •The earlier v0.3 design used OCI layers with a user-space overlay via libkrun, but file operations still depended on FUSE-mediated round trips between the VM and host.
- •The article identifies FUSE-based host round trips for open, stat, readdir, and cache misses as the main reason the previous architecture was much slower than Docker.
- •The new design uses prebuilt filesystem images mounted by the VM kernel, with EROFS for read-only layers and ext4 for scratch space.
- •To support both Linux and macOS without external host tools or root access, the team wrote Rust-based EROFS, ext4, and VMDK image writers and validated them with a reader and CI under the real VM kernel.