diff options
Diffstat (limited to 'docs/design')
| -rw-r--r-- | docs/design/2026-06-25-zfs-vm-test-coverage.org | 39 |
1 files changed, 29 insertions, 10 deletions
diff --git a/docs/design/2026-06-25-zfs-vm-test-coverage.org b/docs/design/2026-06-25-zfs-vm-test-coverage.org index 694478f..d9625e0 100644 --- a/docs/design/2026-06-25-zfs-vm-test-coverage.org +++ b/docs/design/2026-06-25-zfs-vm-test-coverage.org @@ -70,9 +70,10 @@ test VM (skip the passphrase prompt; encryption isn't what we're validating). current/non-ZFS), picks the matching archangel config, and writes a profile-named image: =vm-images/archsetup-base.qcow2= (default) vs =vm-images/archsetup-base-zfs.qcow2=. Same =clean-install= snapshot name. -- =run-test.sh= + Makefile take the same =FS_PROFILE= and select the image + - the matching archsetup config (=archsetup-vm.conf= vs =archsetup-vm-zfs.conf=, - the latter with the ZFS filesystem settings). =make test FS_PROFILE=zfs=. +- =run-test.sh= + Makefile take the same =FS_PROFILE= and select the image (via + =init_vm_paths=). The archsetup run config (=archsetup-vm.conf=) is *shared* — + archsetup auto-detects ZFS from the live root, so no per-profile run config is + needed. =make test FS_PROFILE=zfs=. ** C. Bare-metal runner migration Mirror the VM runner's fix in =run-test-baremetal.sh=: @@ -109,12 +110,30 @@ analyze_log_diff, categorize_errors, generate_issue_report, VALIDATION_*. - *P-E* delete the dead shell-sweep functions (the standing P5 follow-up). * Open questions -1. *Does archangel support a ZFS-root config out of the box?* Verify before P-A; - if not, that's its own sub-task (or a feature request to archangel). -2. *Two images vs one image + two snapshots?* Lean two images — ZFS vs ext4 are - different on-disk layouts; cleaner than juggling snapshots on one disk. -3. *Profile on run-test.sh vs a separate run-test-zfs.sh?* Lean a =FS_PROFILE= - param on the existing runner — avoids duplicating the harness. -4. *Disk size / RAM for the ZFS VM* (ZFS wants more RAM than the 4G default?). +1. *Does archangel support a ZFS-root config out of the box?* RESOLVED (yes). + ZFS is archangel's *default* filesystem (=FILESYSTEM=zfs=, validated by + =installer/lib/config.sh:validate_filesystem=), with =NO_ENCRYPT=yes= for an + unattended unencrypted install and a ready =installer/velox-zfs.conf.example= + to model. No archangel work needed. +2. *Two images vs one image + two snapshots?* RESOLVED — two images. ZFS vs + btrfs are different on-disk layouts; cleaner than juggling snapshots on one + disk. =btrfs= keeps the legacy unsuffixed =archsetup-base.qcow2=; =zfs= gets + =archsetup-base-zfs.qcow2=. +3. *Profile on run-test.sh vs a separate run-test-zfs.sh?* RESOLVED — + =FS_PROFILE= env param on the existing runner + Makefile, no duplicate + harness. +4. *Disk size / RAM for the ZFS VM* — start at the 4G RAM / 50G disk defaults; + bump =VM_RAM= only if the ZFS install OOMs (decide at P-C build time). 5. *Should the bare-metal runner stay at all once a ZFS VM exists*, or does the ZFS VM profile make it redundant for everything except real-hardware smoke? + Defer until after P-D. + +* Design corrections (found during P-A/P-B grounding) +- The "non-ZFS" base is *btrfs*, not ext4 — =archsetup-test.conf= sets + =FILESYSTEM=btrfs=. The profile axis is zfs vs btrfs throughout. +- *No =archsetup-vm-zfs.conf= is needed.* archsetup reads no filesystem key; it + auto-detects ZFS from the live root via =is_zfs_root()= (=findmnt -n -o FSTYPE + /=, archsetup:688). The ZFS branch (sanoid, zfs-scrub timer, mkinitcpio udev + hook, docker zfs storage driver) fires whenever the running root is ZFS. So + only the *archangel* base config and the base *image* differ per profile; the + archsetup run config (=archsetup-vm.conf=) is shared. |