我最近为我的 Debian 服务器购买了一块新的 16TB 硬盘。我首先通过类似 Ubuntu 的桌面在其上创建了一个分区 (gpt)，对其进行了格式化 (ext4)，并在其上 rsync 了旧数据。现在磁盘可以使用了，因此我将其插入我的服务器。现在出现了一个我无法识别的奇怪 I/O。
iotop -ao报告 3MB/sCurrent DISK WRITE毫无迹象谁在做这件事fatrace -c -ttouch报告没有写入或读取，但如果我自己有一个文件，则确实报告它。dstat -tdD /dev/sdx --top-io报告每秒稳定地写入 3072k，与一致iotop，但也没有罪魁祸首，只有在应该有名字的地方才有空白i/o process，但它确实确认了 I/O 操作是在所述磁盘上，这是我最初从它发出的噪音中推断出来的……
现在我知道 iotop 标头显示的内容与进程的 I/O 写入和/或读取总数之间可能存在不一致，如前所述这里。但与之前的帖子相反，当时：
- 服务器与互联网断网
- 本地网络只是服务器
- 我没有表演任何磁盘上的操作
- 我手动退出了所有可以使用该磁盘的程序
几个小时后（至少 10 个小时，不超过 20 个小时），噪音消失了，磁盘上不再有 3MB/s 的输入。
我的问题是：编写一些缓存系统、初始化表或类似的东西是否是正常行为（尽管我之前从未观察到）（可能是来自内核？）可以解释这种持续 10-20 小时的 3MB/s 写入？
我最初想到的是加密/随机病毒，但即使以 3MB/s 的速度运行 20 个小时也不可能覆盖 16 个可用磁盘上写入的 12TB 数据。
对此有任何合理的解释吗？
答案1
您注意到的后台 IO 负载是由于 ext4 延迟 inode 表分配造成的。来自mke2fs手册页：
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 file
system initialization noticeably, but it
requires the kernel to finish initializing the
file system in the background when the file
system is first mounted. If the option value
is omitted, it defaults to 1 to enable lazy
inode table zeroing.
答案2
内核或文件系统可能正在执行维护任务，例如更新元数据或日志记录，这可能会导致持续的磁盘写入。这些任务通常在后台执行，以优化磁盘性能。