问题现象：

image.png

明明没有什么数据读写，但是使用iostat -dxm 1查看，发现某个盘，io并发度，已经svctm（一般超过15ms就算高的了）都很高

定位过程：
使用iotop -P ，查看有没有什么可疑的IO高的进程，发现ext4lazyinit比较可疑

image.png

在创建Ext4文件系统时，必须清理inode表的现有区域(用null覆盖，或“0”)。这需要一定的时间。但是，启用“lazyinit”特性后，ext4文件系统的创建将显著加快，因为它不会立即初始化所有inode表，而是在后台的初始挂载过程中逐步初始化它们(内核版本2.6.37)

此外，如果启用了uninit_bg特性（默认是启用），那么mke2fs不会完全初始化inode表。这显著加快了文件系统的初始化速度，但是它要求内核在第一次挂载文件系统时在后台完成文件系统的初始化。如果省略该选项值，则默认值为1，以启用惰性inode table 清零。

“ext4lazyinit”内核进程以高达16000 kb /s的速度写入设备，从而使用了大量硬盘带宽。

按道理来说，系统安装了这么久，ext4lazyinit应该早就初始化完退出了的，但是这里ext4lazyinit还在持续运行，所以怀疑在创建文件系统的过程中出现了什么问题

解决方案：
1 先kill 掉占用该磁盘的进程

 lsof 有问题的磁盘分区挂载的目录
kill -9 进程 （先检查进程kill对业务是否有影响）
umount 磁盘分区
mkfs.ext4 -E lazy_itable_init=0,lazy_journal_init=0 磁盘分区
mount 磁盘分区 要挂载的目录

说明：
-E 是mkfs.ext4创建文件系统时指定扩展参数

• lazy_itable_init[= <0 to disable, 1 to enable>]
  如果启用了uninit_bg功能，则mke2fs不会完全初始化inode表。这显著加快了文件系统初始化的速度，但它需要内核在首次挂载文件系统时在后台完成对文件系统的初始化。如果省略了选项值，则默认为1以启用惰性索引节点表归零。
• lazy_journal_init[= <0 to disable, 1 to enable>] #Journal文件则用于对整个文件系统的操作内容进行记录
  如果启用，则mke2fs不会将日志索引节点完全清零。这显著加快了文件系统初始化的速度，但如果系统在日志被完全覆盖了一次之前崩溃，则会带来一些小风险。如果省略了选项值，则默认为1以启用惰性日志索引节点清零。

这里使用这两个扩展参数创建文件系统，是防止在创建文件系统的时候ext4lazyinit再出现问题，索性在创建文件系统的时候就初始化。但也可能是某个特殊操作导致的ext4lazyinit卡住，不使用扩展参数也可以正确创建文件系统，我这里是直接规避后面的可能了

进行了以上操作之后，磁盘读写恢复了

image.png