4

My setup is the following:

  • Linux kernel 2.6.28
  • e2fsprogs 1.42.7
  • 64 GB class 10 SD card

I am attempting to speed up the time it takes to format the entire card to an ext4 filesystem. My research has pointed me towards the lazy_itable_init=1 option for mkfs.ext4. If I understand correctly, these options will improve the speed of formatting the SD card partition considerably, however this is achieved by deferring the initialization of the inodes to when the filesystem is first mounted. This initialization will then be performed in the background by the kernel (v2.6.27+ only)

The man pages have the following sentence about this option:

This [flag] speeds up filesystem initialization noticeably, but it requires the kernel to finish initializing the filesystem in the background when the filesystem is first mounted.

My question is, what happens if the kernel does not finish initializing the filesystem in the background?

I have tested this by formatting using the lazy_itable_init=1 option, mounting the file system and then removing the SD card shortly after. When I insert the card again, I can mount the partition without problem and wrote several files of 100 MB containing zeros. These were read back and were correct.

Is this just a fluke positive, would I be guaranteed to see this behavior after such a sequence of events?

Improve this question
1
  • I don't think the kernel makes many guarantees when you rip the drive underlying a mounted filesystem. I bet your SD card doesn't, either (e.g., if you remove it while its in the middle of moving a block for wear leveling).
    – derobert
    Jun 10, 2013 at 21:08

1 Answer 1

Reset to default
2

The reason the inode tables are initialized with zeros it to make sure that any garbage that happened to be there before does not get misinterpreted as a valid inode by e2fsck. Normally it won't make any difference but if e2fsck detects errors, it may try to recover by heuristically recognizing inodes whether or not the bitmap indicates they are in use, and so it may try to recover invalid inodes that you will then have to remove from /lost+found.

Improve this answer
4
  • As a follow up, would you know of anyway to query or get notification from the kernel about when this background initialization has completed?
    – lbuchy
    Jun 10, 2013 at 22:43
  • It happens as you use the disk. So it's never really fully completed, unless the disk is completely full. When you see the kernel thread ext4lazyinitialization running, it means the init is happening. This mechanism degrades I/O performance considerably, I don't understand why it's enabled by default. Maybe it made sense in 2010, but not with very large disks that exist these days...
    – David Faure
    Aug 29, 2021 at 9:26
  • @DavidFaure, no, it gets fully completed when the thread doing the initializing finishes the job. It has nothing to do with how full the disk is.
    – psusi
    Sep 9, 2021 at 17:07
  • @psusi That's indeed the theory I read online. The code must be buggy, because it doesn't match my experience. I had a 8TB ext2 partition (on a USB HDD) which would trigger ext4lazyinitialization very very often, almost every time I was using it. I have since reformatted the disk differently to get rid of that annoying problem.
    – David Faure
    Sep 10, 2021 at 19:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .