systemdプロジェクトの開発者たちは、「systemd-journald」コンポーネントにおける長年のアーキテクチャ上の問題、すなわちディスクに書き込まれるデータ量（書き込み増幅）が実際のログ量よりも大幅に多くなってしまう問題について、調査と修正を開始しました。
この話は2020年3月に遡る。当時、バグ追跡システムに、約500KBのテキストログを生成するとSSD上で700MBを超える物理書き込み操作が発生するという報告が提出された。systemdの開発者たちはこの問題をきっぱりと否定し、「ファイルシステムの仕組みを理解していない」と反論し、プロファイリングの実施を拒否し、「対応不要」としてチケットをクローズした。開発者たちのコメントはユーザーから数百件の低評価を受けたが、プロジェクトの姿勢は揺るがなかった。
2026年初頭、2回目の問題報告が提出されました。その中で、独立系開発者のValdikSSは、分離されたcgroupおよびループデバイスを使用して詳細なプロファイリングを実施し、問題が発生するメカニズムを明確に示しました。メモリマップドファイル（mmap）とバイナリハッシュテーブルの使用により、750バイトのテキストメッセージを1つ書き込むだけでもメモリフィンガープリントが変更され、4キロバイトのページ全体がディスクにフラッシュされ、ブロックデバイスレベルで50～70KBのI/Oが発生します。
昨日のHacker Newsのトップページ記事と、反論の余地のない合成テストの公開を受けて、プロジェクトのメンテナーたちは発言を変え、journaldのキャッシュフラッシュメカニズムとインデックスストレージ構造の最適化に着手した。
出所： オープンネット.ru
