我正在使用我的腳本建立 dm-cache 設備： http://pastebin.com/KTSzL6EA
實際上它正在運行這些命令：
dmsetup create suse-cache-metadata --table 0 15872 linear /dev/mapper/suse-cache 0
dmsetup create suse-cache-blocks --table 0 125813248 linear /dev/mapper/suse-cache 15872
dmsetup create storagecached --table 0 2930266112 cache /dev/mapper/suse-cache-metadata /dev/mapper/suse-cache-blocks /dev/mapper/storage 512 1 writethrough default 0
dmsetup resume storagecached
在 60GB SSD LVM 磁碟區上用於快取 1.5TB USB 2.0 HDD。我正在使用以下命令安裝快取的 dm 裝置：
mount -t btrfs -o noatime,autodefrag,compress=lzo,space_cache /dev/mapper/storagecached /mnt/storage
然而它似乎根本不起作用。我注意到，每次我訪問快取設備上的任何內容以及每次某個機器人訪問我的網站時，外部HDD 都會旋轉，即使我猜它應該被緩存，這也很煩人，最終會導致I/O錯誤大約一周，因為外部硬碟無法處理連續的加速和減速。
我決定實際執行一些基準測試，並使用dd命令將 8GB 檔案複製到 /dev/null 只達到 40MB/s。它的速度與非快取 HDD 相同。總是。兩者都在擦除快取的情況下進行空運行，以及我認為應該緩存的第三次或第四次讀取。用於快取的 SSD 在根分區上達到 92MB/s。當然，每次工作後我都會擦除 Linux RAM 緩存，以消除 RAM 快取效能影響。
我實際上在兩台電腦上使用這個腳本，但它們似乎都不起作用。我知道 writethrough 不會加快寫入速度，但無論如何我更在乎讀取。
編輯：
檢查dmsetup status日誌後，我發現快取命中率非常低。會不會是 btrfs 的錯？
答案1
dm 快取需要一些時間才能將區塊提升到快取設備。與linux RAM快取不同，預設的dmcache策略需要至少對某些資料進行幾次讀取才能將其升級為SSD，通常需要大量讀取，超過10次。需要大量讀取“訓練”dmcache 的時間。如果快取大小與備用記憶體的數量相似，並且經常使用的資料佔用大量空間，則它可能根本無法正常運作。
答案2
使用lvmcache(7)進行設置，你會更高興。此外，線上說明頁面對於啟動和運行也非常有幫助。請注意回寫/直寫策略和 smq 快取策略，該策略僅在較新的（核心 4.2 之後）版本上預設為啟用。這也是 RHEL 7.2+ 左右的預設設定。
你可以看我的演講：https://www.youtube.com/watch?v=6W_xK5Ks-Lw 或閱讀幻燈片：https://www.linuxdays.cz/2017/video/Adam_Kalisz-SSD_cache_testing.pdf