1.詳細描述
在4.19.90 - 17內核的機器上偶現(部分機器大概2周一次)IO夯死的現象(dmesg 中顯示某進程 blocked for more than 120 seconds, 后面接著Call trace),并伴隨有ssh登錄不上的問題出現.
復現步驟:
很難復現,我們在研發(fā)過程中通過修改過內核代碼(加劇問題暴露)的內核才能復現。
1. 大部分測試機用上我們 添加代碼加劇現象的的內核 從外部scp一個4G左右的 iso 文件到虛擬機內部就在拷貝過程就會慢慢發(fā)現拷貝速度降到 幾百K,這時候肯定是IO被阻塞了, 大概120秒后就可以在dmesg中看到 (blocked for more than 120 seconds )報錯信息.
2. 我們也遇到過這樣沒有出現阻塞的機器,這時候我們繼續(xù)加大IO,在scp的過程中,也給相同塊設備的掛載點dd if=/dev/urandom of=/xxx/dest/path/xxxfile bs=1M count=4000, 這樣我們基本都能看到以上問題的現象。
3. 這些的前提是得換上我們加劇現象的調試內核才能復現。
原因:內核的WBT模塊, 有個判斷自己是不是第一個IO waiter的地方在多線程情況下會有判斷非原子性的邏輯問題。會導致某些被阻塞的IO一直無法被喚醒,導致塊設備無法寫入。
影響:會影響之前發(fā)布的4.19內核的版本
規(guī)避方案:通過 echo 0 > /sys/block/設備/queue/wbt_lat_usec 關閉這個模塊,就不會有卡在wbt的D狀態(tài)進程了。
修復方案:升級內核(Version 4.19.90-23.18.v2101)
【注意事項】
需要重啟生效;