Two devices, not one "disk"

A workspace's main disk is virtio-blk, a paravirtualized block device (see the device inventory post). A shared folder from the Mac is virtio-fs, a paravirtualized filesystem protocol built to share a host directory tree rather than back a disk image. They solve different problems and perform accordingly. A public discussion among Apple's container engineers and contributors (apple/container discussion #1516) put native performance at roughly 2–3× virtio-blk, and virtio-blk at roughly 3× virtio-fs, for the same disk-heavy workload. That's a big gap.

Where to put what

The rule that follows: if disk throughput matters (a build with lots of file I/O, a database, unpacking a big archive), do it on the workspace's own disk, not in a shared folder. Use shared folders for what they're good at, convenient access to files that live on the Mac.

That can seem to clash with keeping project source in a shared folder, as other posts here suggest. The two combine well: keep the source in the shared folder so your Mac and your Git history see it, and point the heavy, generated parts at the guest's own disk. Put node_modules, virtualenvs, build output and caches in a directory on the guest disk (many tools take an output or cache path, or you can symlink the folder), and the slow path only carries the files you edit.

Caching is a durability trade-off, not free speed

Velo Workspaces attaches the disk in .cached mode instead of the framework's default, which behaves as uncached, to absorb the repeated metadata rewrites an OS install produces. The device inventory post explains the full mechanism and why it doesn't give up durability: the guest's own flushes stay synchronous. It's worth repeating as a disk-performance fact. Caching changes how quickly repeated writes to the same blocks complete, which is a real difference for install-heavy work, but it's a durability decision first and a speed one second, and Velo Workspaces keeps the safer half.

Day to day

  • Keep your working set on the workspace's own disk whenever throughput matters.
  • Use shared folders for convenience: moving files to and from the Mac, and source you want to edit on either side, not the live directory for a build or database.
  • Expect installs and big unpacks to benefit from host caching. That's already configured; there's nothing to tune.

Related reading: the device inventory post, guest OS performance tuning for the I/O scheduler and TRIM, how vCPU allocation works, and what decides VM startup time. Or download Velo Workspaces and try it yourself.