在超过十亿个文件的目录上执行“tar”时，进程停留在D状态

Question

我在做一些实验以了解有关Linux进程状态的更多信息。

所以，有一个目录（命名big_dir），在它超过十亿的文件（目录中有很多子目录递归），然后我跑tar -cv big_dir | ssh anotherServer "tar -xv -C big_dir"，并通过执行top的是，tar过程停留在d发现状态。同时，tar命令不断输出文件的路径。

我知道该进程处于D状态，因为它正在执行磁盘I/O，但为什么它的状态不在D和R之间切换？打印目录下的文件名必须使用一些CPU计算，不是吗？否则find命令怎么知道它应该打印什么？

如果我运行dd if=/dev/zero of=/dev/null，则dd过程状态保持在R状态从top输出。但为什么它不是D状态？难道它一直在做I/O吗？

Answer 1

/dev/zero和/dev/null是伪设备。所以他们身后没有物理设备。

如果我做

dd if=/dev/zero of=/tmp/zeroes 

然后top确实显示我dd在d状态。然而，它确实花了很多时间在R（CPU时间）。 top将简单地对进程表进行采样，因此您可能需要观察一段时间才能看到瞬态状态。

我怀疑上面的tar例子，输出到stdout的时间与磁盘时间相比可以忽略不计。还要注意，输出到标准输出还将涉及窗口系统的写入，同时它正在执行该过程将进入休眠状态。例如我现在正在运行yes，并且大部分工作都由我的X服务器执行。 yes进程在大部分时间里都在睡觉，我正在看它（通过top）

Answer 2

我确定你的tar进程有时候会去R，但它可能是很短的时间，因为它没有'这么做 - 特别是因为你通过网络发送数据。除非这是一张10Gb/s的网卡（其他“另一个服务器”实际上是以1GB/s的速度运行），否则这将是链中速度最慢的部分。 ssh本身在加密数据时会花费一点开销。

它可能需要几微秒的时间才能从磁盘请求一些数据，并且需要几毫秒的时间让磁盘移动它的头部并读取实际数据。所以你在“R”中有大约0.1％的时间，其余的在“D”中。