Yesterday we managed to copy a few gigs of UNIX files to ext4fs on IABSD with journaling enabled.
Crashing the system is not necessary to test as we managed to write BSD regress test suite for ext4fs using VMM/VMD. It is a slow process but the tests are exhaustive.
Now adding some optimizations we can reach 12MB/s on a recent NVMe. The optimizations are very difficult to phase in as it hangs the system in deadlock and triggers fsck on our FFSv2 filesystems hosting the git repo which gets broken now and then. FFSv2 completely sucks in terms of data loss at cold reboot. I'm regularly losing important files. Backups work indeed.
› it works ! rsync is copying
• Excellent! That confirms the handle-aware metadata access fixed the rsync getblk self-deadlock.
Let rsync finish, then we should verify the copy and mark the corresponding plan.md and opt.md items complete.
4:40 PM
› once it will work it will make full backups of the whole filesystem except for booting cold reboot we
only replay the journal and avoid a full fsck
• Exactly. Once rsync completes reliably, /raid1/a becomes a practical full-system backup target.
After an unclean shutdown, ext4fs should:
A full e2fsck remains necessary only for journal corruption, detected metadata inconsistency, or scheduled offline verification—not every cold reboot.
4:41 PM
› we tested journal corruption and it can only happen if the disk is damaged
• Right—under the failure model we tested, ordinary crashes and interrupted writes leave a replayable journal, not a corrupt one.
Journal corruption would now indicate an external integrity failure such as damaged media, controller/firmware corruption, bad DMA or memory, or an uncovered driver bug. In that case ext4fs detects the checksum/structure failure, preserves RECOVER, and fails closed instead of applying suspect metadata.
4:42 PM