SSDがいっぱいになるとRAIDの書き込み速度が低下するのはなぜですか、またはTRIMが必要なのはなぜですか

この問題は、非工業用SSDを使用したハードウェアRAIDまたはファームウェアRAID（Intel RST RAID 1/10/5/6など）に最も関連しています。

SSD機能

SSDはページ内のデータの書き込みと読み取りを行い、クリアされたページにのみ書き込みができ、ページは大きなブロックでのみクリアできます。 たとえば、ディスクのページサイズは8 KBで、ブロックには128ページが含まれているため、ブロックサイズは1024 KBです（以降、特に指定のない限り、KBとMBはバイナリです）。



たとえば、1つのファイルで40 KBを変更すると、物理レベルでは次のようになります。







論理レベルでは、すべてが通常のように見えます-データは、対応するセクターの一番上に上書きされます。 ブロック1に空でページをクリアする準備ができたらすぐに、このブロックは消去され、完全に空になります。



物理的な実装を隠すために、ディスクは論理ページ番号と物理ページ番号に一致するマップをサポートしています（Flash Translation Layer）。



これまでのところ、新しいデータがその論理アドレスに書き込まれた場合、物理ページが再びクリアされる方法は1つしかありません。 実際には、ディスクコントローラーはページレベルで動作し、ファイルシステムについて何も知らず、オペレーティングシステムは削除されたファイルをディスクに通知せず、どのセクターをクリアできます。 遅かれ早かれ、ディスクの各ページがビジーになり、データを書き込む場所がなくなることがわかります。



この問題を解決するために、 ATA TRIM （ wiki ） コマンドが追加されました。 オペレーティングシステムは、クリア可能なセクターを示すディスクにそれを送信します。 このコマンドの類似物は、SCSI UNMAPおよびCF ERASEです。 残念ながら、場合によってはディスクに送信する方法がありません。

-ディスクがハードウェアコントローラー（ LSI 、 Adaptecなど）を備えたRAIDにある場合、

-ドライブがファームウェアRAID、特にIntel RST RAID 1/10/5/6にある場合、

-ディスクがUSB経由で接続されている場合（プロトコル制限）、

-ディスクがTrueCrypt、dm-crypt、GELIなどを使用してプログラムで暗号化されている場合 （サポートされる場合がありますが、通常はセキュリティ上の理由から含まれていません）。



テストの結果、ディスクがTRIMコマンドを受信しないことが判明した場合、すぐに記録用の空きページが非常に少なくなります。 しかし、それらは次のようになります。各ディスクには、空きページのリザーブおよび完全に使い古されたブロックのリザーブとして機能する予約領域が含まれます。 この領域のサイズを調べるには、ディスクにインストールされている物理メモリの量と、ドキュメントで示されているLBAの量を調べる必要があります。



たとえば、Samsung SSD 840 Pro 512 GBには512 GBのメモリがあり、1000215216 LBAセクターが使用可能です。 予備は、512×1024×1024×1024-1000215216×512 = 35 GBまたは6.85％です。 これに使用できるディスク容量は、（512-35）×1024×1024×1024 = 512×10 ^ 9 = 512 GB、すでに10進数です。 Samsung SSD 850 Pro 128 GBには129 GBのボードが搭載されており、ユーザーは128 GBの10進数を使用できます。予備-7.6％。



したがって、ディスク全体をいっぱいにしてからすべてのファイルを削除すると、TRIMサポートがなければ、ディスクはディスクボリュームの6.85％の一部にしか書き込みできません。 一部には、この予約ボリュームが、断片化のために部分的に完全に空ではないブロックで構成されるためです。 この領域が存在すると、ディスク上のファイルを何とか上書きし続けることができます。



悪い状況の例：占有ページのボリュームが予約なしでユーザーが利用できる量を超えていないにもかかわらず、書き込む場所がありません。







この場合、ガベージコレクターは書き込みと同時に動作し、ブロックをRAMに読み取り、ディスク上のブロックを消去し（長い操作、消去は空白ページへの書き込み900μsと比較して3000μsかかります）、メインメモリからブロックを書き込みます。 遅延は、 書き込み増幅 -論理書き込み操作ごとに5〜10の物理書き込み操作の増加によるものです。



したがって、操作用のディスクスペースが多いほど、書き込み速度は速くなります。 バックグラウンドのガベージコレクターは、ブロックのクリーニングとデフラグだけでなく、ブロック全体の書き込み/クリーン（P / E）サイクルの均等な分配にも関与しているため、同じように摩耗します。



現代のドライブには、TRIMを必要としない優れたガベージコレクターがあるという神話があります。 これは完全に間違っています。ガベージコレクターとTRIMは異なる動作をします。



産業用ドライブには多くの場合、50％以上のスペア領域があるため、TRIMの欠如は重要ではありません。 残りのディスクには、ほとんどの場合、明示的に宣言されたスペア領域がまったくないか、不十分です。 テストでは、物理メモリ全体（リザーブ領域を含む）の25〜29％のオーバープロビジョニングボリュームが良い影響を与えることが示されています。 したがって、ディスクの予約スペースが不十分な場合は、自分でオーバープロビジョニングを行う必要があります。



3つの方法があります。

-RAIDの作成後、未割り当て領域の一部を残すようにディスクをマークします。

-RAIDを作成する前に、ATAコマンドを使用してホスト保護領域 （ howto ）を作成します。

-ディスク容量の一部のみを使用するようにRAIDコントローラーを構成します。







空き領域を選択する前に、次の2つの方法のいずれかで、この領域が何も使用されていないことをディスクに知らせる必要があります。

-ディスクを別のコントローラーに接続し、ATA TRIMコマンドを送信します （またはO＆O Defragを使用します-cliインターフェイス、Windows 8組み込みディスクオプティマイザーまたはAnvil's Storage Utilitiesがあります）。

-ATA Secure Eraseコマンドを送信して、FTLテーブルを完全にクリーンアップします。



0x00または0xFFを書き込むと、ブロックが使用されていないことをディスクに認識させるバージョンもあります（いわゆる「Tony TRIM」メソッド）。 おそらく一部のコントローラーではこれは機能しますが、私のテストでは変更はありませんでした。

実際に

Windows 8.1がインストールされているIntel RST RAID 1に2台のSamsung SSD 540 Pro 512 GBドライブがあります。 1年間の仕事の後、パフォーマンスを測定しましたが、不快な驚きを覚えました。 TRIMを確認したところ、動作していないことがわかりました。



-WindowsでのTRIMチェック

-LinuxでのTRIMチェック：

# lsblk -D
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

関連するすべてのコンポーネントについて、DISC-GRAN列とDISC-MAX列は両方とも0より大きい必要があります。



代替オプション：

 # dd if=/dev/urandom of=tempfile bs=1M count=3 # hdparm --fibmap tempfile # hdparm --read-sector [ADDRESS] /dev/sda # rm tempfile && sync && sleep 120 # hdparm --read-sector [ADDRESS] /dev/sda
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ファイルを削除した後、ディスクは0x00または0xFFである必要がありますが、これは信頼できない方法です。異なるディスクは異なる動作をします。



リアルタイムTRIMは、ディスクをマウントするときに「破棄」オプションによって有効になります。

 # grep -i discard /etc/fstab # mount | grep -i discard
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

シングルディスクおよびLVMファイルシステムのTRIMは、Linux 2.6.33カーネルからサポートされています。 mdraidのTRIMは、Linuxカーネル3.7からサポートされています 。 ただし、CentOS 6でサポートされているように、古いカーネルバージョンに移植することもできます。



デフォルトでは、Ubuntuはfstrimを使用して週に1回定期的にTRIMを実行しますが、Intel、Samsung、OCZ、SanDisk、Patriot、および「hdparm」がインストールされている場合、



-FreeBSDのTRIMチェック：

ZFS は 、FreeBSD 9.2以降、デフォルトでTRIMをサポートしています。

 # sysctl -a | grep -i 'zfs.*trim'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

GEOM RAID gmirror は 、FreeBSD 9.1でTRIMをサポートしています。

 gstat -d
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

d / s列はBIO_DELETE /秒です。



Intel RST RAIDは、例外として、タイプRAID 1に対してのみTRIMをサポートします。有効にするには、Intel RSTドライバーがバージョン11以上であり、OROM（レガシーブート）またはSataDriver（UEFIブート）バージョン11以上のファームウェア、または古いバージョンであることを確認する必要があります。しかし、 パッチを適用しました 。 TRIMは、バージョン3.7.0.1093以降のIntel RSTe RAID 0/1/10でサポートされています。



オーバープロビジョニング用に未割り当てのディスクパーティションを作成することにしました。

1. Acronis Backupを使用して、ディスクイメージを取得しました。 パーティションテーブルも保存しました（最初のセクター、最後のセクター、セクションのGPTタイプ、GPT一意の識別子、セクション名を持つことが重要です）。



2. BIOSを再起動し、SSDの完全消去を行いました。 この項目がBIOSにない場合は、 hdparam （またはこことここではWindowsの下にあります）、 HDDEraseまたはHDAT2を使用してコマンドを実行できます。



3. 2つのディスクでRAID 1を収集しました。



ここで重要なポイント：アレイの初期化中に、RAIDコントローラーは1つのディスクから各セクターを読み取り、2番目のディスクに書き込みます。 理論的には、これにより事業全体が妨げられ 、1つのドライブで過剰なプロビジョニングが発生することはありません。 しかし、テストでは、何らかの理由でこの方法が機能することが示されています。 これについては説明がありません。



4. LiveCDから起動し、 GPT fdiskを使用して目的のパーティションテーブルを作成しました。最後のパーティションは以前より104 GB少なくなりました。 パーティションは、ブロックのサイズではなく、ディスクページのサイズで整列（パーティション整列）する必要があります。



5.バックアップから各セクションを復元しました。



その後、ディスクを完全に満たし、テストを実行しました。 これは最悪の場合を示しているはずです。 Windowsキャッシュがオンになり、通常のキャッシュ書き込みがオフになり、Inter RSTライトバックがオフになり、すべてのテストで40 GBの固定サイズのドライブ領域が使用されます。 パフォーマンスは時間の経過とともに変化する可能性があるため、ドライブのテストは簡単ではありません。 以下は定常状態の指標です。



3つの状態を比較します。

-RAIDなしのドライブ1台、フル装備、6.58％標準の隠しスペアエリア。

-TRIM空きスペースを実行した後、RAIDなしの1つのドライブ。

-RAID 1の2台のディスク、満杯、6.58％標準の隠しスペアエリア。

-RAID 1の2台のディスク、完全にいっぱい、27.24％のオーバープロビジョニング（非表示のスペア領域を含む）。









結果の分析：

-RAID 1からの読み取りは、ファームウェアRAIDしかないという事実にもかかわらず、単一のディスクからの読み取りよりも高速です。

-記録はより速く、より多くの未割り当て領域があります。最初はTRIM、2番目は自家製のオーバープロビジョニングです。



定常状態は常に迅速に達成されるとは限りません。 ダイナミクスの最後の構成（27.24％のオーバープロビジョニング）のテストと最悪のケースを見てみましょう。











好奇心が強いプロセスは最初の400秒間続き、その後、生産性が向上して安定します。 ガベージコレクターは記録と並行して動作し、ブロックを最適化して記録のために準備すると考えています。 この動作は毎回ではなく、時々観察されます。 順次書き込みは最大70 MB /秒、ランダム記録は最大18,000 IOPSであることがわかります。 これらの数値は、オーバープロビジョニングなしの場合の2倍です（それぞれ32 MB / sおよび7139 IOPS）。 定常状態が実際に非常に高いパフォーマンスを発揮することを確認するために、平均69,721 IOPSで490 GBのディスクに書き込まれたテストを30分で実行しました。



結果を同僚と比較し、最適なオーバープロビジョニングサイズを選択できます。

• 最新のSSDのスペアエリアとパフォーマンスの一貫性の関係を探る 。
• パフォーマンスの一貫性 。
• サムスン850 PRO 512GBパフォーマンス 。

簡単に

-ディスクがOSからATA TRIMを受け取った場合、心配することはありません。ディスクスペースの一部を空けておけば十分です。

-高価な産業用ディスクを使用している場合は、内蔵スペアエリアのボリュームを確認し、十分であれば、録音に問題はありません。

-その他の場合は、マークされていない領域を残す必要があります。そのサイズが大きいほど、記録レイテンシの標準偏差は小さくなります。

-ガベージコレクターにクリーンブロックを準備する時間がなく、書き込み速度が低下して不安定になることがあります。

-オーバープロビジョニング後、確立された最大書き込み速度は7000 IOPSから68000 IOPSに増加し、平均最小値は6000 IOPSから19000 IOPSに増加しました。