影響整個桌面的奇怪 I/O 停頓
在最近一次硬體遷移之後，我開始遇到奇怪的 I/O 停頓，影響我的桌面 Debian Stretch 系統。典型症狀，都發生在每個攤位期間：
- 我無法與我的網路瀏覽器 Chromium 互動。沒有任何效果：網頁滾動（通常這是我注意到停頓的方式）、切換選項卡等。無論是在網頁上還是在 Chromium UI 上，都沒有滑鼠懸停動作。
- 在虛擬終端中，我無法再執行新程序。例如，我在其中打開一個新選項卡，
mate-terminal但我的 shell 沒有出現，只是游標在閃爍。在停止前打開 shell 的終端中，我可以輸入命令，但通常它不會啟動；sudo something甚至不要求輸入密碼。- 其他程序，如 RStudio，無法將任何內容保存到磁碟，並且在嘗試保存時經常掛起。
- 我在日誌中看到
journald -f，如果停頓時間足夠長，journald它本身會重新啟動，例如：sty 30 14:03:54 liori-pc systemd[1]: systemd-journald.service: Main process exited, code=killed, status=6/ABRT sty 30 14:03:54 liori-pc systemd[1]: systemd-journald.service: Unit entered failed state. sty 30 14:03:54 liori-pc systemd[1]: systemd-journald.service: Failed with result 'watchdog'. sty 30 14:03:54 liori-pc systemd[1]: systemd-journald.service: Service has no hold-off time, scheduling restart. sty 30 14:03:54 liori-pc systemd[1]: Stopped Flush Journal to Persistent Storage. sty 30 14:03:54 liori-pc systemd[1]: Stopping Flush Journal to Persistent Storage... sty 30 14:03:54 liori-pc systemd[1]: Stopped Journal Service. sty 30 14:03:54 liori-pc systemd[1]: Starting Journal Service... sty 30 14:03:54 liori-pc systemd-journald[23935]: Journal started sty 30 14:03:54 liori-pc systemd-journald[23935]: System journal (/var/log/journal/2318080f60e357aaf765e98d0000035c) is 2.1G, max 4.0G, 1.8G free.
- 使用 dm_crypt 時，一個
dmcrypt_write程序開始佔用單個 CPU 核心的 100%（我後來從這個系統中刪除了 dm_crypt，但仍然會發生停頓）。- 我觀察
/proc/meminfo並看到這個Dirty數字永遠不會超過幾兆字節。值得注意的是，在停頓期間，這個數字不會改變。- 在極少數情況下，我什至會收到一條核心消息，格式為“INFO：task «some process»blocked for more than 120 seconds.”，«some_process»通常是 mdX_raid5、chromium 或其執行緒之一等。範例日誌.
/dev/sdd最初，我的設置只是單個 1TB 驅動器（目前）分區上的單個 600GB ext4 文件系統。然後我遷移到 3×6TB 驅動器 (/dev/sd{b,c,e})，使用基於 LVM 的 raid5、bcache 及其在 SSD 驅動器上的記憶體，然後是 dm_crypt — 這就是停頓開始的時候。在調試的過程中，我將其簡化為 LVM-raid5，沒有 bcache 或 dm_crypt；攤位仍然會發生，儘管我覺得現在已經不那麼頻繁了。這種失速一天會發生數次，通常持續幾分鐘。我注意到我可以通過明確請求一些磁碟操作來破壞它：我有時可以通過從遠端機器上通過 ssh 登錄到這個系統來破壞它，或者（幾乎總是）通過
cat /dev/sdb >/dev/null或者cat /dev/sdc >/dev/null（有時一個，有時另一個工作; 特別是cat /dev/sde >/dev/null從來沒有幫助過）。然後，一切停滯不前的東西突然又開始工作了。所以我懷疑問題是由以下之一或相互作用引起的：
- 驅動器：三個都是希捷 Skyhawk ST6000VX0023。其中兩個在此設置之前未使用，第三個使用了半年（
/dev/sdc）。- 磁碟控制器：主機板：
Gigabyte Z68X-UD3H-B3有兩個控制器：Marvell 88SE9172其中一個驅動器連接到其中，晶片組內置控制器（Intel® Z68）與另外兩個（我可以檢查哪一個在軟體中的位置嗎？）。- 控制器核心驅動程序中的一些錯誤。
- LVM 或 raid5 中的一些錯誤。
這是一個 Debian Stretch 系統，安裝了一些向後移植的軟體包，最顯著的是 kernel
4.19.0-0.bpo.1-amd64。英特爾酷睿 i7-2600k，16GB 記憶體。在這一點上，我沒有想法了。如何進一步調試此問題？
編輯：我開始了一個腳本，它每 4 秒從其中一個驅動器中讀取一個隨機扇區，並且現在 2 天沒有停頓。因此，確實看起來某些系統組件（LVM？raid？）在必要時無法正確地將設備從某種低功耗模式中喚醒。
編輯：我不再可以訪問這個系統，所以我不能再測試任何假設。我只能說，在執行該腳本後，我不再獲得攤位。不過，我希望我知道如何調試它。
希捷 Skyhawk 型號在 6TB 型號上的“待機就緒”時間為 23-30 秒。1TB 型號的這個數字是 6 毫秒；在過渡到 2TB 的過程中，這個檔位大大增加了。我懷疑您的驅動器正在切換到僅緩衝 I/O 的空閒狀態，然後在您嘗試寫入它時停止，因為它正在旋轉。
該驅動器支持 4 種電源管理模式：活動、空閒、待機和睡眠。手冊中的相關部分說：
“每次驅動器執行活動功能（讀、寫或尋軌）時，待機計時器都會重新初始化，並開始從其指定的延遲時間倒計時到零。如果在需要任何驅動器活動之前待機計時器達到零，則驅動器使轉換到待機模式。在空閒和待機模式下，驅動器接受所有命令並在需要訪問磁碟時返回活動模式。
從 Linux 中更改電源管理模式以消除待機模式是一件痛苦的事情。驅動器供應商為這類事情提供實用程序，但通常他們需要啟動他們的 ISO 或使用僅限 Windows 的實用程序。我在使用 hdparm 調整待機超時方面取得了一些成功；這是一個入門教程。