When creating an Ext4 file system, the existing regions of the inode tables must be cleaned (overwritten with nulls, or "zeroed"). It really takes time. However, with "lazyinit" feature enable, the creation of a ext4 file system will be significantly accelerated, because it does not immediately initialize all inode tables, initializing them gradually instead during the initial mounting process in background (from Kernel version 2.6.37).
Further more, If enabled and the uninit_bg feature is enabled, the inode table will not be fully initialized by mke2fs. This speeds up file system initialization noticeably, but it requires the kernel to finish initializing the file system in the background when the file system is first mounted. If the option value is omitted, it defaults to 1 to enable lazy inode table zeroing.
Note1: Be careful when testing the performance of a freshly created file system. The "lazy initialization" feature may write a lot of information to the hard disk after the initial mounting and thereby invalidate the test results. At first, the "ext4lazyinit" kernel process writes at up to 16,000kB/s to the device and thereby uses a great deal of the hard disk’s bandwidth.
Note2: lazy_itable_init is turned on by default if the kernel you are running supports automatic background initialization of the inode table ( 2.6.37+ ). Without that support, enabling this option is unsafe as it leaves the inode tables uninitialized
Force ext4 lazy init
By default, lazy init is enable, if you want force to make sure the initialization is running background, run
mkfs.ext4 -O uninit_bg=1 -E lazy_itable_init=1
Disable ext4 lazy init
By default, lzay init is enabled. In order to prevent lazy initialization, advanced options are offered by the mkfs.ext4 command:
mkfs.ext4 -E lazy_itable_init=0,lazy_journal_init=0 /dev/mapper/fc-root
By specifying these options, the inodes and the journal will be initialized immediately during creation
lazy_itable_init[= <0 to disable, 1 to enable>]
If enabled and the uninit_bg feature is enabled, the inode table will not be fully initial-
ized by mke2fs. This speeds up filesystem initialization noticeably, but it requires the
kernel to finish initializing the filesystem in the background when the filesystem is first
mounted. If the option value is omitted, it defaults to 1 to enable lazy inode table zero-
lazy_journal_init[= <0 to disable, 1 to enable>]
If enabled, the journal inode will not be fully zeroed out by mke2fs. This speeds up
filesystem initialization noticeably, but carries some small risk if the system crashes
before the journal has been overwritten entirely one time. If the option value is omitted,
it defaults to 1 to enable lazy journal inode zeroing.
-E lazy_itable_init don't change file system creation result, only speed up the process.
For ext4 file system hold large files
In most case you actually want some options that match your usage patterns and not only speed up filesystem creation but also allow faster usage and more usable space.
For a filesystem that will hold large files, try the following options:
mkfs.ext4 /dev/sdXX -O sparse_super,large_file -m 0 -T largefile4
-T largefile4 picks options in
/etc/mke2fs.conf which generally contain something like:
inode_ratio = 4194304 blocksize = -1
where -m 0 only says not to reserve 5% for root, which is okay for a data (not boot/root) filesystem. 5% of a 8TB disk means 400Gb. That's a pretty significant difference.
man mke2fs for details on each of these options.
Here are relevant extracts:
sparse_super Create a filesystem with fewer superblock backup copies (saves space on large filesystems). large_file Filesystem can contain files that are greater than 2GB. (Modern kernels set this feature
on automatically when a file > 2GB is created.) -i bytes-per-inode Specify the bytes/inode ratio. mke2fs creates an inode for every bytes-per-inode bytes
of space on the disk.The larger the bytes-per-inode ratio, the fewer inodes will be created.
This value generally shouldn't be smaller than the blocksize of the filesystem, since in that
case more inodes would be made than can ever be used.
Be warned that it is not possible to expand the number of inodes on a filesystem after
it is created, so be careful deciding the correct value for this parameter.