Hello Michael, Thanks! I have done some comparisons in my tree, which is slightly ahead of what I have sent (I let patches cook for a while before sending). So far the journal costs little, but it depends on the workload. These were on a 64-bit Hurd VM with 4 GB of RAM:
- rm -rf of an extracted Linux kernel tree, followed by sync: the journaled filesystem is about twice as fast (32 s against 1m07s). That workload is almost all metadata, which the journal batches into commits instead of writing in place so perhaps not very surprising. - tar -xf of the same tree: the journaled filesystem is about 5% slower (1m58s against 1m52s). An aritficial workload that syncs after every file operation would show a larger cost, since every sync is a journal commit. In normal use, like large apt upgrades, I have not noticed a difference, but I have not timed those. The journal also uses memory: a fixed 4 MB intercept pool, plus shadow copies of the metadata blocks in flight, which grow with load (around 50 MB at peak during a large untar on a 2 GB i386 VM). I am working on removing ext2fs's explicit syncs when a journal is active. Fewer syncs mean fewer rushed pager writes, so the intercept pool could shrink or go away. Once everything is sent, I will do a more thorough round of benchmarks and post the numbers. I hope this helps. Thanks, Milos On Mon, Oct 19, 2026 at 9:26 AM Michael Banck <[email protected]> wrote: > Hi Milos, > > On Mon, Oct 19, 2026 at 09:10:25AM -0700, Milos Nikic wrote: > > This series closes the biggest gap in the journal so far: directory > > blocks were not journaled. > > First off, many thanks for all the work you have done on journalling in > the past months, it was a large gap in the Hurd's functionality and is > much appreciated. > > One question though: after the recent fixes and this additonal > functionality, I wonder what the current overhead is using the journal. > Did you re-run some benchmarks (I think you or others originally did > some?) now? > > > Michael >
