OrbStack fails to start: BTRFS "corrupt leaf" (overlapping extents) on data.img.raw, mount fails with EIO #2757

Describe the bug

After an unclean shutdown (host exit diagnostics: "unknown crash"), OrbStack no longer starts. The VM boots, then fails to mount the user data volume (/dev/vdb1, BTRFS) because the extent tree has a corrupt leaf with overlapping extents. Both the normal mount and the backup-roots recovery fail with EIO. OrbStack then says the data is still readable in recovery mode and shuts the VM down.

Key log lines:

BTRFS info (device vdb1): start tree-log replay
BTRFS critical (device vdb1): corrupt leaf: block=9955147776 slot=16 extent bytenr=9365913600 len=1048576
  previous extent (9364865024 168 12582912) overlaps current extent (9365913600 168 1048576)
BTRFS error (device vdb1): block=9955147776 write time tree block corruption detected
BTRFS error (device vdb1): error while writing out transaction: -5
BTRFS error (device vdb1 state A): Transaction 87356 aborted (error -5)
BTRFS error (device vdb1 state EA): failed to recover log trees with error: -5
BTRFS error (device vdb1 state EA): open_ctree failed: -5
!!! Failed to mount data: failed to mount /dev/vdb1 to /data: EIO: I/O error
[*] Attempting to recover data (backup roots)
!!! Failed to recover via backup roots: EIO: I/O error
!! OrbStack data could not be mounted, but it is still readable in recovery mode.
!! Do NOT reset or delete OrbStack data: it can likely be recovered.
!!! Init failed: failed to mount /dev/vdb1 to /data: EIO: I/O error

The same leaf (block 9955147776, gen 87356) fails identically on both attempts. It was dirtied by transaction 87356 during log replay. The overlapping entries are item 15 (extent 9364865024, len 12582912, gen 86753) and item 16 (extent 9365913600, len 1048576, gen 87356), both owned by inode 4009835 on root 256.

Context: host exit diagnostics say reason "unknown crash", raw wait status 27392 (0x00006B00), raw flags 0x86000000. At 08:49:18 vmgr logged replaced running vmgr (old build macho:05775f98..., new build macho:6f9b53fd..., outcome=stopped), then started a new VM right away. The host disk was about 93% full (14 GB free). The virtio_snd control message timeouts in the log look unrelated.

Questions:

1. Is there a supported way to run btrfs check or btrfs rescue (for example zero-log, or clearing the free space tree) against data.img.raw, or to mount it read-only to export containers and volumes?
2. Could the vmgr replacement and immediate VM start have raced with the previous VM's shutdown or log write?

To Reproduce

I do not have a reliable reproduction. The VM was running (Docker containers, including a local n8n instance), the host exited with "unknown crash", and vmgr was replaced by a new build at 08:49:18 and started a new VM immediately. Every start after that failed with the BTRFS errors above.

Expected behavior

The VM mounts the data volume, or the data can be recovered or repaired with a supported procedure.

Diagnostic report (REQUIRED)

The VM never reaches a state where a diagnostic report can be generated from the app, so I am pasting the relevant details instead.

OrbStack 2.2.4 (2020400), commit 1c4c8267f3256f8df9e4d80a2e50ac8f1136956c
macOS 15.8, Apple Silicon (arm64)
Guest kernel: 7.2.9-orbstack-00391-g2b298d05fbd4
Data image: ~/Library/Group Containers/HUAQ24HBR6.dev.orbstack/data/data.img.raw (245107802624 bytes apparent, about 16 GB on disk)

Workaround applied: I kept a copy-on-write clone of the corrupted image, moved the corrupted image aside (intact, not deleted), and let OrbStack create a fresh data image, which now starts. The corrupted image is preserved. I can provide the full vmgr.log, the host exit diagnostics, or the image itself on request.

Screenshots and additional context (optional)

No response