為什麼 fstrim 似乎不會修剪 btrfs (+ecrypts) 上的數據塊？
我有一個帶有多個分區的 SSD 磁碟。其中之一是有一個 btrfs 卷，掛載為
/home，它包含一個 ecryptfs 主目錄。當我修剪卷時，似乎 fstrim 不會修剪此類卷上的數據塊 - 為什麼？您可以在下面看到有關設置的所有資訊，以及我遵循的程序，並附有評論。
$ cat /etc/fstab:UUID=xxx / ext4 errors=remount-ro 0 1 UUID=yyy /media/vfio ext4 defaults 0 2 UUID=zzz /home btrfs defaults 0 2
$ mount | grep sda:/dev/sda5 on / type ext4 (rw,relatime,errors=remount-ro,data=ordered) /dev/sda1 on /media/vfio type ext4 (rw,relatime,stripe=32721,data=ordered) /dev/sda2 on /home type btrfs (rw,relatime,ssd,space_cache,subvolid=5,subvol=/)
$ ls -la /home /home/myuser/.Private # summary:/home: .ecryptfs myuser /home/myuser/.Private -> /home/.ecryptfs/myuser/.Private
$ df -h:Filesystem Size Used Avail Use% Mounted on /dev/sda5 16G 11G 4,7G 69% / /dev/sda1 93G 52G 36G 60% /media/vfio /dev/sda2 828G 542G 286G 66% /home /home/myuser/.Private 828G 542G 286G 66% /home/myuser我第一次在所有捲上執行 fstrim。
$ fstrim -va:/home/myuser: 286,4 GiB (307518836736 bytes) trimmed /home: 286,4 GiB (307485450240 bytes) trimmed /media/vfio: 40,4 GiB (43318886400 bytes) trimmed /: 5,4 GiB (5822803968 bytes) trimmed
/home由於額外的 ecryptfs 掛載，fstrim 似乎在樹上執行了兩次。這沒關係（我可以通過執行具有特定掛載點的 fstrim 來避免它）。問題是修剪/home沒有按預期工作，因為每次執行都會找到並修剪相同數量的數據。進一步的執行表明了這一點。
$ fstrim -v /（還行吧）：/: 0 B (0 bytes) trimmed
$ fstrim -v /home（這不行）：/home: 286,4 GiB (307478061056 bytes) trimmed注意 sda2 (
/home) 修整需要一些時間來執行，所以它實際上是在做一些事情。
擔心 fstrim 報告的大小是一個常見的誤解。
這真的沒有任何意義。 忽略它。
fstrim只需發出適當的ioctl，其他一切都是文件系統的決定，並且文件系統的行為非常不同。例如，ext4盡量避免一遍又一遍地修剪相同的東西，所以你會看到0 bytes trimmed.xfs不在乎並修剪所有免費的東西，所以你總是會看到<roughly free space> bytes trimmed. 其他文件系統可能會做其他事情，這完全取決於文件系統如何選擇實現FITRIM系統呼叫邏輯，如果它完全實現的話。只要修剪的數據量不大於可用空間，無論
fstrim（文件系統，實際上）報告什麼，您都應該沒問題。最後，只有 SSD 本身真正知道目前修剪了什麼，沒有修剪什麼。修剪已經修剪過的塊不會造成任何傷害。
不要根據
x bytes trimmed報告的內容做出結論fstrim。如果要驗證數據是否被修剪，則必須檢查磁碟上的原始數據。（https://unix.stackexchange.com/a/85880/30851）但該方法可能不適用於 btrfs，我從未嘗試過。