长时间ext4lazyinit会损坏硬盘吗？为什么要在 ext4 中初始化 inode 表（在 NTFS 中不需要任何初始化）？ETC

Question

我以前从来没有关注过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表初始化（运行手动mkfs.ext4命令），是否会花费同样长的时间？格式化需要 6 个小时以上吗？这对我来说有点可笑。我读到 ext4lazyinit 是新内核中的一个新功能。没有惰性初始化的过去怎么样？我不记得格式化驱动器并等待数小时才能完成。

谢谢。

更新： ext4lazyinit 过程现已完成。这段车程大约需要2个小时。这是一种新的驱动器。

Answer 1

严格来说，只要我们不需要尝试进行某些极端的文件系统损坏修复，lazyinit 就不是必需的。问题是，如果使用 mke2fs（又名 mkfs.ext4）重新格式化预先存在的文件系统，则 inode 表中可能存在旧 inode，这些旧 inode 可能会被误认为是当前文件系统中的 inode。通常，块组描述符中有一个条目指示 inode 表的该部分中有效 inode 的范围。但是，如果块组描述符已被丢弃，或者无法信任（因为它们的元数据校验和无效，或者我们正在使用备份块组描述符等），则 e2fsck（又名 fsck.ext4）会搜索所有块组描述符。 inode 表中的块，如果我们不会偶然发现文件系统以前版本的 inode 并感到困惑，那将是非常可取的。

这就是lazyinit 线程所做的事情；它正在慢慢地将索引节点表中尚未使用的部分清零。以前，inode 表初始化会在 mke2fs 期间完成，但这会使 mkfs 进程对于非常大或非常慢的磁盘非常慢。因此，我们将其推迟到安装文件系统时。之所以需要几个小时，是因为我们刻意让它占用大约 10% 的磁盘带宽，以尽量减少对系统性能的影响。这可以通过挂载选项进行调整，或者您可以强制 inode 表初始化在 mke2fs 时间发生（因此您的驱动器可能需要 2 小时，这将使 mke2fs 多出大约 12 分钟）。您还可以通过挂载选项暂时或永久禁用延迟初始化。

其他文件系统有什么作用？一种方法是在这些极端腐败的情况下举手投降。（毕竟，每个人都会定期进行备份，对吗？所以我们不必那么努力。:-）当文件系统没有固定的 inode 表（如 ntfs）时，这种方法更为常见。

Reiserfs 没有固定的 inode 表，因此当它找不到“跳舞 inode”时，它会做的就是对文件系统中的所有块进行强力搜索，试图找到看起来像 inode 表块的块。但这种方法的问题是，如果您尝试将 reiserfs 文件系统的 VM 磁盘映像存储在 reiserfs 文件系统中，并且 fsck.reiserfs 对所有块进行强力搜索，则生成的 Franken 文件系统可能是......有趣的。

至于这是否会损坏您的磁盘驱动器，应该不会。但是，如果磁盘驱动器旋转一个小时左右，导致其变得足够热而损坏它，那么它的设计或安装不正确，正常操作很容易造成损坏。但随后您应该向您的硬件供应商/提供商投诉。