Hi all, I’m working on a user-space metadata journaling layer for libdiskfs and have run into a boot-time issue I hope to get guidance on.
The goal is to capture metadata changes very early in the boot process — ideally even before fsck — and flush them to a raw device (backed by a file or similar) synchronously (i.e. the calling thread waits for the result of the write). However, I’ve found that attempting to open() the raw device during early boot (e.g. from journal_init(), called via diskfs_init_diskfs) can block indefinitely. This happens even with O_NONBLOCK, and also applies to access(), stat(), etc. — all of which appear to stall while the device layer is still coming online. As a workaround, I buffer entries in memory and defer writes until later, and I’m also experimenting with watchdog threads that poll for readiness. But I’d like to find a more robust and principled solution. Specifically: - When is it considered safe for user-space code to open and write to a persistent block-backed device? - Is there a recommended hook (or mechanism) I could wait for before beginning replay or issuing synchronous flushes? - Or is this limitation expected, and journaling systems should stage initialization accordingly? Thanks in advance for any insight or suggestions. Milos
