generated from erix/meta
[BUG] Existing FAT32 directory metadata VM exceeds its original deadline #70
Labels
No labels
bug
ci
docs
duplicate
enhancement
help wanted
invalid
performance
phase-6
question
refactor
security
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
erix/integration#70
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
The maintained positive FAT32 directory metadata VM times out in the original full regression run. Its acceptance markers are not established; no passing result or root cause follows from a successful sibling run.
Reproduction
Observed in original Integration run 1699, source
fcd7b4a9608f629a12de78c53da5c3615d906b46, using the workflow-selected complete dependency catalog and unchanged parallel VM settings. The existing scenario istests/scenarios/subsystem-e2fs-fat-fat32-directory-metadata-positive.toml; its maintained entry point is:This records the original CI observation; a separate local reproduction has not been performed and no unchanged retry is requested.
Expected and actual behavior
Expected: the complete positive directory metadata scenario reaches every required marker within its existing 120-second QEMU deadline, without authority changes or relaxed progress checks.
Actual: original worker 9 reports
error: qemu timed out after 120sat complete job-log line 55591. That worker's own preceding scenario boundary at line 52883 identifies this case. The complete suite ends at 487 passed and 2 failed out of 489; its other failure is the ext4 quota scenario already tracked separately. The full failed-run log and serial tail remain retained.Environment and identity
fcd7b4a9608f629a12de78c53da5c3615d906b46.604aa1e6682536a3f6df9ec80776ca06a130b69cb9039b937ee07133ab107255.Evidence and prior checks
All six complete logs from original runs 1699/1700 retain 28,483,276 bytes with no warning candidates. Rust and Markdown jobs pass. Both full VM suites finish at 487/489; run 1700 instead retains ext4 quota's 45-second serial stall and ext4 links' 120-second timeout. Those observations do not substitute for this failed FAT32 case or establish a shared cause.
Tracking
Related: quota regression 18, other filesystem regressions 20, performance work 3, WIP PR 12 and Phase 6 completion.
Correlate the actual last guest progress and filesystem requests, preserve source identities and original failures, and fix an identified cause before a changed-input validation. Do not increase deadlines, remove assertions, reduce the required workload or repeatedly rerun unchanged inputs to obtain a pass.
Original full-regression follow-up — 22 September 2026: Integration run 1701 and run 1702, source b06dfad00202, both pass. Six complete original logs total 26,962,712 bytes with zero warning candidates. Each run explicitly records passing ext4 quota, ext4 links and FAT32 directory-metadata scenarios in the full catalog. These are observations of the original submitted runs; no job was restarted or cancelled and no deadline was changed for this follow-up. The prior failures remain retained, and these passes do not establish their cause or failure frequency. This report stays open while the independent timing investigation and current-source regressions continue.
Additional original full-regression observation — 22 September 2026: Integration 1703 and 1704, source
dff878dd35, both pass. Six complete logs total 26,964,178 bytes with zero warnings and explicit ext4 quota/links and FAT32 directory passes in each run. These are observations of the original submitted handles, with no retry or deadline change. They do not establish the cause or frequency of the retained earlier failures, so this report remains open.