Linux – Risks involved with lazy_itable_init=1 for ext4 fs on SD card

ext4linuxsd card

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?

Best Answer

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.

Related Question