Significant Performance Degradation When Switching from `--dir` to `--disk` for CI/CD Workloads

[arash01]

Environment

• Tart Version: 2.28.6
• Host & VM macOS Version: Sequoia 15.6.1
• Hardware: AWS EC2 Mac M2

Background

We're running a runner that executes builds inside Tart VMs. Our workflow involves:

1. Copying git repository and build scripts to a shared volume
2. Attaching the volume to a Tart VM
3. Executing builds inside the VM (compilation, tests, artifact generation)
4. Collecting artifacts after the VM stops

The Switch: --dir → --disk

We recently migrated from using --dir (VirtioFS directory sharing) to --disk (sparse image as block device) for the following reasons:

• Need for better isolation and control
• Avoiding VirtioFS limitations and potential issues

Previous approach:

tart run "vm-image" --dir="/path/to/shared"

Current approach (slow):

# Create sparse image
hdiutil create -size 50g -type SPARSE -fs APFS -volname "MyVolume" volume.sparseimage

# Mount, copy files, unmount
hdiutil attach volume.sparseimage
# ... copy files to /Volumes/MyVolume ...
diskutil unmountDisk /dev/diskX

# Attach to VM
tart run "vm-image" --disk="/dev/diskX"

Problem: Severe Performance Degradation

Build times have dramatically increased after switching to --disk. For example:

• With --dir: Build completes in ~10 minutes
• With --disk: Same build takes ~80 minutes

Questions

1. Is our understanding correct that --disk uses VirtIO block device rather than VirtioFS?
2. Are there known performance characteristics differences between VirtioFS and VirtIO-blk for write-heavy workloads?
3. Does VirtioFS have optimisations for small file operations that VirtIO-blk lacks?
4. We format as APFS and mount as a block device - does this additional layer (block device → APFS → file operations) introduce overhead compared to direct VirtioFS access?
5. Are there any Tart or Virtualization.framework optimisations we should enable for CI/CD use cases?

---

Thank you for this excellent tool! We're committed to making it work optimally for our CI/CD infrastructure.

[fkorotkov]

We don't have much experience with running IO intensive operations on attached disks but I would suggest checking two things:

1. Trying sync=none option for your run command: tart run "vm-image" --disk="/dev/diskX:sync=none"
2. Try using Tahoe hosts and use new ASIF format for disks.

PS if you have Priority Support package feel free to email the support address (can't figure it out by your GH profile), there might be some subtle caveats for EC2 Macs and network volumes they have. Will need a bit more details that you might like to disclose in a private email thread.

[Sn0wCrack]

This may be related to the general performance issues that Virtualzsation.framework has with disk writes.

It's been noted 1 that running echo "write through" > /sys/block/vda/queue/write_cache can improve performance massively.

In our own base image we've added in the following udev rule under /etc/udev/rules.d/99-vda-write-through-cache.rules that will automatically apply this change on boot.

ACTION=="add|change", KERNEL=="vda", SUBSYSTEM=="block", ATTR{queue/write_cache}="write through"

[arash01]

Will give it a crack, thanks 👍