web-dev-qa-db-ja.com

自動TRIMと手動TRIM

私は現在、新しいTPでトリミングする方法を見つけようとしていますが、手動/オンライントリミングの違いについて疑問に思っていました。

私のセットアップは次のとおりです。

SSD Samsung 830、128GB、およびXubuntu 12.10を搭載したThinkPad T430sは、システムでトリムが機能するかどうかを確認するための出力です（ここからこれらを入手してください： http://wiki.ubuntuusers.de/SSD/TRIM =）

root@eike-tp:~# Sudo hdparm -I /dev/sda | grep -i TRIM
   *    Data Set Management TRIM supported (limit 8 blocks)

まず、オンライントリミングを試しました： TRIMを有効にする方法

破棄が挿入された私のfstab：

UUID=d6c49c17-a4f1-466c-9f7e-896c20db3bba /  ext4  discard,noatime,errors=remount-ro  0  1
# swap was on /dev/sda5 during installation
UUID=a0322f5f-c6c1-4896-863f-668f0638d8cf none  swap  sw  0   0
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0

私はそれが動作するかどうかをテストしようとしました（ただし、/ dev/sdaで試してもゼロは得られません）が、この方法はSSDタイプ2でのみ可能であり、タイプ3のようです。それが機能するかどうかわからない。

Ubuntuwiki（最初のリンク）は手動トリミングを推奨しているため、破棄する代わりに毎日cronjobを設定します。

#!/bin/sh
LOG=/var/log/batched_discard.log
echo "*** $(date -R) ***" >> $LOG
fstrim -v / >> $LOG

ウィキの記事では、毎週または毎日を提案しています。今私の質問に：

自動トリムはどのくらいの頻度で実行されますか？推奨される頻度は？オンライントリミングと手動トリミングのどちらですか？

ご協力ありがとうございました

ssdtrim
12
Eike Cochu

自動トリムと手動トリムの違いは、自動トリム（discardマウントオプションを使用）は、ファイルの削除後に同期時に解放されたブロックをトリムしますが、手動トリム（fstrimを使用）は、一度。

テスト中

自動トリムが機能しているかどうかをテストする1つの方法は、大きなファイルを作成および削除することです。

user@Host:/somewhere$ dd if=/dev/urandom bs=1M count=100 of=bigfile
user@Host:/somewhere$ sync
user@Host:/somewhere$ rm bigfile
user@Host:/somewhere$ sync

自動破棄が機能している場合、手動で再度トリミングしても多くのブロックはトリミングされません。すでにトリミングされているはずです。ファイルシステムでSudo discard -vを実行し、トリミングされたブロックの数を確認します。

勧告

私の経験では、自動トリムはパフォーマンスを低下させます。 ただし、これはおそらくハードウェアに依存します。ドライブで問題ない場合があります。

手動トリムを使用している場合、頻度については、SSDの空き領域の量と比較して、一般的なワークロードでデータを書き込む速度を考慮してください。削除されたデータでディスクがいっぱいになる前に、十分に頻繁にトリムしたい場合。 SSDの大部分が空き領域であるか、ディスクのワークロードが軽い場合は、時折（毎週またはそれ以上）トリミングするだけで十分です。 SSDのほとんどがいっぱいの場合、またはビデオファイルを頻繁に編集する場合は、より頻繁にトリミングする必要があります。

4
Mechanical snail

私はストレージエンジニアではなく、 自分自身の関連する心配 を持っていますが、スケジューリングに関しておそらく役に立つ提案をすることができます。 TRIMがSSDの面倒な摩耗を引き起こさないと確信しています。ディスクがブロックのリサイクルを開始する前に、最終的に受けなければならないのは単なるハウスキーピングです。バッチTRIMmingの最適なスケジュールは、使用方法によって異なります。書き込み頻度と空き容量の関数、と思うべきです。それを念頭に置いて、私はcronジョブとfstrim -vを数日間手動で取り外します。

私が思うトリックは、通常の書き込み操作を実行するために使用済みブロックをリサイクルする前にバッチTRIMが書き込み用にSSDを準備するスケジュールを作成し、パフォーマンスを低下させることです。 24時間待ってからfstrim。空き領域よりもはるかに少ないブロックをトリムしたと主張する場合、おそらくそれよりも少ない頻度でバッチTRIMmingが提供されます。

2
dam

Fstrimデーモンを準備しました https://github.com/dobek/fstrimDemon

Cronテーブルよりも稼働時間に基づいてfstrimを実行する方が信頼性が高いようです。楽しんで。

2
Dobek

起動するたびにSSDをトリミングします。起動から20秒後に呼び出されるshファイルを作成しました。ログファイルではなくシステム通知でfstrimからの出力を表示することを選択しました。

最初にtrim.shディレクトリに~/binファイルを作成します

#! /bin/sh
notify-send "TRIM" "$(Sudo fstrim -v /)"

次に、パスワードを入力する必要がないように、fstrimを実行するためのユーザー特権を与える必要があります。 visudoでsudoersファイルを開き、次の行を追加します。

yourusername  ALL=(ALL) NOPASSWD: /sbin/fstrim

home/yourusername/binフォルダーを$PATHに含める場合は、パスワードを必要とせずにコマンド 'trim'を使用してターミナルで手動でトリミングすることもできます。

これで、スクリプトを起動アプリケーションに追加し、遅延を指定できます。新しいsudoersエントリがロードされるように、再度ログアウト/ログインする必要があります。

1
kasper Taeymans