And yeah i read that diskfs_sync_everything is not the right place, but
didn't yet change it. Was focused on some of the details of the journal.c
tonight.
More to follow soon.

On Thu, Jun 26, 2025 at 11:40 PM Milos Nikic <nikic.mi...@gmail.com> wrote:

> Thanks all,
> I'm attaching here the initial super early patch.
>
> This is very much experimental and incomplete — the current implementation
> does *not* yet capture all changes, enforce ordering guarantees, or
> support recovery — but I wanted to share it early to gather feedback.
>
> It logs things like this into /tmp/journal.log
>
> === BEGIN TX 504 === [2025-06-27 07:35:05.116]
> action: sync
> name: (unknown)
> parent inode: 0
> inode:        49142
> mode:         010100666
> size:         0 bytes
> nlink:        1
> blocks:       8
> mtime: 1751006105
> ctime: 1751006105
> === END TX 504 ===
>
> There is a small header on journal.c that says what it does (and what it
> doesn't yet do).
>
> I tried to make it thread safe, and somewhat smart (linear buffer, flushes
> when full and so on), but i have only been on it for short periods of time.
>
> Thanks in advance
> Milos
>
>
> On Thu, Jun 26, 2025 at 4:52 PM Samuel Thibault <samuel.thiba...@gnu.org>
> wrote:
>
>> Hello,
>>
>> Milos Nikic, le mer. 25 juin 2025 14:36:04 -0700, a ecrit:
>> > As a learning and exploration effort, I've started working on a toy
>> journaling
>> > layer inside ext2fs. The goal is to understand how journaling might
>> look in a
>> > user-space filesystem like Hurd’s, and whether it's feasible to
>> implement a
>> > basic journaling mechanism incrementally.
>>
>> Being userspace probably doesn't really have impact on the
>> implementation of journaling.
>>
>> > So far, I’ve added a non-intrusive skeleton that:
>> > - Hooks into `diskfs_init_diskfs` (for init) and
>> `diskfs_sync_everything` (for
>> > flushing),
>>
>> You'll want to plug at a lower level than diskfs_sync_everything, to
>> catch all data and metadata writes and write to the log ahead of them.
>>
>> For real safety, we will need to introduce write barriers at the device
>> RPC layer.
>>
>> Samuel
>>
>> > - Buffers log entries in memory and flushes to `/tmp/journal.log`,
>> > - Outputs to the screen during boot if writing fails (e.g., due to
>> early boot
>> > or read-only FS),
>> > - Is wrapped in a minimal interface (`journal_log`,
>> `flush_journal_to_file`)
>> > with guards for safety.
>> >
>> > The goal is **not** a production journaling layer, but rather to build
>> a base
>> > to explore correctness, crash safety, and design directions.
>> >
>> > You can see it show up during boot with messages like:
>> >
>> > Toy journaling: journal_init() called
>> > Toy journaling: flushing journal to disk...
>> >
>> > I can also verify the presence of one of the init messages in
>> /tmp/journal.log
>> >
>> > Before proceeding further:
>> > - I'd appreciate any guidance on whether this is being plugged in the
>> right
>> > places.
>> > - Are there preferred conventions or hooks I should be using instead?
>> > - Would you be open to reviewing it as a small patch series while I
>> iterate, or
>> > should this stay on a branch until it's more mature?
>> >
>> > Thanks in advance for any input — and for the warm welcome so far!
>> >
>> > Best,
>> > Milos Nikic
>>
>

Reply via email to