7.3.2.2.5. 維持されたメタデータ修正の最適化

維持されたメタデータ修正の達成可能レベルを決定する際の主な要素は、ログのサイズです。ログデバイスは円形なので、末尾が上書きされる前にログ内の全修正がディスク上の実際の場所に書き込まれる必要があります。これには、すべてのダーティーメタデータを書き戻すためのかなりのシーキングを伴います。デフォルト設定では、ファイルシステム全体のサイズとの関係でログサイズが拡張されるので、ほとんどの場合ではログサイズはチューニングが不要です。

小型のログデバイスだと、メタデータのライトバックが非常に頻繁に行われることになります。ログはスペースを解放するために常に末尾をプッシュし、このため修正されたメタデータが頻繁にディスクに書き込まれ、オペレーションが遅くなります。

ログサイズを大きくすると、末尾をプッシュするイベント間の期間が増大します。これによりダーティーメタデータがより効果的に統合され、メタデータのライトバックパターンが向上し、頻繁に修正されたメタデータのライトバックが少なくなります。代償としては、大きなログはメモリ内でそのままになっているすべての変更を追跡するためにより多くのメモリが必要となる、という点です。

マシンのメモリが限られている場合、大規模なログは便利ではありません。これは、大きいログの利点が活かされる前にメモリ制限によってメタデータの書き戻しが発生するためです。このようなケースでは、大きいログではなく小さいログの方がパフォーマンス向上につながります。これは、スペース不足となるログからのメタデータの書き戻しの方が、メモリ回復による書き戻しよりも効率的だからです。

ログは常に、ファイルシステムを格納しているデバイスの基礎的ストライプユニットに一致させるようにすべきです。mkfs はデフォルトでこれをMD および DM のデバイスで行いますが、ハードウェア RAID の場合は指定する必要があります。これを正確に設定することで、ディスクに修正を書き込む際にログ I/O が I/Oの不整列を引き起こし、読み取り・修正・書き込みの操作がその後に続く可能性を回避します。

マウントオプションを編集することでログオペレーションをさらに改善することができます。メモリ内のログバッファー (logbsize) を増やすと、ログに変更を書き込むスピードが高まります。デフォルトのログバッファーサイズは MAX (32 KB、ログストライプユニット) で、最大サイズは 256 KB です。一般的に値が大きいとパフォーマンス速度が高まります。しかし、fsync の多いワークロードでは、大型のストライプユニットの調整を使うと小さいログバッファーの方が明らかに大型バッファーよりも速くなります。

delaylog マウントオプションも、ログへの変更数を減らして維持されるメタデータの修正パフォーマンスを向上させます。これは、ログに変更を書き込む前にメモリ内の個別の変更を統合することで達成されます。頻繁に修正されるメタデータは、修正ごとにではなく、定期的にログに書き込まれます。このオプションはダーティーメタデータによるメモリ使用量を増やし、クラッシュ発生時のオペレーション損失の可能性を高めますが、メタデータ修正速度とスケーラビリティを 1 桁以上改善できます。fsync、fdatasync、sync のいずれかを使ってデータおよびメタデータのディスクへの書き込みを確認している場合は、このオプションの使用でデータまたはメタデータの整合性が低下することはありません。