web-dev-qa-db-ja.com

pdflush、kjournald、swapなどはどのように相互運用しますか？

最近、この考えを引き起こした質問がありました。ここまたはGoogleマシンを介して本当に答えを見つけることができませんでした。基本的に、私はカーネルI/Oアーキテクチャがどのように階層化されているかを知りたいと思っています。たとえば、kjournaldはpdflushにディスパッチしますか？私の想定では、pdflush（大容量ストレージI/Oより一般的）はより低いレベルにあり、SCSI/ATA /実際に書き込みを実行するために必要なコマンドをトリガーし、kjournaldは書き込み前に高レベルのファイルシステムデータ構造を処理します。ただし、逆の方法でも同じことがわかります。kjournaldがファイルシステムのデータ構造と直接やり取りし、pdflushが目を覚まし、kjournaldを介してダーティページキャッシュページをデバイスに書き込みます。また、他の何らかの理由で2つがまったく相互作用しない可能性もあります。

基本的に： Linuxカーネル内の大容量ストレージにI/Oをディスパッチするために使用される基本的なアーキテクチャを視覚化（グラフまたは単なる説明）する方法が必要です。

linuxkernelstoragekjournald
17
Bratchley

pdflush、_kjournald, and_ kswapd`の詳細について説明する前に、Linuxカーネルに関して正確に何を話しているかについて、その背景について少し説明しましょう。

GNU/Linuxアーキテクチャー

GNU/Linuxのアーキテクチャは2つのスペースと考えることができます：

  • ユーザー
  • カーネル

User SpaceとKernel Spaceの間にGNU Cライブラリ（glibc）これは、カーネルをユーザー空間アプリケーションに接続するシステムコールインターフェイスを提供します。

カーネルスペースは、さらに3つのレベルに分割できます。

  • システムコールインターフェース
  • アーキテクチャに依存しないカーネルコード
  • 建築依存コード

システムコールインターフェイスその名前が示すとおり、glibcとカーネル間のインターフェイスを提供します。 アーキテクチャに依存しないカーネルコードは、VFS（仮想ファイルシステム）やVMM（仮想メモリ管理）などの論理ユニットで構成されています。 アーキテクチャ依存コードは、特定のハードウェアアーキテクチャのプロセッサおよびプラットフォーム固有のコードであるコンポーネントです。

GNU/Linuxアーキテクチャの図

ss of gnu/linux Arch.

この記事の残りの部分では、カーネルスペース内のVFSおよびVMM論理ユニットに焦点を当てます。

GNU/Linuxカーネルのサブシステム

ss of kernel com

VFSサブシステム

GNU/Linuxカーネルがどのように構造化されているかについての高水準の概念を使用して、VFSサブシステムについてもう少し深く掘り下げることができます。このコンポーネントは、物理デバイス（HDDなど）上のファイルシステム（ext3/ext4など）に最終的にマッピングされるさまざまなブロックストレージデバイスへのアクセスを提供する役割を果たします。

VFSの図

ss of vfs

この図は、ユーザーのプロセスからのwrite()がVFSを通過し、最終的にデバイスドライバーに到達して、物理ストレージメディアに書き込まれる方法を示しています。ここがpdflushに遭遇する最初の場所です。これは、ダーティデータとメタデータバッファーブロックをバックグラウンドでストレージメディアにフラッシュするデーモンです。図にはこれは示されていませんが、kjournaldに沿って別のデーモンpdflushがあり、ダーティジャーナルブロックをディスクに書き込む同様のタスクを実行しています。 注：ジャーナルブロックは、ext4やJFSなどのファイルシステムが、変更が行われる前に、ファイル内のディスクへの変更を追跡する方法です。

上記の詳細は この論文 でさらに議論されています。

write()ステップの概要

I/O sybsystemオペレーションの簡単な概要を提供するために、関数write()がユーザースペースアプリケーションによって呼び出される例を使用します。

  1. プロセスは、write()システムコールを通じてファイルへの書き込みを要求します。
  2. カーネルは、ファイルにマップされたページキャッシュを更新します。
  3. Pdflushカーネルスレッドは、ページキャッシュをディスクにフラッシュします。
  4. ファイルシステムレイヤーは、各ブロックバッファーを_bio struct_（ 23ページの1.4.3、「ブロックレイヤー」を参照 ）にまとめ、ブロックデバイスレイヤーに書き込み要求を送信します。
  5. ブロックデバイスレイヤーは、上位レイヤーから要求を取得し、I/Oエレベーター操作を実行して、要求をI/O要求キューに入れます。
  6. SCSIやその他のデバイス固有のドライバーなどのデバイスドライバーが書き込み操作を処理します。
  7. ディスクデバイスファームウェアは、シークヘッド、回転、プラッター上のセクターへのデータ転送などのハードウェア操作を実行します。

VMMサブシステム

さらに深く掘り下げて、今度はVMMサブシステムを調べることができます。このコンポーネントは、メインメモリ（RAM）、スワップ、および物理ストレージメディア間の一貫性を維持する役割を果たします。一貫性を維持するための主要なメカニズムはbdflushです。メモリのページはダーティと見なされるため、ストレージメディアにあるデータと同期する必要があります。 bdflushはpdflushデーモンと連携して、このデータをストレージメディアと同期します。

VMMの図

ss of VMM

スワップ

システムメモリが不足するか、カーネルスワップタイマーが期限切れになると、kswapdデーモンがページを解放しようとします。空きページ数が_free_pages_high_を超えている限り、kswapdは何もしません。ただし、空きページ数が下回ると、kswapdはページ再利用プロセスを開始します。 kswapdがページに再配置のマークを付けた後、bdflushは、pdflushデーモンを介して、ストレージメディアへの未処理の変更を同期するように注意します。

参考文献と参考文献

21
slm