LUKS 上 LVM 上的 btrfs - 一個 LUKS 容器的性能比另一個好
我有 2 個 LUKS 容器，一個帶有預設 OpenSUSE 安裝程序設置，另一個帶有
-h sha512 -s 512 -i 5000分離的標頭。在它們每個之上都有 LVM - 一個只有 1 個作業系統卷，即 btrfs，另一個（分離）有 3 個卷 - 交換、ssd 記憶體和 btrfs 數據。問題是作業系統卷上的 btrfs 比數據卷執行得好很多。有作業系統的那個在沒有LVM的LUKS上執行或多或少像原始btrfs，有數據的那個在三星SSD PRO上達到… 50MB / s順序…（它比WD Green HDD慢）我計劃使用這個卷適用於虛擬機，但它的速度非常慢，Win10 的啟動時間大約是一分鐘左右，而在 OS 分區上則只有幾秒鐘。作業系統卷是由 OpenSUSE 安裝程序使用預設設置創建的。帶有數據的那個是手動創建的，
mkfs.btrfs除了label. 以下是掛載參數：
/dev/mapper/linux-suse on / type btrfs (rw,relatime,ssd,discard,space_cache)/dev/mapper/data-data on /home/lapsio/VMs type btrfs (rw,noatime,compress=lzo,ssd,space_cache)首先要歸咎於ofc壓縮，但實際上VMs dir已經
chattr -R +C VMs/在它以及里面的所有文件上設置了標誌。我也嘗試對這個目錄進行碎片整理，但它似乎不起作用。
哦，我的……我沒有提到這個驅動器是從筆記型電腦上移來的，作為唯一的驅動器，它 99% 都充滿了數據。第一個 LVM 在作業系統啟動時自動掛載並啟用了 TRIM（我知道不建議在加密設備上使用它，因為它會顯示磁碟上的數據組織，但作業系統分區只包含作業系統，而不包含實際的重要數據），第二個 LVM 是從命令行手動掛載的，並且沒有啟用TRIM（因為我不打算在那裡使用TRIM）。但事實上，這個 180gb 分區（在 256gb 驅動器上）或更確切地說是覆蓋驅動器這一部分的數據單元，因為它是安裝在 PC 中的，所以根本沒有修剪。
在我手動修剪此 LUKS 分區後，它工作正常