Hi Diego and Joshua

Thanks for the thoughts. Let me address everything that I can:

1) Why not reserve an inode for the journal?
Yes — ext2/ext3/ext4 already have fields like s_journal_inum and
s_journal_dev in the superblock for pointing to a journal inode.
For this prototype, I deliberately avoided that route for a couple of
reasons:

    - Independence from ext2 allocation rules: The current implementation
places the journal in a raw reserved region outside the ext2-managed block
space. This guarantees it’s untouched by ext2’s allocator, fsck, or normal
file deletion.

    - Early boot simplicity: By having a fixed offset+size directly in the
superblock hint, ext2fs can start journaling without having to traverse
inode tables or block maps before the system is stable.

    - Cross-FS potential: Since the logic is in libdiskfs and uses only the
hint+store offsets, it could theoretically be reused for other
libdiskfs-based file systems without having to emulate ext3/4’s inode-based
journal semantics.

That said, nothing in the design forbids switching to an inode-backed
journal in the future — especially if integration with e2fsprogs or more
seamless deployment is desired

2) Superblock backup copies

You’re right — ext2 keeps backup superblocks at various block group
boundaries. In a production-ready setup, any change to the journaling hint
in the primary superblock should also be applied consistently to those
backups.

In this prototype, *that’s not done intentionally*. The helper script (
journal-hint2.sh) is only meant as a *bring-up tool* for experimentation:

- it touches *only* the primary superblock.

- it assumes a fixed journal size at the partition end.

- It’s meant for testing on copied disk images to make it easy-er to start
up. It's not a production tool by any stretch of the imagination.

For a production deployment, the right approach would be to integrate with
e2fsprogs (tune2fs / mke2fs) so the hint is validated and written to *all*
backup superblocks in one go. That would make it fsck-proof and consistent
across block groups.
So:
 - Current method = simplest path to get a working journal without
modifying e2fsprogs.
 - Prototype script = not production tooling.
 - Future improvement could include an inode-backed journal and proper
backup superblock updates.
We can go anywhere from here really

@Joshua
Thanks! Great to hear you shrank /home successfully.
I got to say I never even tried on real hardware so thanks for trying! I
also never tried it on a separate mount :). Im curious of the results you
will have.

The script should still work whether its the image or real hardware:
On real hardware one can use something like:
sudo ./contrib/journaling/journal-hint2.sh /dev/sdXY on

A couple safety notes for running the hint script on real hardware:
- Please run it on the partition device (e.g., /dev/sdXY), not on the whole
disk.
- Do not write the hint while the filesystem is mounted read-write. ext2
caches the superblock; writing it raw while mounted can be lost or cause
inconsistency.

For /home (assuming it’s a separate ext2 partition):
0) make a backup if you can
1) unmount /home (close apps first)
sudo umount /home
2) ensure clean state
sudo e2fsck -f /dev/sdXY
3) write the journaling hint (device instead of .img)
sudo ./contrib/journaling/journal-hint2.sh /dev/sdXY on
4) flush and verify
sudo blockdev --flushbufs /dev/sdXY sudo dumpe2fs -h /dev/sdXY | less   #
confirm the hint fields changed
5) remount /home and test
sudo mount /home # reboot into Hurd and check for [JOURNAL] lines before
fsck

Btw the journal (if it is not in debug) is extremely silent. You will
likely see nothing in the logs unless there are some errors (out of memory
or things like that). If everything is working you should start seeing
folders (maybe empty) in your /restore after every reboot.
(/restore/[timestamp1], /restore/[timestamp2])
(they will grow and grow, i didn't implement any folder management so far!)

On Wed, Aug 13, 2025 at 11:33 AM Joshua Branson <jbra...@dismail.de> wrote:

> Milos Nikic <nikic.mi...@gmail.com> writes:
>
> > Hey folks,
> >
> > Here’s a link to my personal repo where you can try metadata journaling
> for Hurd ext2:
> >
> > https://github.com/mnikic/hurd-journaling/tree/journal-main
> >
> > I keep that branch up to date with upstream plus the journaling changes.
> >
> > Release (v0.9-journal):
> > https://github.com/mnikic/hurd-journaling/releases/tag/v0.9-journal
> >
> > Setup instructions (including scripts and links) are here:
> >
> https://github.com/mnikic/hurd-journaling/blob/journal-main/JOURNALING.md
> >
> > If the setup (resizing ext2, etc.) feels too involved, let me know — I
> can work on a script to automate the whole process.
>
> I'm working on using the journal for my /home partition (1).
>
> I've resized my /home partition by 8 MiB, which your guide made easy.
>
> Your script to write the journal hint in the ext2 superblock assumes the
> user is using a *.img file.  I am running the Hurd on real hardware.
> Would it be possible for you to tweak the script so that I can run it?
>
> Thanks!
>
> Joshua
>
> 1.  I have a / and /home partition.  I would like to try to use the
> journal for /, but that's somewhat harder to do.  I'd have to boot my
> Hurd T43 laptop with linux on a usb stick...I just haven't done that yet.
>
> --
>
> Joshua Branson
> Sent from the Hurd
>

Reply via email to