mkfs.ext4 is taking hours to complete on 4 TB RAID 5
mkfs.ext4 -O uninit_bg=1 -E lazy_itable_init=1
will force the time consuming parts of the initialization into the background.
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 initialized 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 initialization.
uninit_bg
Create a filesystem without initializing all of the block groups. This feature also enables checksums and highest-inode-used statistics in each blockgroup. This feature can speed up filesystem creation time noticeably (if lazy_itable_init is enabled), and can also reduce e2fsck time dramatically. It is only supported by the ext4 filesystem in recent Linux kernels.
Related videos on Youtube
ArSeN
Updated on September 18, 2022Comments
-
ArSeN over 1 year
I am running mkfs.ext4 on top of LVM on a RAID 5, and it is taking hours to complete. It's a 3 TB, four disks setup, and I'm just doing:
mkfs.ext4 /dev/md0
My stripe size and width seem OK. How can I to speed this up?
-
Joris about 13 yearsYour question is very open ended and lacks almost any information. Without anything to go on, I'd say your raid5 is (re)building and that takes up a lot of IO
-
ArSeN about 13 yearsIndeed, it was the raid rebuilding that was making it drag. In fact i had to wipe out the disks with dd if=/dev/zero of=/dev/sd{a,b,c,d} before raid could be properly resintalled. It was insisting in reading existing blocks on the disk/mess with mbr/screwing linux reinstal before i did this. Not even mdadm --zero-superblocks fixed it.
-
-
psusi almost 13 yearsNote that 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, so they may contain garbage that fsck will mistake as valid inodes under certain circumstances. Also uninit_bg is enabled by default for ext4.