Macで外付けSSDが遅くなった理由：Trimの問題

macOSTahoe ·
Macで外付けSSDが遅くなった理由：Trimの問題

外付けSSDの読み込みは速いのに書き込みだけが遅い。それはTrimの問題であり、誰もが勧める2つの確認方法はApple siliconでは何の役にも立ちません。

去年の春には40 GBのプロジェクトフォルダを900 MB/sでコピーできていた外付けSSDが、いまでは同じ作業に11分かかる。ほかには何も変わっていない。同じケーブル、同じポート、同じMac、同じドライブだ。それなのに、そのフォルダをドライブから取り出す方向にコピーすると、いまでも一瞬で終わる。読み込みは昔とまったく同じ速さのままだ。崩れたのは書き込みだけである。

この非対称性こそが答えのすべてだ。ケーブルの問題なら読み込みも書き込みも一緒に遅くなる。ポートの不良でも読み書きは一緒に遅くなる。サーマルスロットリングならすべてが遅くなり、エンクロージャが冷えれば回復する。読み込み速度は無傷のまま書き込み速度だけが崩壊しているドライブが示しているのは、特定の、そしてよく理解された故障だ。フラッシュの消去済みブロックが枯渇し、しかもどのブロックを消去してよいのかを誰も教えてくれていない。それがTrimの問題である。

厄介なのはその先だ。MacでTrimの状態を確認する方法を検索すると、何十ものサイト（私たち自身が公開した記事も含めて）で同じ2つのアドバイスが繰り返されているのを見つけることになる。確認には system_profiler SPSerialATADataType | grep TRIM を実行しろ。修正には sudo trimforce enable を実行しろ。だが現代のMacでは、1つ目のコマンドは何も出力せず、2つ目はUSBドライブに対して何の効果もない。どちらもタイプミスではないし、非推奨になったわけでもない。そして、適用されなかったことを知らせるエラーメッセージも出ない。ただ静かに、無関係であり続けるだけだ。

本記事はそこを正す。Trimが実際に何をしているのか、なぜその欠如が書き込みだけを罰するのかを説明し、Trimの問題とそっくりに見える4つの現象の見分け方を示し、標準的とされる2つの確認方法がなぜ失敗するのかを（自分で実行して失敗を目撃できるコマンド付きで）実演し、そのうえでApple silicon Macで本当に機能する2つの確認方法を提示する。本記事で「検証済み」と記載した内容はすべて、macOS 26.5.2（ビルド25F84）を実行するApple silicon Macで取得したものである。

要点まとめ

  • 読み書きの非対称性そのものが診断結果である — The Eclectic Light CompanyのHoward Oakley氏は具体的な数字を示している。「書き込み速度が読み込み速度の20%以下まで落ちているなら、Trimの問題だと確信してよい」
  • sudo trimforce enable は外付けドライブの修正手段ではない — マニュアルページ自身が「AHCIコントローラに接続されたサードパーティ製ドライブ」でTrimを有効にすると述べている。AHCIとはSATAインターフェイスのことなので、USBドライブやNVMeドライブには何の効果もない。
  • system_profiler SPSerialATADataType はApple siliconでは何も出力しない — そのデータタイプがこれらのマシンには存在しないため、インターネット上で最も多くコピーされているTrim確認コマンドは空の結果を返し、人々はそれを何かの証拠だと誤読する。
  • 実際に機能するのは system_profiler SPNVMeDataType とマウント時の統合ログである — APFSはボリュームがマウントされたときにTrimスキャンを記録するので、ドライブを抜き、時刻を控え、挿し直し、直後にログを読む必要がある。
  • 唯一の治療法は完全な消去と再フォーマットである — 任意のタイミングでドライブをTrimさせるユーザー向けコマンドは存在せず、購入前にどのエンクロージャがTrimを通すのかを教えてくれる互換性リストもAppleは公開していない。

Trimが実際にしていること、そしてなぜ書き込みだけが苦しむのか

消去ブロックという問題

フラッシュメモリにはシリコンの段階で組み込まれた非対称性がある。どのページも自由に読める。消去済みのページには書き込める。しかし、すでにデータが入っているページを上書きすることはできない。再利用するにはまず消去しなければならず、その消去はページ単位では起こらない。多数のページを含む、はるかに大きな単位である消去ブロック（erase block）全体に対して行われる。

Howard Oakley氏はその帰結を率直にこう述べている。「使用中のメモリブロックにSSDが書き込むには、まずそれを消去しなければならず、その消去〜書き込みサイクルの所要時間は絶望的なほど遅い」

これがメカニズムのすべてだ。消去済みブロックの在庫が潤沢なドライブでは、到着した書き込みは単純なプログラム動作で済み、公称速度で完了する。在庫がゼロのドライブでは、到着する書き込みのたびに一連の作業が発生する。古くなったページを含むブロックを探し、まだ有効なページを読み出し、その有効ページを別の場所に書き、ブロック全体を消去し、そこでようやく新しいデータを書く。この連鎖はリード・モディファイ・ライトと呼ばれ、クリーンな書き込みの一桁多い時間を要することがある。

なぜドライブは自力で判断できないのか

ここが多くの人を驚かせる部分だ。ファイルを削除しても、ドライブはそれを知らない。ファイルシステムは自分のメタデータを更新してそれらの論理ブロックを空きとして記録するが、ドライブコントローラの視点からは、これまで書けと言われたすべての論理ブロックが依然として有効なデータを保持している。先月削除した動画が入っていたブロックと、いま作業中のプロジェクトファイルが入っているブロックを区別する手段がない。どちらも保持し続けるしかない。

Trimはそのギャップを埋めるためのメッセージだ。ファイルシステムが領域を解放したとき、OSがもう気にしていない論理ブロックアドレスを列挙したTrimコマンドを送ることができる。ドライブはそれらを無効としてマークし、バックグラウンドのガベージコレクションが自由にそれらを整理して消去できるようになる。こうして、書き込みを速いまま保つ消去済みブロックのプールが構築される。

Trimがなければ、そのプールはドライブが埋まるにつれてゼロに向かって縮み、その後は永久にゼロのままだ。ドライブは壊れていないし、フラッシュも摩耗していない。ただ、何時間も前にバックグラウンドで済ませられたはずの消去サイクルに、ほとんどの時間を費やしているだけである。

なぜ読み込みは完璧に速いままなのか

読み込みには消去が一切不要だ。読み込みとは、フラッシュ変換レイヤーでの検索と、それに続くページのセンス動作である。ドライブが本当に有効な100ギガバイトを抱えていようと、半年前に論理的に削除された100ギガバイトを抱えていようと、要求されたページを返す速度にはまったく違いが出ない。

だからこそこの症状は際立っており、信頼に値する。Trimの問題を抱えたドライブは病気ではない。ほかに取れる測定値はすべて正常に見える。S.M.A.R.T.のステータスは良好、ボリュームは即座にマウントされ、Disk UtilityのFirst Aidは通過し、シーケンシャルリードは初日と同じ数字を出す。劣化しているのは書き込みパスだけだ。消去済みブロックを手元に持っていることに依存しているのが、書き込みパスだけだからである。

一度もTrimされなかったドライブの経時変化

劣化は線形でもなければ即座でもない。だからこそ人々が気づくまでに数か月かかる。

新品または消去したての SSDは全ブロックが消去済み状態にあるので、書き込みはそのまま通る。それは、ドライブがおおよそ全容量ぶん一度は書き込まれるまで続く。重要なのは、いまFinderでどれだけ埋まって見えるかよりも、累積の書き込みバイト数だ。どの瞬間も400 GBまでしか保持したことのない2 TBのドライブでも、400 GBの映像素材を20回入れ替えていれば、物理ブロックはすべて触られている可能性がある。

その先は、Trimを受け取るドライブなら削除のたびにきれいに回復する。受け取らないドライブは決して回復しない。コントローラは書き込んだ全ブロックを有効としてマークし続け、オーバープロビジョニングのマージン（メーカーが確保している小さな予備領域で、通常は1桁パーセント）だけが唯一の空き領域となり、到着するすべての書き込みでリード・モディファイ・ライトをすり潰すように繰り返す。

そのため、ドライブは6〜18か月ほどは問題なさそうに見え、その後の数週間で痛みを伴うほど遅くなる。その数週間に何かが起きたわけではない。閾値を越えただけだ。

症状の見分け方：Trimの問題とそっくりな4つの現象

Macで外付けドライブが遅くなる原因はいくつもあり、そのうち3つはドライブの最初の1年ではTrimよりずっと多く見られる。何かを消去する前に、正しい故障を見ているのかを確認してほしい。

この症状はよくあるもので、Appleのサポートフォーラムにも繰り返しスレッドが立っている。ディスカッション254727504「Why is my external SSD so slow at writing?」やディスカッション255040461「Slow external SSD」などだ。テストを始める前に、ほかの人が同じ問題をどう表現しているか見ておきたいなら、そのあたりは妥当な参照先である。

比率テスト

少なくとも8 GBの大きなファイルを1つ、両方向にコピーして時間を計る。小さなファイルの詰まったフォルダではだめだ。それはスループットではなくファイルシステムのオーバーヘッドを測ってしまう。大きなファイルを1つ、である。

そして比較する。読み込みも書き込みも遅く、しかも互いに近い値なら、問題はフラッシュではなく接続側にある。読み込みが正常で書き込みがそのごく一部なら、Trimの領域だ。覚えておくべき有用な閾値はOakley氏のもの、すなわち読み込み速度の20%以下なら確信してよい、である。

症状の比較表

観察される現象最も可能性の高い原因確認方法
書き込みが遅く読み込みは正常、去年までは両方問題なかったTrimがドライブまで届いていない比率テスト、続いて後述のマウント時ログ確認
読み込みも書き込みも同程度の割合で遅いケーブル、ポート、または公称より低い速度でネゴシエートされたリンクケーブルを交換、別のポートを試す、System Informationでネゴシエート速度を確認
最初は速く、20〜60秒で大きく落ち、休ませると回復するSLC書き込みキャッシュの枯渇、またはサーマルスロットリング3分以上の転送を1回実行して曲線を観察する。エンクロージャに触れてみる
小さなファイルが大量に入ったフォルダのときだけ遅いファイルシステムとメタデータのオーバーヘッド、Spotlightのインデックス作成、セキュリティソフト大きなファイル1つで再試行する。それが速いならドライブの問題ではない
ランダムに切断される、「ディスクの取り出しエラー」が出る、コピー中にドライブが消えるバス電力またはエンクロージャの電源管理まず切断を直すこと。それまではどの速度測定も信用できない
Disk Utilityには出るがFinderには出ない、または二重に表示されるパフォーマンスではなくマウント層のバグ速度の障害ではまったくないので、消去しても解決しない
あるMacでは遅く別のMacでは速い、ケーブルは同じそのMacのポート、ハブ、またはドック途中にハブを挟まず、両方のマシンに直結してテストする
初日からずっとこの遅さだったTrimではない。本当にSSDなのか、リンクが何でネゴシエートされているかを確認新品のドライブは全ブロックが消去済みで、まだTrimの問題は起こり得ない

最後の行は強調しておく価値がある。理由もなくドライブを消去してしまう人を救えるからだ。ずっと遅かったドライブにTrimの問題は存在し得ない。 Trimによる劣化には履歴が必要だ。箱から出した時点で遅かったのなら、エンクロージャ、ケーブル、そして支払った速度でリンクが確立しているかどうかを見るべきである。

まず接続を排除する

ここでの2分間の作業が、不要な消去を防いでくれる。

System Informationを開き（Optionキーを押しながらAppleメニューをクリックし、システム情報を選ぶ）、USBまたはThunderbolt/USB4の項目でドライブを探す。箱に印刷された速度ではなく、リンクが実際にネゴシエートした速度を確認すること。10 Gb/s対応のドライブが充電用ケーブルのせいで480 Mb/sのリンクで接続されていれば、双方向とも壊滅的に遅くなる。

system_profiler SPUSBHostDataType

このコマンドは同じUSBツリーをテキスト形式で、接続されている各デバイスのリンク速度も含めて出力する。Thunderbolt接続なら代わりに SPThunderboltDataType を使う。どちらのデータタイプもApple siliconに存在する。次のセクションで説明するとおり、誰もが使えと言ってくるあのデータタイプとは違って、である。

結論を出す前にケーブルも交換すること。USB-Cケーブルが実際に何をサポートしているかは製品によって大きく異なり、充電は完璧にこなすのにデータはUSB 2.0の速度に制限されているものもある。この変数を排除するのにコストはかからず、「SSDが遅くなった」という報告の多くはこれで説明がつく。

現代のMacで、インターネット上の2つの標準的な確認方法が失敗する理由

ここが最も重要なセクションだ。というのも、ここでの誤った助言は単に役に立たないだけではないからだ。静かで空っぽで、エラーも出ない結果を出力し、人々がそれを答えだと解釈してしまうという点で、能動的に人を誤らせる。

trimforce はほぼ全員が言っているような動作をしない

自分のMacで man trimforce を実行してみてほしい。マニュアルページはApple siliconのmacOS 26.5.2にもまだ存在しており、それがこの助言が死に絶えない理由の一部でもある。以下が、そこに書かれている内容の逐語訳である。

NAME行はこうだ。「trimforce – サードパーティ製ドライブでTRIMコマンドを有効にする」

DESCRIPTIONはこうだ。「trimforceは、AHCIコントローラに接続されたサードパーティ製ドライブへのTRIMコマンド送信を有効にする。デフォルトでは、TRIMコマンドはサードパーティ製ドライブには送信されない。一部のドライブはコマンドを正しく処理できない場合があるため、TRIMを有効にする際は細心の注意を払うこと。trimforceはシステム管理者が実行しなければならない」

enable 動詞はこう文書化されている。「AHCI接続のサードパーティ製ドライブへのTRIMコマンド送信を開始する。有効にするには再起動が必要」

そしてHISTORYセクションはこうだ。「trimforceユーティリティはOS X 10.10.4で初めて登場した」

DESCRIPTIONをもう一度読み、AHCIコントローラに接続されたという部分で立ち止まってほしい。AHCI（Advanced Host Controller Interface）は、SATAストレージ向けの標準的なホストインターフェイスである。USBではない。NVMeでもない。Thunderboltでもない。

trimforce が2015年のOS X 10.10.4で作られた目的は、特定の、そして今日ではほぼ歴史的となった状況にある。回転式ドライブやApple製SATA SSDを搭載して出荷されたMacを開け、サードパーティ製SATA SSDを内部に取り付けたところ、macOSがAppleの認定していないドライブにTrimを送ることをデフォルトで拒否する、という状況だ。trimforce はその拒否を上書きする。それがこのコマンドの全目的であり、「コマンドを正しく処理できない場合がある」という警告が存在するのは、2015年当時、Trimされるとデータを失いかねないファームウェアのバグを持つSATA SSDが実在したからである。

USBエンクロージャに入った外付けSSDにとって、trimforce は無関係だ。経路のどこにもAHCIコントローラは存在しない。ドライブはUSBマスストレージまたはUASPのブリッジの向こう側にあり、Trimがフラッシュまで届くかどうかを決めるのはmacOS内のスイッチではなく、そのブリッジチップである。NVMeドライブについても、内蔵であれThunderboltエンクロージャ内であれ、同じく無関係だ。NVMeもまたAHCIではないからである。

私たち自身もこれを間違えていた。 以前公開したmacOS外付けSSDトラブルシューティングガイドでは、外付けドライブのパフォーマンスを扱うセクションの「サードパーティ製SSDでTRIMを有効にする」という項目に sudo trimforce enable を挙げていた。あの推奨は外付けドライブに対しては誤りであり、本記事がそれに取って代わる。マニュアルページは2015年からずっと同じことを書いていた。私たちが十分に注意深く読んでいなかったのだ。あの助言を信じてコマンドを実行したとしても、悪いことは何も起こっていないし、良いことも何も起こっていない。

反射的にこのコマンドに手を伸ばすべきでない理由はもう一つある。マニュアルページ自身の「細心の注意を払うこと」という指示は現実の障害モードについてのものであり、しかもこのコマンドは有効化に再起動を要求する。データ損失の注意書きが文書化されたシステム全体のストレージ設定変更を、明示的に対象外とされているドライブに効くかもしれないという期待だけで実行するのは、どんな確率で見ても割に合わない取引だ。

system_profiler SPSerialATADataType は空の結果を返す

もう一つの、どこにでも繰り返されている確認方法がこれだ。

system_profiler SPSerialATADataType | grep TRIM

Apple silicon Macでは、これは何も出力しない。「TRIM Support: No」でもない。まったくの無出力だ。しかもその理由はTrimが無効だからではない。そのデータタイプがそのマシンに存在しないからである。

これは1つのコマンドで自分で確認できる。

system_profiler -listDataTypes | grep -i sata

Apple silicon Macでは一致するものが返らない。フィルタなしで system_profiler -listDataTypes を実行すればマシンが実際に持っているものが表示され、私たちがテストしたMac（macOS 26.5.2、ビルド25F84）では、ストレージ関連の項目として SPNVMeDataType、SPStorageDataType、SPThunderboltDataType、SPUSBHostDataType などが含まれていた。SPSerialATADataType は存在しない。Apple silicon MacにはSATAコントローラが一切ないからだ。内蔵SSDはSoCに接続されたNVMeであり、マシンのどこにもユーザーがアクセスできるSATAバスは存在しない。

つまり、インターネット上で最も広くコピーされているTrim確認コマンドは、現代のMacに対して存在しないハードウェアについて問い合わせ、空の答えを受け取り、その空の答えを grep に流し込み、grep は律儀にその中から何も見つけられない、ということをしている。エラーもなく、警告もなく、誰かが気づくような終了コードもない。人々はそれを実行し、空白の出力を見て、もともと傾いていたほうの結論を引き出すのだ。

実際にSATAバスを持つIntel Macでは、このコマンドは機能し、SATAデバイスのTrim状態を報告する。まだIntel Macを使っているなら、内蔵ドライブについては依然として有用だ。ただしどのMacであっても、USB接続の外付けドライブについて何かを教えてくれたことは一度もない。

diskutil もTrimの状態を報告しない

3つ目のバリエーションとして目にするのが、Disk Utilityや diskutil でTrimの状態を確認するという提案だ。そこには存在しない。

diskutil info -all | grep -i trim

私たちがテストしたMacでは何も返らない。diskutil info -all はシステム上のすべてのディスクとすべてのボリュームについて diskutil が知っているあらゆるプロパティを出力するが、その中にTrimは含まれていない。Disk Utilityのグラフィカルな情報パネルにも表示されない。これは見るペインを間違えているという話ではない。diskutil は本当にTrimの状態を公開していないので、そこで読み取れると示唆するガイドは、実際には起こらないことを説明していることになる。

Apple silicon Macで利用可能なデータタイプを一覧表示するsystem_profilerのターミナル出力。SATAの項目は存在しない

実際に機能する確認方法

方法は2つあり、どちらが該当するかはドライブの接続方式によって決まる。

内蔵ドライブとNVMeドライブ向けの system_profiler SPNVMeDataType

Macの内蔵SSD、およびSCSI変換レイヤーを介さずmacOSが直接NVMeで会話しているThunderboltやUSB4接続のNVMeドライブについては、macOSはTrimのサポート状況を報告してくれるし、それは簡単に読める。

system_profiler SPNVMeDataType

出力は小さなインデント付きのツリーだ。NVMExpress: で始まり、次にコントローラの項目（Apple siliconでは Apple SSD Controller:）、そして見出しとしてドライブのモデル名が続く。私たちがテストしたMacでは、そのモデル見出しの下に報告されるキーが次の順で現れた。Capacity、TRIM Support、Model、Revision、Serial Number、Detachable Drive、BSD Name、Partition Map Type、Removable Media、S.M.A.R.T. status、Volumes。

見たいのは2行目の TRIM Support である。テストしたMacの内蔵ドライブでは Yes と表示された。それが健全な答えの姿であり、Oakley氏による状況のまとめとも一致する。「Appleの内蔵SSDはすべてTrimを完全にサポートしており、NVMeインターフェイスを持つサードパーティ製外付けドライブもそうであるはずだ」

その行だけを抜き出すには、次のようにする。

system_profiler SPNVMeDataType | grep -A1 -i "capacity"

あるいは、ツリー全体を読んでしまってもよい。フィルタをかける価値がほとんどないほど短いからだ。外付けNVMeエンクロージャがこの出力に現れているなら状況は良好である。ここに現れること自体が、macOSがUSBマスストレージでトンネリングするのではなくNVMeで会話していることを意味するからだ。

重要な制約は次のとおり。ほとんどのUSB外付けSSDは SPNVMeDataType にまったく現れない。 エンクロージャの中身がNVMeモジュールであっても、USBブリッジはそれをUSB経由のSCSIデバイスとしてMacに提示するので、代わりに SPUSBHostDataType と SPStorageDataType に現れる。NVMeのリストに載っていないことは、Trimされているかどうかの判定にはならない。単に、この方法ではその問いに答えられないという意味であり、そのときは2つ目の方法が必要になる。

マウント時ログによる方法

これはAPFSでフォーマットされたあらゆるドライブに対して、接続方式にかかわらず機能する確認方法であり、Howard Oakley氏の手法である。APFSが特定の、観測可能な瞬間にTrimを実行しているために成り立つ。

APFSボリュームがマウントされると、APFSのスペースマネージャがコンテナをスキャンして空きブロックを探し、それらに対してTrimを発行する。そして何をしたかを統合ログに記録する。記録は spaceman_scan_free_blocks で始まるエントリだ。Trimが行われたコンテナでは、スキャンとともにTrimの活動が表示される。Trimが行われなかったコンテナでは、スキャンのあとに (no trims) というマーカーが表示される。

その1つの文字列が答えである。マウントしたばかりで空き領域もあるドライブに (no trims) が出るなら、Trimはそのドライブに届いていない。

手順は次のとおり。

  1. ドライブを正しく取り出す。Finderで右クリックして「取り出す」を選ぶか、diskutil eject /dev/diskN を使う。ケーブルをいきなり引き抜かないこと。
  2. 物理的に接続を外す。数秒待つ。
  3. 正確な時刻を控える。Macが使っているのと同じ時計で、秒単位まで。ターミナルの date で正確に得られる。
  4. ドライブを再接続し、ボリュームがFinderに現れてマウントが完了するまで待つ。10〜20秒ほど見ておく。
  5. 接続前後の時間帯についてログを読む。
log show --last 2m --predicate 'senderImagePath CONTAINS[c] "apfs"'

Oakley氏の述語は senderImagePath CONTAINS[c] "apfs" で、これはサブシステムの命名にかかわらずAPFSのコードから発せられたものをすべて捕まえる。時刻を控えていて、より狭い範囲を指定したいなら、log show は明示的な範囲指定も受け付ける。

log show --start "2026-08-15 14:30:00" --end "2026-08-15 14:30:40" --predicate 'senderImagePath CONTAINS[c] "apfs"'

これでもまったく何も返らない場合は、情報レベルのエントリを含めるために --info を追加し、それでも空なら続けて --debug を追加する。これらのフラグは一致条件を変えるのではなく、レベルのフィルタを広げるものだ。

そのうえで結果から spaceman_scan_free_blocks を検索し、自分のドライブのデバイス（disk5、disk6 など、diskutil list が示すもの）を名指ししているエントリを見つけ、(no trims) マーカーを探す。ディスク番号がテスト対象のドライブと一致しているか確認すること。起動コンテナやほかにマウントされているAPFSボリュームもそれぞれ独自のエントリを出すので、別のものを読んでしまいやすい。

稼働時間がこの確認を台無しにする理由

ここに罠がある。そして、多くの人がこの方法を試して「ログの方法は使えない」と結論づけてしまう理由でもある。

APFSのTrimメッセージはマウント時にしか出力されない。 定期的なものではない。1時間ごとのハートビートのようなものは存在しない。3週間前にマウントされたボリュームがそのままマウントされ続けていれば、そのTrimエントリは3週間前に書かれており、ログの保持期間からとっくに消えている。

私たちはまさにこれを検証した。稼働時間21日のMacで次を実行したところ、

log show --last 7d --predicate 'senderImagePath CONTAINS[c] "apfs"'

返ってきた行はゼロだった。まる1週間のログの中に1件もない。しかもそれは、TRIM Support: Yes を報告する完全に健全な内蔵SSDを備えた、完全に健全なマシンでの結果である。起動ボリュームは3週間前の起動時にマウントされ、それは保持期間の外であり、それ以降何もマウントされていなかったのだ。

したがって --last 7d のクエリが空白で返ってくることには何の意味もない。それはTrimが壊れている証拠でもなければ、機能している証拠でもない。最近何もマウントされていないという証拠にすぎない。この確認が答えを出すのは、ログを読む直前に自分でマウントイベントを作った場合だけである。抜いて、時刻を控えて、挿し直して、それから読む。この順番で、遅延なしに。

ターミナルを使いたくない場合のOakley氏のツール

Howard Oakley氏は、この作業をラップした無料ユーティリティを2つ提供している。MintsにはマウントのタイミングのログウィンドウをキャプチャするDisk Mount機能があり、LogUIは同じ述語をインターフェイス経由で適用できる汎用の統合ログブラウザだ。どちらもThe Eclectic Light Companyから入手できる。log show の呼び出しを手で組み立てたくないなら、これらは同じ仕事を、述語のタイプミスの余地を減らしてこなしてくれる。

読み込みと書き込みを誠実にベンチマークする方法

比率テストは測定の質を超えられないし、SSDに対する気軽なベンチマークの多くは、安心はさせてくれるが意味のない数字を生む。

新品のドライブが常に良好に見える理由

ドライブを消去した直後にベンチマークすれば、公称速度が出る。全ブロックが消去済みで、すべての書き込みがクリーンなプログラム動作であり、ベンチマークの長さのあいだそれを維持するのにTrimは要らないからだ。「フォーマット直後に速度テストをしたら問題なかった」がTrimの動作について何も語らないのは、このためである。Trimが無関係となる唯一の条件を測ってしまったのだ。

同じ理由で、本記事の後半で説明する治療法は即座に効いたように見え、その後、依然としてTrimされていないドライブでは、数か月後に静かに効かなくなる。

意味のある測定をするには、ドライブがTrimの効いてくる状態、すなわち相当に使い込まれ、書き込みと削除の実際の履歴を背負った状態にある必要がある。

実際の使用を反映するテストを組む

この目的でベンチマークを誠実にするには、4つの条件がある。

大きなファイルを使う。 少なくとも8 GB、理想的にはドライブのSLCキャッシュ（コンシューマ向けドライブでは容量の数パーセント程度であることが多い）を超えるサイズ。小さなファイルのテストはメタデータ処理を測ってしまい、見たいフラッシュの挙動を覆い隠す。

ドライブを半分以上埋めておく。 ほぼ空のドライブは、Trimの状態にかかわらず空き領域を持っている。追いかけている問題が現れるのは、コントローラが消去済みブロックを切らしているときだ。

大量削除のあとでテストする。 大きなものを削除し、ゴミ箱を空にし、それから書き込む。これはまさにTrimが処理するために存在するシナリオである。ファイルシステムが空きとみなしていて、ドライブがそれを知っているかもしれないし知らないかもしれない領域、という状況だ。

最初の数秒ではなく持続的なスループットを測る。 現代のSSDはどれも最初のバーストを高速なキャッシュに吸収させる。転送を3分間観察し、どこに落ち着くかを見ること。

粗いが誠実なコマンドラインでの測定

dd なら何もインストールせずに数字が得られる。まず書き込みだ。

dd if=/dev/zero of=/Volumes/YourDrive/speedtest.bin bs=1m count=8192

これは8 GBのゼロを書き込む。完了すると dd は転送バイト数、経過時間、1秒あたりのバイト数によるスループットを含むサマリー行を出力する。そのスループットを控えておく。

次に、読み込みテストがRAMではなく実際にドライブから読むように、Macのディスクキャッシュをフラッシュしてから、ファイルを読み戻す。

sudo purge
dd if=/Volumes/YourDrive/speedtest.bin of=/dev/null bs=1m

2つのスループットの数値を比較する。そのあとテストファイルを削除する。

注意点が1つ。SSDコントローラの中には繰り返しの多い入力を圧縮したり重複排除したりするものがあり、純粋なゼロだけのファイルは最も簡単なケースなので、/dev/zero からの dd はドライブを実力以上に良く見せることがある。それを避けるには、代わりに動画などの大きな実ファイルをコピーして時間を計るとよい。グラフィカルな代替手段でも問題ない。Blackmagic Disk Speed Testは数分にわたって落ち着いていく様子を観察できる連続表示を出すので、キャッシュ枯渇による落ち込みが見つけやすい。

結果の読み方

同じドライブ、同じケーブル、同じポート、同じセッションで、書き込み速度を読み込み速度に対する百分率として計算する。

80%以上なら問題はない。フラッシュでは書き込みが読み込みよりいくらか遅いのは通常のことであり、昔からそうだ。

40%から80%のあいだは曖昧な領域だ。初期段階のTrimの問題かもしれないし、キャッシュを使い切ったドライブかもしれないし、熱の挙動かもしれないし、単にそのモデルの性能かもしれない。大量削除のあとに再テストし、マウント時ログの確認を実行すること。

20%を下回るなら、Oakley氏の言葉どおりに受け取り、Trimの問題として扱ってよい。彼の言い回しは意図的なものだ。その比率であれば「Trimの問題だと確信してよい」

同一の外付けSSDにおける読み込みと書き込みのスループット比較。書き込みは読み込みのごく一部にとどまっている

ファイルシステムの選択：APFS、HFS+、そしてexFATの罠

どのファイルシステムでドライブをフォーマットしたかが、ハードウェアの話をする以前に、そもそもTrimが試みられるかどうかを決める。

exFATはTrimしない

これは、この問題全体の中で最も簡単に避けられる原因だ。Oakley氏は直截にこう述べている。「APFSとHFS+は通常、SSDがマウントされるたびにTrimを行うが、ExFATのような古いPC用ファイルシステムでフォーマットされたドライブは、まずTrimされることはない」

exFATはドライブが出荷時にフォーマットされている形式だ。追加ソフトなしでmacOSとWindowsの両方が読み書きできる唯一の形式だからである。また、MacとPCのあいだでドライブを行き来させる必要があるときに、人々が意図的に選ぶ形式でもある。そしてそれは、どんなエンクロージャに入っていようと、どう接続されていようと、どの確認方法が何を報告しようと、そのドライブがmacOSからTrimコマンドを受け取ることは決してないことを意味する。

遅い外付けSSDがexFATなら、答えは見つかったのであり、ログの確認を実行する必要はない。スキャンすべきAPFSコンテナが存在しないので、APFSのマウントエントリはそもそも1件も出ない。

クロスプラットフォームというトレードオフ

このトレードオフは現実のものであり、ただで済む答えはない。だからこそ、自分がどちら側を選んでいるのかを明確にしておくべきだ。

フォーマットmacOSでのTrimWindowsとの互換性適した用途
APFSあり、マウントのたびに標準ではなし。サードパーティ製ソフトが必要Mac専用のドライブ、新しいmacOSでのTime Machine、パフォーマンスが重要なあらゆる用途
HFS+（Mac OS拡張）あり、マウントのたびに標準ではなし。サードパーティ製ソフトが必要古いMac、レガシーなワークフロー、非常に古いシステムで動作する必要があるドライブ
exFATなしあり、標準で対応パフォーマンスの代償を受け入れたうえでの、本当にクロスプラットフォームな共有

MacとWindowsマシンの両方に挿すドライブが本当に必要なら、exFATは現実的な選択であり、書き込み性能が経年で劣化することは受け入れるべきだ。ドライブの使用量を容量に対して十分低く保ち、まったく再フォーマットしないのではなく時折再フォーマットすることで緩和できる。しかし、クロスプラットフォームのアクセスが毎週必要なことではなく「いつか欲しくなるかもしれないこと」でしかないなら、APFSでフォーマットすること。ファイルはいつでもネットワーク越しにコピーできるし、何年も速いままのドライブは、仮想的な利便性に勝る。

HFS+はTrimされるが、余命は限られている

HFS+はいまでもTrimされるし、いまでも機能する。しかしMacでの長期的な選択としては良くなく、特に暗号化されたHFS+は廃止への道を歩んでいる。HFS+の外付けドライブを使っていて、どのみち再フォーマットを考えているなら、いまがAPFSに移行する好機だ。暗号化されたHFS+ボリュームをAPFSに変換するガイドで、移行手順とTime Machineへの影響を扱っている。

接続の選択：USBブリッジ対ThunderboltとNVMe

ファイルシステムは必要条件ではあるが十分条件ではない。APFSのドライブであっても、Trimコマンドが物理的にフラッシュコントローラまで到達する必要があり、そこでエンクロージャが関わってくる。

ブリッジチップがやらなければならないこと

USB外付けSSDは、Macと直接会話しているドライブではない。エンクロージャの中にはブリッジチップがあり、USBと、ストレージモジュールが話す言語（SATAまたはNVMe）とのあいだを翻訳している。macOSはストレージのコマンドをUSB上でSCSIとして、通常はUASP（USB Attached SCSI Protocol）を使って送り、TrimにあたるSCSIのコマンドはUNMAPである。

つまりコマンドは連鎖を生き延びなければならない。APFSがTrimを決断し、macOSがUSB上でUNMAPを発行し、ブリッジチップがそれを受け取り、ブリッジチップがそれをSATAのTRIMまたはNVMeのDeallocateに翻訳し、ストレージモジュールがそれを実行する。ブリッジがその翻訳を実装していなければ、コマンドは破棄される。しかも静かに。どこにもエラーは現れない。だからこそ診断が難しく、だからこそログによる確認だけが唯一信頼できる読み取り手段なのだ。

ベンダーの資料とコミュニティの検証を通じて一般に報告されている状況は、USBブリッジ越しのTrimパススルーは一貫していない、というものだ。UNMAPを通すブリッジもあれば、通さないものも多く、しかもそれはドライブのブランドではなくチップとファームウェアのリビジョンによって変わる。ThunderboltやネイティブNVMeの経路が信頼できるルートなのは、コマンドを失う翻訳レイヤーが存在しないからである。再びOakley氏のまとめを引く。「Appleの内蔵SSDはすべてTrimを完全にサポートしており、NVMeインターフェイスを持つサードパーティ製外付けドライブもそうであるはずだ」。この「はずだ」は彼の言葉であり、誠実な仕事をしている点に注意してほしい。

最もリスクが高いのは古いSATAドライブだ。Oakley氏の言葉では「SATAインターフェイスの遅いドライブこそ、Trimをサポートしていない可能性が最も高い」。外付けがUSBケースに入ったSATA SSDなら、これは余った2.5インチSSDから組み立てられた多くのドライブに当てはまる構成だが、存在する中で最もリスクの高い構成である。

Appleは互換性リストを公開していない

これははっきり述べておく。買い方が変わるからだ。Appleは、macOSでTrimをサポートする外付けエンクロージャのリストを公開していない。 サポート文書もなければ、認定ハードウェアのページもなく、USB接続ドライブについてそれを報告するAPIもなく、System Informationでの表示もない。Appleは外付けストレージのTrimの挙動をそもそも一切文書化していない。

つまり、あるエンクロージャがTrimを通すかどうかを購入前に知る権威ある手段は存在しない。メーカーのマーケティングも当てにならない。ほとんどのエンクロージャベンダーはTrimについてどちらの方向にも言及していないからだ。知る唯一の方法は、買って、APFSでフォーマットして、マウント時ログの確認を実行することである。

これは本当に不満の残る状況であり、特定のチップセットがmacOSでTrimを明確にサポートする／しないと断言する人がいれば、それは利用可能な証拠が支持する以上のことを主張している。チップのファームウェアのリビジョンは異なるし、エンクロージャのベンダーは型番を変えずに中身を変えるし、macOS自身の挙動もリリースごとに変わってきた。自分が所有しているドライブをテストすること。

購入時にこれが意味すること

互換性リストが存在しない以上、翻訳の問題がそもそも生じない構成を優先すべきだ。ThunderboltまたはUSB4のNVMeエンクロージャは方程式からブリッジを取り除き、副次的な利点としてはるかに高いスループットをもたらす。すでに接続まわりを検討しているなら、Thunderbolt 5ドック購入ガイドで現行世代のハードウェアが実際に何を提供するのかを扱っている。

ケースと余ったドライブから自分で組み立てるのではなく、大手メーカーの一体型ポータブルSSDを買うほうが概してリスクは低い。そのモジュール専用にベンダーがブリッジを選定し検証しているからだ。保証にはならないが、変数が1つ減る。

そして何を買うにせよ、返品がまだ簡単な最初の1週間のうちにテストすること。APFSでフォーマットし、データをいくらかコピーし、いくらか削除し、取り出し、再接続し、ログを読む。2分で分かる。

治療法：消去して再フォーマットする

任意のタイミングでドライブをTrimさせるコマンドは存在しない

「いますぐドライブをTrimする」コマンドを探す人がいるが、そんなものはない。macOSは、要求に応じてボリュームにTrimを発行するユーザー向けの手段を一切公開していない。trimforce は、これまで見てきたとおりAHCI接続のサードパーティ製ドライブに対するシステムポリシーを切り替えるだけで、ここには当てはまらない。Disk Utilityにそのような機能はない。diskutil にそのような動詞もない。

ドライブを巨大なファイルで埋めてから削除するという提案も見かけるかもしれない。それは役に立たないし、Trimを受け取っていないドライブでは、コントローラが有効とみなすデータをさらに書き込むことになり、事態を悪化させる。

残された手段についてOakley氏は明確だ。「唯一の治療的処置は、SSDを完全に再フォーマットし、それで通常の書き込み速度が回復するかどうかを見ることである」

ドライブを消去すると、パーティションマップとファイルシステムがゼロから再構築される。コントローラがそれを尊重するドライブでは、消去自体が事実上ブロックを空き状態に戻し、ドライブはフルスピードで戻ってくる。この修正が本物である理由がそれだ。そして同時に、根底のTrim経路が壊れたままなら一時的なものにすぎない理由でもある。メカニズムを直さずに時計を巻き戻しただけだからである。

まずデータを、きちんと退避する

消去するとドライブ上のすべてが失われるので、Disk Utilityに触れる前にすべてをコピーし、検証すること。「コピーが終わった」ではなく、実際にコピー先から大きなものを含む複数のファイルを開き、無傷であることを確認する。このドライブは読み込みが依然として速いので、この作業はすぐ終わる。この障害モードのささやかな救いである。

そのドライブが何かの唯一のコピーを保持しているなら、まずどこか別の場所に2つ目のコピーを作ること。Trimの問題を抱えたドライブは故障しているわけではなく、消去中に死ぬ可能性は低いが、大切なものを1コピーしか持たない状態を作ってはいけない。そしてそのドライブがTime Machineの保存先なら、あなたはバックアップ履歴を捨てようとしている。決める前に後述のTime Machineのセクションを読んでほしい。

消去の実行

Disk Utilityを使い、まずデフォルト設定を1つ変える。

Disk Utilityを開き、「表示」→「すべてのデバイスを表示」を選ぶ。これが重要だ。これをしないとDisk Utilityはボリュームしか表示せず、ボリュームを消去してもコンテナとパーティション方式は残ってしまう。消去したいのは物理デバイス、つまりサイドバーでドライブのモデル名が付いた最上位の項目である。

その最上位のデバイスを選び、「消去」をクリックして、次のように設定する。

  • 方式: GUIDパーティションマップ
  • フォーマット: APFS（exFATにする明確な理由がない限り）

ドライブを複数回上書きするセキュリティオプションのスライダーは使わないこと。SSDでは遅く、何の利点もないまま膨大な量のデータを書き込み、しかも回復しようとしているまさにそのブロック状態に逆行する。

コマンドラインで済ませたい場合の同等の手順は次のとおり。

diskutil list
diskutil eraseDisk APFS DriveName GPT /dev/diskN

まず diskutil list を実行し、出力を注意深く読んで正しいデバイスを特定すること。間違った diskN に対する eraseDisk は間違ったドライブを破壊するし、確認のプロンプトは出ない。

そのあとに期待できること

直後にベンチマークすれば速いだろう。それが証明するのはフラッシュが健全であることだけで、それ以上のことは何も示さない。

本当のテストはその後の数か月に起こることだ。データを書き戻し、普通に使い、実際の削除と再書き込みのサイクルをドライブが経たあと、6〜8週間後に比率テストをもう一度実行する。書き込み速度が保たれていれば、おそらくTrimはドライブに届いており、今回は一度限りの出来事だったことになる。同じ曲線でまた劣化するなら、エンクロージャがTrimを通しておらず、再フォーマットは修正ではなく定期的に行うメンテナンスだということだ。

その時点で判断は経済的なものになる。1時間で作り直せる作業用ディスクなら、定期的な再フォーマットは許容できる。運用中のアーカイブなら許容できない。そのドライブが重要なら、エンクロージャをThunderboltまたはNVMeのユニットに置き換えてそちらをテストするのが持続的な答えである。

予防：ドライブをこの状態に陥らせない

余裕を残す

最も効果的な習慣がこれだ。使用率を70%以下に保っているドライブは、Trimがなくてもコントローラが使える空き論理領域を持っている。一度も書き込まれていないブロックは消去済みのままだからだ。98%まで埋めて使ってきたドライブは、事実上すべてのブロックが触られており、余裕がまったくない。

これは内蔵ストレージにも当てはまる。同じ物理法則が起動SSDを支配しているからだ。ただしそちらではTrimが確実に機能している。ストレージ管理ガイドで、満杯に近づいてきたMacで空き領域を見つけて取り戻す方法を扱っている。

満杯まで詰め込むワークフローを避ける

ドライブにとって、ほかよりはるかに過酷な習慣がある。カメラの映像素材でドライブを容量いっぱいまで満たし、全部吸い出し、また満たす、というのが最悪のケースだ。触れるブロックは最大、Trimへの依存も最大、それが無期限に繰り返される。映像制作の職業ユーザーは一般ユーザーよりはるかに早くこの障害モードに突き当たり、そうではないのにドライブが摩耗していると思い込むことが多い。

自分の仕事がそれに当てはまるなら、Trimを通すことを検証済みのドライブを使うか、プロジェクトの合間に再フォーマットのサイクルを予定に入れるかのどちらかにすること。2台のドライブをローテーションし、吸い出し後にそれぞれを再フォーマットするのは妥当な運用パターンであり、コストはプロジェクトごとに消去1回である。

エンクロージャを意図をもって選ぶ

診断ではなく予防として繰り返す価値がある。これを決めるのはエンクロージャであって、中のSSDモジュールでも箱に書かれたブランドでもない。ワークロードがそれに見合うならThunderboltまたはネイティブNVMeを選び、何を選んだにせよ最初の1週間でテストすること。

時々再テストする

マウント時ログの確認は2分で終わる。重要な外付けドライブに対して年に一度、あるいはmacOSのメジャーアップグレードのあとに実行しておけば、遅い転送に1か月を費やす前に挙動の変化を捕まえられる。結果はどこかに記録しておくこと。あるドライブが3月にはクリーンだったと分かっていることは、12月に有用な文脈になる。

Time Machineの保存先と起動可能なクローン

Time Machineが最悪のケースである理由

Time Machineの保存先は、Trimにとってほぼ最大ストレスのシナリオだ。設計上、容量いっぱいに向けて満たされていき、そのあと場所を空けるために最も古いスナップショットの削除を始め、そして回収された領域にまた書き込む、というループを永久に続ける。これは大量削除に続く大量書き込みの連続サイクルであり、まさに速さを保つためにTrimに依存するパターンである。

Trimを受け取っていないSSDの保存先では、バックアップは数か月かけてどんどん遅くなる。報告される症状は、以前は数分で終わっていたTime Machineのバックアップが何時間も走るようになる、あるいは「バックアップを準備中」の段階や書き込み中に止まったように見える、というものだ。Time Machineのせいにしたくなるし、Time Machineには別途切り分ける価値のある本物の問題も数多くある。それらはTime Machineトラブルシューティングガイドで詳しく扱っている。しかし、保存先がSSDで、そこからの読み込みは依然として速いのに書き込みが這うようであれば、Time Machineの設定に午後をまるごと費やす前にTrimを疑うべきだ。

厄介なのは、Time Machineの保存先を消去するとバックアップ履歴が失われる点だ。ドライブを再フォーマットしつつスナップショットを保つ方法はない。選択肢は、履歴の喪失を受け入れて新しいバックアップを始めるか、別のドライブに新しい保存先を用意し、新しいバックアップが確立したら古いほうを引退させるかである。多くの人にとっては後者がドライブ1台のコストに見合う。履歴のないバックアップは、何か月ぶんものバージョンを持つバックアップよりはるかに役に立たないからだ。

バックアップに限ったハードウェア選択について一言。これは、従来型のハードディスクが悪い答えではない数少ないケースだ。回転式ディスクには消去ブロックの問題がなく、Trimの要件もまったくない。スペック上は遅いが、夜間の増分バックアップではそれが無関係であることは多く、しかも何年もの書き込みと削除のサイクルを経ても挙動が劣化しない。

起動可能なクローンと外付け起動ボリューム

起動可能なクローンも同様の挙動を示す。クローンソフトは実行のたびに大量のデータを書き直すので、保存先がTrimされていなければクローンの所要時間は着実に伸びていく。ここでの利点は、クローン先が頻繁にマウントとアンマウントを繰り返されることで、マウント時のログエントリを作るのがきわめて簡単だという点だ。取り出し、再接続、ログを読む。1分もかからない。

復旧ツールとしてではなく日常の環境として外付けドライブからmacOSを起動しているなら、賭け金は高くなる。システムのあらゆる書き込みが同じ劣化した経路を通るからだ。起動ドライブについては特に、USBケースよりThunderbolt NVMeエンクロージャを選ぶ強い論拠になる。

よくある問題のトラブルシューティング

ログの確認がまったく何も返さない

問題: ドライブは接続されているのに、APFSの述語を付けて log show を実行しても行が1つも返らない。

解決策: ほぼ確実に、先にマウントイベントを作らずにログを読んだか、読むのが遅すぎたかである。エントリはボリュームがマウントされたときにしか書かれない。ドライブを取り出し、物理的に接続を外し、date で時刻を控え、再接続し、ボリュームがFinderに現れるまで15秒待ち、それからはじめて log show --last 2m を実行すること。それでも空なら、レベルフィルタを広げるために --info、続いて --debug を追加する。それでも空で、しかもドライブが実際にマウントされたのなら、そのドライブが本当にAPFSかどうかを確認する。exFATのドライブはスキャンすべきAPFSコンテナが存在しないため、APFSのエントリを一切生成しない。

system_profiler SPSerialATADataType が何も出力しない

問題: どのサイトも勧めるTrim確認コマンドが何も出力せず、それがTrimオフを意味するのか判断できない。

解決策: どちらの意味でもない。Apple silicon Macではそのデータタイプが存在しない。system_profiler -listDataTypes | grep -i sata で確認でき、こちらも何も返らない。内蔵ドライブとNVMeドライブには system_profiler SPNVMeDataType を、それ以外にはマウント時ログの方法を使うこと。これらのマシンでは、空のSATA結果に意味のある解釈は存在しない。

sudo trimforce enable を実行したが何も変わらなかった

問題: trimforceを有効にし、指示どおり再起動したのに、外付けドライブは以前とまったく同じ遅さのままだ。

解決策: それが期待どおりの結果である。trimforce はマニュアルページ自身が述べるとおりAHCI（SATA）コントローラに接続されたサードパーティ製ドライブに作用するのであり、あなたのUSBまたはNVMeの外付けはそれに当たらない。実行しても何も壊れていないし、何も直っていない。確認したければ自分で man trimforce を実行してDESCRIPTIONを読むこと。実際に何が起きているのかを知るには、マウント時ログの確認に進む。

ドライブが TRIM Support: Yes と表示されるのに書き込みが遅いまま

問題: system_profiler SPNVMeDataType はそのドライブについてTrimサポートを報告しているのに、書き込み性能が悪い。

解決策: Trimサポートが報告されているのは、ドライブと経路がその能力を広告しているという意味だ。このボリュームで実際にTrimが行われていることの確認にはならず、それを測るのがマウント時ログの確認である。次はそれを実行すること。あわせてTrim以外の原因も排除する。System Informationでネゴシエートされたリンク速度を確認し、ケーブルを交換し、別のポートでテストし、3分間の持続転送を実行して、ブロック枯渇ではなくキャッシュ枯渇やサーマルスロットリングを見ているのではないか確かめる。

最初の30秒は速いのにその後崩れる

問題: 大きなコピーがフルスピードで始まり、途中で毎回70%以上落ちる。

解決策: これは通常、Trimの問題ではなくSLC書き込みキャッシュが埋まっている現象で、コンシューマ向けドライブでは正常な挙動だ。ただしTrimに飢えたドライブでは、落ちたあとの下限がより低くなる。両者を区別するには、ドライブに電源を入れたままアイドル時間を置いてからテストする。キャッシュ由来の減速はドライブがフラッシュする時間を得ると回復するが、Trimの飢餓は回復しない。エンクロージャの温度も確認すること。熱くなったブリッジチップやNVMeモジュールは激しくスロットリングし、外からは同じに感じられる。

小さいファイルは遅いが大きいファイルは速い

問題: 数千個の小さなファイルが入ったフォルダのコピーが、同じ合計サイズの単一ファイルのコピーよりはるかに時間がかかる。

解決策: Trimの問題ではない。小さなファイルの転送ではファイルごとのオーバーヘッドが支配的になり、Spotlightのインデックス作成やセキュリティソフトが着地するたびに各ファイルをスキャンすることで劇的に悪化する。きれいなスループットの数字を得るには単一の大きなファイルでテストすること。大きなファイルの書き込みが正常なら、フラッシュは問題ない。小さなファイルのペナルティを減らすには、システム設定 → SiriとSpotlight → SpotlightのプライバシーでそのドライブをSpotlightの対象から除外するか、フォルダを単一のアーカイブとして転送することを検討する。

消去で直ったが、数か月しかもたなかった

問題: 再フォーマットでフルスピードが戻ったのに、数か月後、同じ曲線で書き込みがまた劣化した。

解決策: その再フォーマットは症状を処置したにすぎない。再発は、Trimが本当にこのドライブに届いていないことを意味する。書き込みと削除の履歴を再構築した途端に、ブロックのプールがまた飢えるのだ。再フォーマットしたドライブでマウント時ログの確認を行い、(no trims) を探して裏を取ること。確認できたなら、現実的な選択肢は、定期的な再フォーマットをメンテナンスとして受け入れるか、SSDモジュールをThunderboltまたはNVMeのエンクロージャに移してその経路をテストするかである。結果を変えられるソフトウェア設定は存在しない。

ドライブがランダムに切断もされる

問題: 書き込みの遅さに加えて、ドライブが勝手に取り出される、あるいは「ディスクの取り出しエラー」の通知が繰り返し出る。

解決策: これらは別々の障害として扱い、まず切断のほうを直すこと。不安定な接続はあらゆる測定を信用できないものにし、書き込み中にボリュームを破損させることもある。切断は通常、フラッシュの問題ではなく電力やバスの問題だ。ハブにつないだバスパワー駆動のドライブ、エンクロージャの積極的なスリープ、あるいはぎりぎりの品質のケーブルなどである。「ディスクの取り出しエラー」とUSB電力のガイドで具体的な原因を扱っている。ドライブが安定して接続され続けるようになったら、戻ってきて比率テストをやり直すこと。

FAQ

sudo trimforce enable はUSB外付けSSDに効きますか？

いいえ。マニュアルページには、AHCIコントローラに接続されたサードパーティ製ドライブに対してTrimを有効にすると書かれており、AHCIとはSATAインターフェイスのことです。USB外付けドライブはUSBブリッジを経由してMacに届いていますし、NVMeドライブもAHCIではありません。このコマンドが当てはまるのは、古いMacの内部に取り付けられたサードパーティ製SATA SSDだけで、それ以外には何も当てはまりません。

なぜ私のMacでは system_profiler SPSerialATADataType が何も返さないのですか？

Apple silicon MacにはSATAコントローラがないため、そのデータタイプが存在しないからです。system_profiler -listDataTypes | grep -i sata で自分で確認できます。一致するものは返りません。空の出力はTrimが無効だという報告ではありません。ハードウェアのカテゴリ自体が存在しないということです。

Disk Utilityや diskutil でTrimの状態を確認できますか？

いいえ。diskutil info -all | grep -i trim は何も返しません。diskutil が報告するプロパティの中にTrimの状態が含まれておらず、Disk Utilityの情報パネルにも表示されないからです。そうでないかのように書いているガイドは、macOSが提供していないものを説明しています。代わりに system_profiler SPNVMeDataType またはマウント時ログの確認を使ってください。

Trimの問題とケーブル不良はどう見分けますか？

同じドライブで同じセッション中に、8 GB以上のファイル1つを使って読み込み速度と書き込み速度を比較してください。ケーブルやポートの問題は双方向を同程度の割合で遅くします。Trimの問題は読み込みをフルスピードのまま残し、書き込みだけを崩壊させます。Howard Oakley氏の閾値は、書き込みが読み込みの20%以下、です。

ドライブを消去すれば書き込みの遅さは恒久的に直りますか？

即座にフルスピードは回復します。消去によってフラッシュが、書き込みの前に消去サイクルを必要としない状態に戻るからです。それが持続するかどうかは、通常の使用中にTrimがそのドライブに届くかどうか次第です。届くなら問題は再発しないはずです。届かないなら、数か月以内に同じ劣化が起こると考えてください。

MacでSSDを外付けにするのに、exFATは本当にそれほど悪いのですか？

経時的なパフォーマンスに関しては、はい。exFATはドライブをTrimしないので、エンクロージャや接続方式にかかわらず、書き込み履歴が積み上がるにつれてexFATのSSDは必ず劣化します。exFATを選ぶのは、Windowsのネイティブアクセスが本当に必要なときだけにしてください。そしてその場合は、ドライブの使用量を容量に対して十分低く保ち、定期的に再フォーマットすることです。

まとめ

読み込みはフルスピードなのに書き込みが遅い外付けSSDは、コマンドを1つ実行する前から、何が悪いのかをあなたに伝えている。その非対称性は、消去済みブロックを使い果たし、どのブロックを回収してよいのかを教えてもらえていないドライブの指紋である。

これの診断が難しい理由は、メカニズムが微妙だからではない。インターネットが合意した2つの確認方法が、どちらも現代のMacで静かに失敗するからだ。system_profiler SPSerialATADataType はApple siliconが持たないハードウェアのカテゴリに問い合わせ、空の結果を返す。sudo trimforce enable はAHCI接続のSATAドライブに対するポリシーを切り替えるもので、マニュアルページ自身が最初の段落で述べているとおり、USB外付けには手を出せない。どちらもエラーを報告しない。その沈黙こそが、誤った助言を循環させ続けているものであり、私たち自身も以前のガイドでそれを繰り返してしまった理由でもある。

機能するものはもっと限られている。内蔵ドライブとNVMe外付けについては、system_profiler SPNVMeDataType が TRIM Support を直接報告する。APFSでフォーマットされたものについては、ドライブを取り出し、時刻を控え、再接続し、マウントを待ち、統合ログの spaceman_scan_free_blocks エントリを読んで (no trims) マーカーを探す。この順番で、遅延なく行うこと。それらのエントリはマウント時にしか書かれず、ほかのどこにも書かれないからだ。3週間の稼働時間があった私たちの検証マシンでは、まる1週間のログにそれらは1件も含まれていなかった。

確認結果が悪ければ、治療法は完全な消去と再フォーマットであり、それを代替できるユーザー向けコマンドは存在しない。その修正が持続するかはエンクロージャ次第であり、Appleが外付けエンクロージャのTrim互換性リストを公開していない以上、知る唯一の方法は、再フォーマットし、数か月使い、もう一度測ることである。同じ曲線で劣化するなら、エンクロージャがコマンドを捨てているのであり、持続的な答えはソフトウェアで変えられる何かではなく、ThunderboltまたはネイティブNVMeの経路である。

今週、3つのことをしてほしい。メインの外付けドライブで、大きなファイル1つを両方向にコピーする比率テストを実行する。比率がおかしければ、ドライブがまだ劣化した状態にあるうちにマウント時ログの確認を実行する。単に直すだけでなく、何かを学べるように。そしてMac専用の外付けドライブはexFATではなくAPFSでフォーマットする。その一つの決断が、そもそもTrimが試みられるかどうかを決めるからだ。

関連記事: macOS外付けSSDトラブルシューティングガイド · Time Machine完全トラブルシューティングガイド