web-dev-qa-db-ja.com

fstrimは、パーティションがdiscardでマウントされているにもかかわらず、パーティションサイズの半分以上をトリミングします

SSDを取り付けたとき、discardをマウントしただけで問題はありませんでした。しかし今日私は代わりにfstrimを使用することの長所と短所について読んでいて、実際にかかる時間を知るためにプログラムを実行することに決めました(まだdiscardでマウントされたパーティションで) 。このコマンドは、ルートパーティションとホームパーティションの両方で数分かかりました。私のホームパーティションには-vそしてこれを得た:

$ Sudo fstrim -v /home
/home: 137494052864 bytes were trimmed

これは、パーティションの空き容量を超えています!

$ df -h /home
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2       206G   78G  118G  40% /home

後続の実行は1秒未満で終了します。例:

$ Sudo fstrim -v /home
/home: 0 bytes were trimmed

確かに、パーティションを常にdiscardでマウントしていた場合、fstrimはそのような大量のデータをトリムすべきではありませんか? discardオプションは確実に有効になっています。関連するfstab行は次のとおりです。

UUID=xxxxxxxx...    /          ext4   noatime,discard,errors=remount-ro  0      1
UUID=xxxxxxxx...    /home      ext4   noatime,discard,errors=remount-ro  0      2

そしてmount出力行:

/dev/disk/by-uuid/xxxxxxxx... on / type ext4 (rw,noatime,discard,errors=remount-ro,stripe=128,data=ordered)
/dev/sda2 on /home type ext4 (rw,noatime,discard,errors=remount-ro,stripe=128,data=ordered)

SSDは東芝のTHNSNS256GMCPです。なぜこれが起こるのですか?

8
Graeme

ここで2つのこと:

  1. fstrimは、ファイルシステムで割り当てられていないすべてのデータをトリミングします(まあ、実際にはすべてのデータではなく、割り当てられていないデータブロックのみです。iノードテーブルの未使用部分や完全に使用されていないブロックの部分は考えていませんdiscardが使用されているかどうかに関係なく、トリミングされます。 fstrimは、それらの未割り当てのブロックのどれが「トリミング」されたか、または過去にまだ存在していないかを知ることはできませんが、実際にはカーネル、fstrimの作業はすべてFITRIMioctlで行われますが、どのブロックグループを追跡します)はトリムされており、それ以降、そのブロックグループに未割り当てがなければ、再度トリムしません。ただし、エクステント長の最小値が小さいFITRIMをリクエストしない限り(ext4コードのチェックから、他のファイルシステムでは異なります)、次の実行で0になる理由を説明します。

    trimは既にトリミングされているブロックには害を与えないことに注意してください。それは、SSD againに必要なすべてのことを実行できることを伝えているだけです(消去して他の何かに再び使用できるようにするなど)。

  2. dfの出力では、「available」の値はroot用に「予約」されているスペースを考慮に入れていません。206-76は118Gではなく130Gであることがわかります。 12G(約5%)は予約されています。見る tunefs -m予約済みの量を変更します。
12