了解沒有交換的只讀文件系統上的 buff/cache 和 tmpfs 關係
我們有一個非常奇怪的錯誤，在 Raspberry Pi 上執行的 Yocto 作業系統會因為磁碟 IO 等待而“鎖定”。
設想：
- 作業系統以只讀方式執行，沒有交換
- 有一個 tmpfs 文件系統，用於儲存作業系統需要寫入的內容（/var、/log 等）
- tmpfs 預設為可用 2GB RAM 的一半
- 有一個 USB 硬碟驅動器連接用於儲存大型 MP4 文件
在執行與 Google Coral USB 加速器互動的 Python 程序一段時間後，輸出
top為：
因此 CPU 負載很大，但 CPU 使用率很低。我們認為這是因為它正在等待 IO 到 USB 硬碟。
其他時候我們會看到更高的記憶體使用率：
Mem: 1622744K used, 289184K free, 93712K shrd, 32848K buff, 1158916K cached CPU: 0% usr 0% sys 0% nic 24% idle 74% io 0% irq 0% sirq Load average: 5.00 4.98 4.27 1/251 2645文件系統看起來相當正常：
root@ifu-14:~# df -h Filesystem Size Used Available Use% Mounted on /dev/root 3.1G 528.1M 2.4G 18% / devtmpfs 804.6M 4.0K 804.6M 0% /dev tmpfs 933.6M 80.0K 933.5M 0% /dev/shm tmpfs 933.6M 48.6M 884.9M 5% /run tmpfs 933.6M 0 933.6M 0% /sys/fs/cgroup tmpfs 933.6M 48.6M 884.9M 5% /etc/machine-id tmpfs 933.6M 1.5M 932.0M 0% /tmp tmpfs 933.6M 41.3M 892.3M 4% /var/volatile tmpfs 933.6M 41.3M 892.3M 4% /var/spool tmpfs 933.6M 41.3M 892.3M 4% /var/lib tmpfs 933.6M 41.3M 892.3M 4% /var/cache /dev/mmcblk0p1 39.9M 28.0M 11.9M 70% /uboot /dev/mmcblk0p4 968.3M 3.3M 899.0M 0% /data /dev/mmcblk0p4 968.3M 3.3M 899.0M 0% /etc/hostname /dev/mmcblk0p4 968.3M 3.3M 899.0M 0% /etc/NetworkManager /dev/sda1 915.9G 30.9G 838.4G 4% /mnt/sda1當它全部“鎖定”時，我們注意到 USB 硬碟驅動器因為完全沒有響應（
ls什麼都不做，只是凍結）。在 dmesg 日誌中，我們注意到以下幾行（粘貼為圖像以保留顏色）：
這是我們開始收到這些錯誤後 dmesg 的完整輸出： https ://pastebin.com/W7k4cp35
我們推測，當系統上執行的軟體嘗試對一個大文件 (50MB +) 執行某些操作時（在 USB 硬碟上移動它），不知何故系統記憶體不足。
我們真的不確定我們到底是如何進行的。我們發現了這個部落格：https ://www.blackmoreops.com/2014/09/22/linux-kernel-panic-issue-fix-hung_task_timeout_secs-blocked-120-seconds-problem/這似乎是同樣的問題和建議修改
vm.dirty_ratio和vm.dirty_background_ratio以更頻繁地將記憶體刷新到磁碟。這是正確的方法嗎？
目前設置是
vm.dirty_ratio = 20和vm.dirty_background_ratio = 10相對較慢的 USB 硬碟驅動器是否需要更改？有人可以解釋發生了什麼嗎？
[sda] tag#0 timing out command, waited 180s blkupdate_request: I/O error, dev sda1 INFO: task jbd2/sda1 blocked for more than 122 seconds.塊設備 /dev/sda 失敗。替換它並恢復數據。
Linux 的任務被阻止警告是指任務在幾分鐘內沒有進展。對於電腦，甚至是儲存系統來說，這都是永恆的。觸發不正常的 I/O 問題。要麼儲存出現故障，要麼存在大量的爭用，要麼資源嚴重匱乏。由於其他消息包含 I/O 錯誤的證據，因此前者似乎很可能。
如果儲存已被替換，則該模型可能速度較慢且不適合此應用程序。嘗試使用高性能 SSD，例如 USB 3 適配器中的 NVMe 或類似設備。
還想出一個綜合負載測試來像應用程序一樣執行儲存，並獲得一些性能數據。小的隨機寫入，長的順序寫入，也許是混合的。在 Linux 上，fio是一個非常靈活的 I/O 測試器。
最後，其他硬體組件可能出現故障。作為一個 Raspberry Pi，嘗試更換整個東西。