Repository navigation
fix(apple): use explicit cached disk modes for Linux guests - #144
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Linux guests sometimes die during long write-heavy jobs with guest filesystem
Input/output error(runner log writes fail, exit 134) or stop answering SSH. The Swift helper attached Linux disks withVZDiskImageStorageDeviceAttachment(url:readOnly:), leaving caching and synchronization modes implicit, which is the configuration other Virtualization.framework projects saw corrupt Linux filesystems (lima #1957, Tart #675, UTM's filesystem workaround). They fixed it by choosing the modes explicitly.Linux boot disks and repository cache disks now use
cachingMode: .cachedandsynchronizationMode: .full. macOS guest disks and the read-only setup seed are unchanged.Proof: every Linux VM I booted overnight in isolated dev homes used this helper (image preparations, tools/serial/headroom/sleep/memory checks, stress rounds) without a disk error. In a controlled A/B under real load (2 VMs per arm, 20 minutes of repeated
pnpm installof this repository plus an fsync file writer, while the host wrote 8 GiB files to the same USB SSD, guest memory well below host RAM), both arms had 0 kernel I/O errors and 0 hung tasks; the new mode completed 24 install cycles per VM versus 21 with implicit modes, so no throughput regression. A second round ran the full CI loop of this repository in each guest (pnpm install+pnpm check) under the same host write pressure: again 0 I/O errors and 0 hung tasks in both arms, with equal throughput (2 CI cycles and 4 writer rounds per VM). Neither arm reproduced the field EIO, so this PR is backed by the documented Virtualization.framework behavior rather than an observed before/after failure.swift build --package-path native/applepasses.Summary by CodeRabbit