Modal’s engineering post is by Nitin Maddi and Amit Prasad and is dated 16 October 2026. It is about the filesystem inside VM sandboxes. Those sandboxes are generally available, and the backend is the implementation they call ImageFS-blk. General availability describes that product backend. It is not a performance promise for every customer workload.

[1]
An upright drive with a charcoal face and a blue edge
A solid-state drive standing upright, its face painted charcoal and its edge muted blue., AI-generated illustration, not a news photograph

The previous path let the virtual machine use host ImageFS through virtio-fs. Names, owners, and permissions lived on the far side of the virtual-machine boundary, so each metadata operation had to ask across it. They saw a recursive ownership change go from four seconds to more than a minute. pnpm and bun installs looked three times slower, and code search fell off sharply. In their microbenchmarks, stat was twice as slow under virtio-fs, and chown was more than six times worse. One chown took three round trips to the host and 99 microseconds. The comparison was ImageFS on the host, ImageFS behind gVisor, and virtio-fs in a virtual machine.

[1]

The new path keeps the filesystem inside the guest. The host only stores bytes and returns them as blocks. The post uses hard drives and solid-state drives as the analogy: the device does not know what a file is. ext4 inside the guest handles ownership and permissions, then commits a batch of writes asynchronously. They measured about 2.1 microseconds for one chown on the block device. The tradeoff is that the host can no longer interpret the guest directory as files. It can only read and write blocks.

[1]

They did not connect this to ImageFS by building a full disk image first. They pull file metadata, write the ext4 index themselves, and fetch the remaining blocks from ImageFS when the guest reads them. Blocks the guest has written stay in that guest’s sparse file. The page says the worst case is copying one block, rather than, in a degenerate case, moving gigabytes to change a few bytes. With prefetching, cold starts were back under a second, without downloading the whole image first.

[1]

The clearest multiplier is the install test. bun install fell from 12.5 seconds to 1.07 seconds, which they call 12 times, and it beat the older ImageFS path because metadata operations no longer leave the guest. The page also says pgbench and speedtest1 became much faster, but it gives no multiplier, so none is added here. Machine type, repetitions, and error bars are absent. The factor of 12 describes this bun-install benchmark.

[1]