Two different devices, not one "disk" abstraction

A workspace's primary disk is attached as virtio-blk — a paravirtualized block device, the same kind this blog's device inventory post covers generally. A shared folder from the host, by contrast, is virtio-fs — a paravirtualized filesystem protocol, not a block device, designed to share a host directory tree into the guest rather than to back a disk image. They solve different problems and their performance characteristics reflect that: a public discussion among Apple's own container-tooling engineers and contributors on this exact question (apple/container discussion #1516) put native host performance at roughly 2–3× virtio-blk, and virtio-blk itself at roughly 3× virtio-fs, for the same disk-heavy workload — a large, real gap, not a rounding difference.

The practical rule that falls out of this: if disk throughput matters for what you're doing — a build with a lot of file I/O, a database, extracting a large archive — do it on the workspace's own disk, not inside a shared folder. Keep shared folders for what they're actually good at: convenient access to files that live on the host, not as the working directory for I/O-heavy work.

Caching mode is a durability tradeoff, not a free speed boost

Velo's disk-image attachment uses .cached mode rather than the framework's own uncached-in-practice default, specifically to absorb the repeated metadata rewrites an OS install generates — the full mechanism, and why it doesn't quietly trade away durability in the process, is covered in depth in the device inventory post's storage section. Worth restating briefly here because it's a disk-performance fact, not just a device-inventory one: caching mode changes how fast repeated writes to the same blocks complete, which is a real, measurable difference for install-heavy work — but it's a durability tradeoff first and a performance one second, and Velo's choice deliberately keeps the safer half of that tradeoff.

What this means day to day

  • Put your working set on the workspace's own disk, not a shared folder, whenever disk throughput actually matters to the task.
  • Use shared folders for convenience, not performance — moving files back and forth with the host, not as the live working directory for a build or a database.
  • Expect installs and large unpacks to benefit from host page-cache absorption — that's a deliberate choice in how Velo configures the disk, not something you need to tune yourself.

Related reading: the device inventory post for how virtio-blk fits alongside Velo's other paravirtualized devices, how vCPU core allocation works, and what determines VM startup time, where this same caching choice shows up again. Or download Velo Workspaces and try it yourself.