なうびるどいんぐ

脳みそ常時-3dB

【Linux】USB接続の外付けSSDでtrimできるかもしれない方法

      HimaJyun

「USB接続の外付けSSDってtrimできないよね～」みたいな問題ですが、強制的にtrimの命令を送ってやればtrimできる事があるらしい。

Linuxの場合での、強引にtrimを試してみる設定方法とか。

スポンサーリンク

外付けSSDがtrimできない

Raspberry PiにSSD繋ごうとすると割と問題になりがち。

OS種別問わず、USB接続のSSDではtrimが出来ない事が少なくない。

具体的に言えば、fstrimコマンドがこんな感じになる。

$ sudo fstrim -v /mnt
fstrim: /mnt: the discard operation is not supported

ただ、OSがtrimをサポートしていないと判断したからといって、trimが使えないとは限らない。実際にtrim命令を送り付けると出来てしまう可能性もある。

LinuxであればOSの判断を無視して強引にtrimを使えるようにする設定が可能なので、試してみる価値はある。

設定

udevルールを追加してtrim(unmap)が使える事をカーネルに通知してやるとtrimができるようになる可能性がある。

なお、この方法はUASP(NVMe)なSSDで確認した、UASP(SATA)のSSDだと結果が変わる可能性がある。(trimには大前提としてUASPが必要なので、そもそもUASPじゃない変換アダプタでは絶対に不可能です)

また、この方法で必ずtrimが可能になるとも限らない。データを全損させる可能性も否定できないのでバックアップなどを取ったうえで慎重に確認してから設定することを強く推奨。

真似して彼女の写真が消えてなくなっても俺は責任取れません。

IDの確認

まず最初に、接続している機器の「ベンダーID」と「プロダクトID」を確認する必要がある。

これはudevadmコマンドで確認できる。(lsusbでも確認できるが、udevadmの方がデバイスを直接指定できて簡単)

sudo udevadm info -q property -n [デバイス]
# デバイスの部分は接続している外付けSSDを指定

出力はこんな感じ。(長いので必要な部分以外省略)

$ sudo udevadm info -q property -n /dev/sda
ID_VENDOR_ID=0bda
ID_MODEL=WR9210_NVME_PCIE
ID_MODEL_ID=9210

このID_VENDOR_IDがベンダーIDで、ID_MODEL_IDがプロダクトID。

今回の例ならベンダーIDは0bda、プロダクトIDが9210となる。

udevルールを追加

/etc/udev/rules.d/の中に任意のファイル名でルールファイルを作成(例: /etc/udev/rules.d/90-uasp-trim.rules)

次のような内容を追加する。

ACTION=="add|change", ATTRS{idVendor}=="ベンダーID", ATTRS{idProduct}=="プロダクトID", SUBSYSTEM=="scsi_disk", ATTR{provisioning_mode}="unmap"
# 実際の例
#ACTION=="add|change", ATTRS{idVendor}=="0bda", ATTRS{idProduct}=="9210", SUBSYSTEM=="scsi_disk", ATTR{provisioning_mode}="unmap"

ファイルを保存して、マシンを再起動する。

確認

確認のためfstrimを発行してみる。(実運用の際はsystemctlのfstrim.timerを有効にする)

$ sudo fstrim -v /mnt
/mnt: 467.4 GiB (501804867584 bytes) trimmed

どうやらこの外付けSSDはこれでtrimが可能になったようだ。

ちなみに、fstrimが報告するtrim済みバイト数に関してはファイルシステム依存らしく、実際にはほとんど無意味。

例えばetx4であればマウント後(再起動後)の最初の1回はディスク全域のバイト数になるが、2回目以降は実際に削除された分になる。

$ sudo fstrim -v /mnt
/mnt: 1.2 GiB (1299595264 bytes) trimmed

これは仕様なので気にしなくても良い。実際にどれだけの領域をtrimに掛けたかはファイルシステムから先の話の模様。

本当に効いてるのか？

ただ、これで「本当に出来てるのか？」と聞かれると、怪しいところはあると思う。

ファイルシステムがtrim命令を送るところまでは正常に成功してるが、変換チップ側でtrim命令を無視している可能性もゼロとは言い切れない。

trim対応を謳う機器を購入するのが確実なのは変わらない。

ベンチマーク

trimが出来てるか確認したいなら目一杯書き込んでから削除してベンチ取れば分かるよね的な雑な思考。

まず最初に、何も書き込んでいない状態でのパフォーマンス。機体がRaspberry Piなので性能低いのはご愛嬌。

SEQ-1M-Q8-T1-Read 376.508
SEQ-1M-Q8-T1-Write 129.23
SEQ-1M-Q1-T1-Read 242.165
SEQ-1M-Q1-T1-Write 172.434
RND-4K-Q32-T16-Read 149.522
RND-4K-Q32-T16-Write 20.358
RND-4K-Q1-T1-Read 16.832
RND-4K-Q1-T1-Write 21.406

次に、ディスクをフルになるまでランダムデータで埋めてから、空にした。

trimしていないのでファイルシステム的には空でもNANDはすべて埋まっているはず。

SEQ-1M-Q8-T1-Read 382.273
SEQ-1M-Q8-T1-Write 74.493
SEQ-1M-Q1-T1-Read 276.086
SEQ-1M-Q1-T1-Write 59.101
RND-4K-Q32-T16-Read 155.562
RND-4K-Q32-T16-Write 13.511
RND-4K-Q1-T1-Read 16.846
RND-4K-Q1-T1-Write 12.966

さすがにwriteのパフォーマンスは悲惨なくらいに落ちるな……そこからfstrimを実行した。

SEQ-1M-Q8-T1-Read 351.871
SEQ-1M-Q8-T1-Write 325.341
SEQ-1M-Q1-T1-Read 255.19
SEQ-1M-Q1-T1-Write 180.757
RND-4K-Q32-T16-Read 152.06
RND-4K-Q32-T16-Write 26.705
RND-4K-Q1-T1-Read 16.845
RND-4K-Q1-T1-Write 20.463

回復した。fstrimが効いていると判断してよさそうだ。

念のため大量のファイルを作成→trimしてハッシュなどが変わらない(データが破損しない)事も確認した。問題なかった。

ただしこれは当然ながらSSDによるので、ダメなやつもあるかもしれない。

参考

以下、参考にしたサイト

Archのサイトってほんっと情報が豊富だよね……

 - サーバー ,