在超過十億個文件的目錄上執行「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」中。