Context
CanonicalStoreMigrationIntent persists the Linux statx.stx_mnt_id of the store root as one of its three root identity coordinates, and the frozen 256-byte intent layout in conformance/segment-store/v2/definition.tsv reserves the field. Mount identifiers are not stable across unmount, remount, or reboot on the same ext4 filesystem.
Today the coordinate is compared only against same-process observations (FilesystemStoreMigrationAuthority::verify_root_identity before mutation, FilesystemVersionTwoAdmission::reopen against the intent on reopen), so a legitimately remounted store already refuses version-two reopen with RootIdentityChanged { coordinate: Mount, .. } even though inode and contents are unchanged. Partial-prefix migration recovery (PR #78 checklist item 7, KEEP-MIGRATION-004) would compare against the persisted value across a restart and reject the store's own recovery.
Raised by Codex on PR #78 (review thread on migration_intent_encoder.rs) and as S3 in the self-audit.
Decision needed before item 7
Either revise the intent format (a format revision with a new golden record) so the mount coordinate is not persisted, or define a restart-stable recovery coordinate (device + inode of the root and of FORMAT, or a filesystem UUID) and specify how a remounted store re-admits. The comparison sites and the RootIdentityChanged refusal stay; only the coordinate changes.
Acceptance
- Documented decision in
docs/formats/segment-store-v2/recovery.md and requirements.md.
- A law that reopens a migrated store after a simulated remount (different mount id, same device and inode) and gets the decided behaviour.
KEEP-MIGRATION-004 evidence does not depend on the transient coordinate.
Context
CanonicalStoreMigrationIntentpersists the Linuxstatx.stx_mnt_idof the store root as one of its three root identity coordinates, and the frozen 256-byte intent layout inconformance/segment-store/v2/definition.tsvreserves the field. Mount identifiers are not stable across unmount, remount, or reboot on the same ext4 filesystem.Today the coordinate is compared only against same-process observations (
FilesystemStoreMigrationAuthority::verify_root_identitybefore mutation,FilesystemVersionTwoAdmission::reopenagainst the intent on reopen), so a legitimately remounted store already refuses version-two reopen withRootIdentityChanged { coordinate: Mount, .. }even though inode and contents are unchanged. Partial-prefix migration recovery (PR #78 checklist item 7,KEEP-MIGRATION-004) would compare against the persisted value across a restart and reject the store's own recovery.Raised by Codex on PR #78 (review thread on
migration_intent_encoder.rs) and as S3 in the self-audit.Decision needed before item 7
Either revise the intent format (a format revision with a new golden record) so the mount coordinate is not persisted, or define a restart-stable recovery coordinate (device + inode of the root and of
FORMAT, or a filesystem UUID) and specify how a remounted store re-admits. The comparison sites and theRootIdentityChangedrefusal stay; only the coordinate changes.Acceptance
docs/formats/segment-store-v2/recovery.mdandrequirements.md.KEEP-MIGRATION-004evidence does not depend on the transient coordinate.