Summary
The JFAT driver backing a persistent VDI (oracle-disk.vdi on IDE hdb1, mounted at /devices/hdb1) shows three robustness problems that make the disk unusable as reliable scratch space for automated guest-side testing:
- Transient
ENOENT right after boot — immediately after boot, cat/java FileReader on files that provably exist fail with can't find ...; retrying seconds later succeeds.
- Writes lost without manual
sync — files written via shell > redirection vanish after an abrupt poweroff unless sync is run first.
- Bulk file creation wedges the guest — extracting a ~1000-file zip onto JFAT never completes; the shell stops responding, Ctrl-C/Ctrl-Z are ineffective, and only a power cycle recovers.
Environment
- JNode
0.2.9-dev (x86 32-bit, cd-x86-lite, default + all-plugins entries)
- VirtualBox 7.2.6, host Ubuntu, guest 1024–2048 MB RAM
- Disk: fixed VDI attached as IDE secondary master, single FAT partition (
hdb1, JFAT (rw))
- Observed 2026-09-17 via serial console (UART2 pipe) + VGA screenshots; KDB log on UART1 shows no panic in these cases
Reproduction
A. Transient ENOENT after boot
# cold boot, then immediately:
cat /devices/hdb1/mini.txt
# -> Exception in command: cannot open '/devices/hdb1/mini.txt': can't find /devices/hdb1/mini.txt
# wait a few seconds / retry:
ls /devices/hdb1
# -> 11B 2026.09.17 09:49 mini.txt (file was there all along)
cat /devices/hdb1/mini.txt
# -> HashProbe5 (now works)
The same file written pre-reboot (echo 'HashProbe5' > /devices/hdb1/mini.txt, wc -c = 11 B) is reported missing on first access after reboot, then found. Smells like a stale/empty directory cache that is only refreshed on the second access.
B. Writes lost without sync
echo 'HashProbe5' > /devices/hdb1/mini.txt
# abrupt poweroff (VBoxManage controlvm poweroff), reboot
ls /devices/hdb1 # file missing or 0 bytes
With an explicit sync after the write, the file survives. close() on the shell redirection stream apparently does not flush through the FAT write-back cache to stable storage. At minimum this needs documenting; preferably close() should flush.
C. Bulk creation wedge
cd /devices/hdb1/l2w
unzip /devices/sg0/ox/mauve/mauve-pkgs.zip # 1068 small files, 2 MB total
# -> prints "creating: ..." for a while, then no prompt for 10+ minutes
# Ctrl-C (--interrupt) and Ctrl-Z (--suspend) do not recover the shell
# KDB log shows no OOM/panic; only remedy is poweroff
Expected behavior
- First post-boot access returns correct results (no phantom ENOENT).
- Closed files survive power loss (or the
sync requirement is documented in help sync / shell guide).
- Bulk creation either completes (slow is fine) or fails with an error and returns to prompt — never a hard wedge.
Impact
Blocks using a persistent VDI as guest scratch space for automated test campaigns (mauve differential runs need list/result files on a writable FS; RAMFS is mounted read-only and the CD is read-only). Current workaround is tiny files + sync + retries, which is slow and flaky.
Triage Addendum (auto, 2026-09-24)
- Area / Kind: area/fs (Sub: jfat/FAT12-16-32) + kind/bug
- Blast radius: Tentative L4 subproject (jfat, VFS lookup/cache, and shell stream paths; data-loss and hang risk)
- Expected scope: Pending evidence; bound each symptom to the narrowest JFAT/VFS/stream path, without ASM, public API, or unrelated boot changes
- Test path: Pending exact boot procedure; then
cd fs && ant test and sh build.sh cd-x86-lite with a VBox persistent-VDI reproduction
- Merge signal: human-review (insufficient signal)
- Gaps: Missing exact boot/run command and commit; no UART1/UART2 failure excerpt; no reproducible VDI/partition details; no stated durability contract for
close() versus sync; no wedge last-filename/thread-state capture
- Full report:
## Triage comment below.
✅ Ticket Runner Status
| Field |
Value |
| Phase |
DONE |
| Turn |
0/3 |
| Retries |
2/3 |
| PR |
- |
| Started |
2026-09-24T22:18:37.427Z |
Summary
The JFAT driver backing a persistent VDI (
oracle-disk.vdion IDEhdb1, mounted at/devices/hdb1) shows three robustness problems that make the disk unusable as reliable scratch space for automated guest-side testing:ENOENTright after boot — immediately after boot,cat/java FileReaderon files that provably exist fail withcan't find ...; retrying seconds later succeeds.sync— files written via shell>redirection vanish after an abrupt poweroff unlesssyncis run first.Environment
0.2.9-dev(x86 32-bit,cd-x86-lite, default + all-plugins entries)hdb1,JFAT (rw))Reproduction
A. Transient ENOENT after boot
The same file written pre-reboot (
echo 'HashProbe5' > /devices/hdb1/mini.txt,wc -c= 11 B) is reported missing on first access after reboot, then found. Smells like a stale/empty directory cache that is only refreshed on the second access.B. Writes lost without
syncWith an explicit
syncafter the write, the file survives.close()on the shell redirection stream apparently does not flush through the FAT write-back cache to stable storage. At minimum this needs documenting; preferablyclose()should flush.C. Bulk creation wedge
Expected behavior
syncrequirement is documented inhelp sync/ shell guide).Impact
Blocks using a persistent VDI as guest scratch space for automated test campaigns (mauve differential runs need list/result files on a writable FS; RAMFS is mounted read-only and the CD is read-only). Current workaround is tiny files +
sync+ retries, which is slow and flaky.Triage Addendum (auto, 2026-09-24)
cd fs && ant testandsh build.sh cd-x86-litewith a VBox persistent-VDI reproductionclose()versussync; no wedge last-filename/thread-state capture## Triagecomment below.✅ Ticket Runner Status