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です。なぜこれが起こるのですか?
ここで2つのこと:
fstrim
は、ファイルシステムで割り当てられていないすべてのデータをトリミングします(まあ、実際にはすべてのデータではなく、割り当てられていないデータブロックのみです。iノードテーブルの未使用部分や完全に使用されていないブロックの部分は考えていませんdiscard
が使用されているかどうかに関係なく、トリミングされます。 fstrim
は、それらの未割り当てのブロックのどれが「トリミング」されたか、または過去にまだ存在していないかを知ることはできませんが、実際にはカーネル、fstrim
の作業はすべてFITRIM
ioctl
で行われますが、どのブロックグループを追跡します)はトリムされており、それ以降、そのブロックグループに未割り当てがなければ、再度トリムしません。ただし、エクステント長の最小値が小さいFITRIMをリクエストしない限り(ext4コードのチェックから、他のファイルシステムでは異なります)、次の実行で0になる理由を説明します。
trimは既にトリミングされているブロックには害を与えないことに注意してください。それは、SSD againに必要なすべてのことを実行できることを伝えているだけです(消去して他の何かに再び使用できるようにするなど)。
df
の出力では、「available」の値はroot
用に「予約」されているスペースを考慮に入れていません。206-76は118Gではなく130Gであることがわかります。 12G(約5%)は予約されています。見る tunefs -m
予約済みの量を変更します。