我以前从来没有关注过 ext4lazyinit。但是今天，在我格式化我的 4TB 外置 USB 硬盘并首次挂载后，LED 灯一直闪烁，没有任何写入和读取。我发现这是因为 ext4lazyinit 初始化了 inode 表。还有一个 [ext4lazyinit] 过程。我有一些问题：
1、既然 NTFS 没有这个“问题”，ext4 为什么要这样做？初始化 inode 表会让 ext4 比 NTFS 更安全、更快吗？我知道 NTFS 没有 inode，它有其他处理数据的方式。但 NTFS 可以快速格式化和挂载，而不需要初始化任何东西。那么 ext4 为什么要有这么大的不同呢？我想它与 NTFS 相比一定有一些优势，否则，长时间初始化有什么意义呢？
2、ext4lazyinit 耗时很长是正常的吗？ext4lazyinit 目前仍在运行。已经一个小时了，不知道还要花多长时间。我对这里的时间计算不感兴趣。我只是想知道这是否正常。我确实谷歌了一下，其他人也遇到过 6+ 小时的 ext4lazyinit 时间。
3，由于驱动器长时间处于繁忙状态，这会在某种程度上损坏硬盘吗？我感觉不太好，LED 灯连续闪烁数小时，驱动器有点热。
4，如果我在格式化期间执行 ext4 inode 表初始化（运行手动 mkfs.ext4 命令），是否需要同样长的时间？格式化会花费 6 个多小时吗？这对我来说有点荒谬。我读到 ext4lazyinit 是新内核中的一项新功能。没有 lazy init 的旧时代怎么办？我不记得格式化驱动器并等待数小时才能完成。
谢谢。
更新：ext4lazyinit 进程现已完成。此驱动器大约需要 2 小时。这是一个比较新的驱动器。
答案1
严格来说，只要我们不需要尝试执行某些极端的文件系统损坏修复，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 可能会....有趣。
至于这是否会损坏您的磁盘驱动器，答案是不会。但如果磁盘驱动器旋转一小时左右导致其变得足够热以致损坏，则说明其设计或安装不正确，正常操作很容易造成损坏。但那时您应该向硬件供应商/提供商投诉。