我以前从不关注 ext4lazyinit。但是今天，在我格式化了我的 4TB 外置 USB 硬盘和第一次安装后，LED 灯一直闪烁，没有任何写入和读取。我发现这是因为 ext4lazyinit 来初始化 inode 表。还有一个 [ext4lazyinit] 进程。我有一些问题：
1、既然NTFS没有这个“问题”，为什么ext4会这样呢？初始化 inode 表会使 ext4 比 NTFS 更安全、更快吗？我知道 NTFS 没有 inode，它有另一种处理数据的方法。但是 NTFS 可以快速格式化和挂载，无需初始化任何东西。那么为什么 ext4 会有这么大的不同呢？我想它与NTFS相比一定有一些优势，否则，长时间初始化有什么意义？
2, ext4lazyinit 时间长这正常吗？ext4lazyinit 目前仍在运行。已经一个小时了，不知道还要多久。我对这里的时间计算不感兴趣。我只是想知道这是否正常。我做了 google 和其他人遇到了 6+ 小时的 ext4lazyinit 时间。
3，由于驱动器长时间忙碌，是否会在某种程度上损坏硬盘驱动器？我感觉不太好，LED 持续闪烁数小时，驱动器有点热。
4，如果我在格式化期间进行ext4 inode table initilization（运行手动mkfs.ext4命令），是否需要同样长的时间？格式需要6个多小时吗？这对我来说有点荒谬。我读到 ext4lazyinit 是新内核中的一个新特性。没有惰性初始化的过去呢？我不记得格式化驱动器并等待数小时才能完成。
谢谢你。
更新： ext4lazyinit 进程现已完成。这段车程大约需要2个小时。这是一种新的驱动器。
严格来说，只要我们永远不需要尝试进行某些极端的文件系统损坏修复，lazyinit 就不是必需的。问题是如果使用 mke2fs（又名 mkfs.ext4）重新格式化预先存在的文件系统，则 inode 表中可能有旧的 inode 可能被误认为是当前文件系统中的 inode。通常，块组描述符中有一个条目，指示 inode 表的该部分中有效 inode 的范围。但是如果块组描述符已被丢弃，或者不能被信任（因为它们的元数据校验和无效，或者我们正在使用备份块组描述符等），那么 e2fsck（又名 fsck.ext4）搜索所有inode 表中的块，如果我们不偶然发现文件系统以前版本的 inode 并感到困惑，那将是非常可取的。
这就是lazyinit 线程所做的；它正在慢慢将 inode 表中尚未使用的部分清零。以前，inode 表初始化将在 mke2fs 期间完成，但这会使 mkfs 进程对于非常大或非常慢的磁盘非常慢。因此，我们将其推迟到安装文件系统的时间。之所以会花费数小时，是因为我们刻意尝试让它占用大约 10% 的磁盘带宽，以尽量减少对系统性能的影响。这可以通过挂载选项进行调整，或者您可以强制 inode 表初始化在 mke2fs 时间发生（因此您的驱动器可能需要 2 小时才能使 mke2fs 多 12 分钟）。您还可以通过挂载选项临时或永久禁用延迟初始化。
其他文件系统是做什么的？一种方法是在这些极端腐败的情况下举手投足。（毕竟，每个人都在定期做备份，对吧？所以我们不必那么努力。:-) 这种方法在文件系统没有固定 inode 表的情况下更为常见，例如在 ntfs 中。
Reiserfs 没有固定的 inode 表，所以当它找不到它的“跳舞的 inode”时它会做的是对文件系统中的所有块进行暴力搜索，试图找到看起来像 inode 表块的块。这种方法的问题是，如果您尝试将 reiserfs 文件系统的 VM 磁盘映像存储在 reiserfs 文件系统中，并且 fsck.reiserfs 对所有块进行暴力搜索，则生成的 franken-filesystem 可能是....有趣。
至于这是否会损坏您的磁盘驱动器，它不应该。但是，如果磁盘驱动器旋转一个小时左右导致它变得足够热而损坏它，那么它的设计或安装不正确，正常操作很容易造成损坏。但是，您应该向您的硬件供应商/供应商投诉。