Archive for January, 2022

On ext4 and forcing the completion of lazy initialization

January 23, 2022

I’m writing this post on an almost dead blog just to share a bit of information some may find useful, especially since I didn’t find a solution elsewhere on the web.

The ext4 filesystem is the default choice on most Linux distributions, and it has a not well known “feature” -enabled by default-, that is lazy initialization. The idea is: to speed up formatting a partition, the inode table and journal are not zeroed out. This leaves a working filesystem, maybe more brittle in case of filesystem corruption, but makes formatting much faster. This task is then deferred to a kernel thread, ext4lazyinit that will slowly do it occupying only a small portion of the disk bandwidth.

On paper it looks fine, but assume you have a mechanical disk that you connect sporadically, and want to write lots of data to it sequentially. Then the performance impact of lazy initialization then becomes significant.

Of course, you can format a partition without this feature, by doing something like:

mkfs.ext4 -E lazy_itable_init=0,lazy_journal_init=0 <partition>

But the problem is you have to remember to do it. Now, assume you already formatted a drive, wrote a few hundred gigabytes to it, noticed the write performance sucks and discovered that you forgot to format it without lazy initialization, how do you force lazy initialization to complete so that your drive can be fast again without formatting it again?

Surprisingly, I couldn’t find any info on the web on how to change my mind and “flush” the lazy init task after a disk is formatted. At first I tried to just leave the disk connected (it’s an external drive), but after a full 24 hours there was no sign the lazy init was going to complete anytime soon, so I tried looking deeper.

On this page i found this promising option:

init_itable=n

The lazy itable init code will wait n times the number of milliseconds it took to zero out the previous block group’s inode table. This minimizes the impact on the system performance while file system’s inode table is being initialized.

It appears to be designed to slow down the lazy init to reduce the impact, but I wonder what happens if I mount a filesystem with init_table=0… The ext4lazyinit taks started consuming 100% CPU, the disk access became very busy, and in 10 or so minutes the task was completed.

Here’s the command that did the trick form me, enjoy:

mount -o init_itable=0 <partition> <mountpoint>