shayonj

Kudos. We did/built something internally to solve similar-ish problems https://www.shayon.dev/post/2026/283/versioned-filesystem-fo...

Interesting that this is happening around the same time as Claude issues too

Nice one re: flatbuffers in `blob` column. Have been working with flatbuffers a lot and that's a neat idea in general.

Not 100% sure about using PG for file system at scale however. I'd love to hear more on the challenges (vacuum, toast, anything else?)

v interesting. Thanks for sharing. I kept seeing this phenomenon of "no free lunches". TIL about the waterbed theory.

> Nothing was solved. The four questions got new answers, and the costs moved into the compactor.

I have been meaning to write on this topic and in relation to LSM for a while. So, I appreciated that note on LSMs. There are no free ~lunches~ reads or writes.

that's very interesting! I was noticing page vault storm on live migrations as well and I wonder if that's what you were running into / mentioning here regarding the lock contention

> you can do things that aren't practical with 100-200ms startup: speculative parallel execution (fork 10 VMs, try 10 approaches, keep the best), treating code execution like a function call instead of an infrastructure decision, etc.

i am not following, why isn't it practical?

Cool project. +1 on userfaultfd for the multi-node path. Wrote about how uffd-based on-demand restore works wrt to my Cloud Hypervisor change [1] if you are curious.

I think the the main things to watch are fault storms at resume (all vCPUs hitting missing pages at once) and handler throughput if you're serving pages over the network instead of local mmap. I think its less likely to happen when you fork a brand new VM vs say a VM that has been doing things for 5 mins.

Also interestingly, Cloud Hypervisor couldn't use MAP_PRIVATE for this because it breaks VFIO/vhost-user bindings. Firecracker's simpler device model is nice for cases like this.

[1] https://www.shayon.dev/post/2026/65/linux-page-faults-mmap-a...

That's a good shout. I will update/port it back from here - https://github.com/cloud-hypervisor/cloud-hypervisor/pull/78..., but quite fast

This is going to be an interesting space to watch I think and big part of offering sandbox as a service basically for enterprise and saas needs.

Yeah, it's hard to hit the right balance with nuance around these and you're spot on. What I meant to get at was the specific difference in default modes where gVisor's systrap intercepts syscalls via seccomp traps and handles them entirely in a user-space Go kernel, so there's no hardware isolation boundary in the memory/execution sense. A microVM puts the guest in a VT-x/EPT-isolated address space, which is a qualitative difference in what enforces the boundary (perhaps?)

Whereas yeah, you can run gVisor in KVM mode where it does use hardware virtualization, and at that point the isolation boundary is much closer to a microVM's. I believe the real difference then becomes more about what's on either side of that boundary where gVisor gives you a memory-safe Go kernel making ~70 host syscalls, a microVM gives you a full guest Linux kernel behind a minimal VMM. So at least in my mind it comes down to a bit of around different trust chains, not necessarily one strictly stronger than the other.

Heya! nice to see you here. In retrospect it feels like CI companies and environments are very well suited for sandboxes since a lot of the problems overlap around ephemeral workloads, running untrusted code, fast cold starts, multi-tenancy isolation. Also, loved Buildkite at a past job! Looking forward to following cleanroom

It touches in the gvisor section around the trade-off that the surface area for gvisor is smaller. There are trade offs. It’s not dishonest.