web-dev-qa-db-ja.com

ファイルシステム（ext4）はどのようにTRIM情報を「保存」しますか？

毎週1回実行されるTRIMcronジョブを有効にすることをお勧めします。 fstrimコマンドが呼び出されると、ファイルシステムは削除されたデータを破棄するためにTRIM情報をドライブに送信します（正しく取得できれば幸いです）

これまでのところ、これは多くの場所で説明されています。

しかし、これらのTRIM情報がfstrimコマンド間でファイルシステムに「保存」される方法/場所に関する情報が見つかりませんか？

そして、これらのTRIM情報を何らかの方法で「クリア」して、SSDが破棄する必要のあるすべてのページ/ブロックの情報を取得しないようにすることはできますか？

または、fstrimコマンドは、実際に削除されるデータに関してファイルシステムとSSDを比較しますか？

ssdtrim
1
MrCalvin

Ext4が実際にどこかにそれを保存するかどうかはわかりません。他のファイルシステムは確かにそうではありません。

ext4は、まだマウントされている間だけ、現在のセッションですでにトリミングされているものを回避します。ファイルシステムを再起動または再マウントすると、空のスペースが再びTRIMされます。

したがって、これはまったく保存されていないメモリ内構造である可能性があります。私は見つけるために非常に細かいソースコードに飛び込んでいませんでした。

ちょっとしたテスト：

# truncate -s 1G /dev/shm/foobar.img
# losetup --find --show /dev/shm/foobar.img
/dev/loop9
# mkfs.ext4 /dev/loop9
# mkdir /mnt/loop

1Gファイルシステムが与えられたら、それをマウントしてトリミングしましょう。

# mount /dev/loop9 /mnt/loop/
# fstrim -v /mnt/loop
/mnt/loop: 973.4 MiB (1020678144 bytes) trimmed
# fstrim -v /mnt/loop
/mnt/loop: 0 B (0 bytes) trimmed

つまり、最初にすべてをトリミングします...結局のところ、それだけですでに疑わしいのです。mkfsもすでにトリミングされているので（痛い）、まだ空でトリミングされていることを知っているはずですよね？まあ、それが知っているなら、それは気にしません：

# umount /mnt/loop
# mount /dev/loop9 /mnt/loop
# fstrim -v /mnt/loop
/mnt/loop: 973.4 MiB (1020678144 bytes) trimmed

したがって、再マウント後、すべての空き領域が再びトリミングされます。

ファイルを作成および削除する場合、精度も正確ではありません。

# dd bs=1M count=10 if=/dev/zero of=/mnt/loop/zerofile
10+0 records in
10+0 records out
10485760 bytes (10 MB, 10 MiB) copied, 0.0124641 s, 841 MB/s
# sync
# rm /mnt/loop/zerofile
# fstrim -v /mnt/loop
/mnt/loop: 117.5 MiB (123203584 bytes) trimmed

したがって、10Mを書き込むと、117Mの再トリムが発生します。それは何の意味もありません。

SSD自体だけが、現在トリミングされているものとされていないものを実際に認識しており、すでにトリミングされた領域をトリミングするように求められた場合、SSDは単に何もしないはずです。したがって、害はなく、この情報をファイルシステムに実際に保存する必要もありません。

4
frostschutz