hX1P8B

Linux/OSS Support Center, IBM Japan 

Linux カーネルのブロックデバイス・ 

I/O サブシステム( 入門編 ) 

Version 1.2 

Linux/OSS Support Center 

Linux カーネルのブロックデバイス・ 


2009/11/6 

© 2009 IBM Corporation


はじめに 

• この資料の内容に関しては正式な IBM のテストを受けておりません。この資料は、資料作成時に 

おける最新情報をご参考のために提供することを目的として記載されており、IBM は、情報の正確 

性、完全性または有用性について何ら保証するものではありません。また、内容は予告なしに変更 

または更新されることがあります。 

• この資料の内容は、限られた検証環境における結果に基づくものであり、全ての環境で同一の結 

果を保証するものではありません。お客様固有の環境に対し、適切であるかどうか、また、正確で 

あるかどうかは十分検証されていません。この資料の情報に基づき導入・設定を実施される場合に 

は、十分な検証テストを行ってください。また、予め各社より提供される情報および製品のマニュア 

ルをご覧ください。 

• この資料の情報に基づいて導入・設定・運用した結果について、IBM はいかなる保証も責任も負い 

かねますので予めご了承ください。 

2 Linux カーネルのブロックデバイス・ 




前提 

• このドキュメントでは、Linux カーネルのブロックデバイス I/O サブシステムについて解説していま 

す。 

► Linux カーネルは、キャラクターデバイスとブロックデバイスの 2 種類のデバイスを区別して取り扱います。 

このドキュメントは、ブロックデバイスのみを対象としていますので、ブロックデバイス I/O サブシステムのこ 

とを、単に I/O サブシステムと表現しています。 

► 一般に、テープデバイスなどのシーケンシャルアクセスのみを提供するデバイスがキャラクターデバイス、 

ハードディスクなどのランダムアクセスが可能なデバイスがブロックデバイスに分類されます。 

• このドキュメントは、読者の理解を助けるために、あえて厳密ではない表現をしている箇所があり 

ます。また、Linux カーネルの内部仕様は、カーネルバージョン、適用パッチ、および、コンパイル 

時の設定により変化します。このドキュメントの内容は、あくまで、一般的な参考情報としてご理解 

ください。 

• I/O サブシステムの実装は、カーネル 2.4 とカーネル 2.6 で大きく変化しています。このドキュメン 

トでは、カーネル 2.6 および IA32 アーキテクチャーを前提としています。 





目次 

• I/O サブシステムの構造 

• VFS (Virtual Filesystem) 

• ディスクキャッシュ 

• ブロックレイヤー 

• I/O リクエストの発行 

• 参考資料 





I/O サブシステムの構造 





I/O サブシステムの構造 (1) 

• Linux の I/O サブシステムは VFS (Virtual Filesystem) とブロックレイヤーに分かれます。 

► VFS は、ユーザープロセスとメモリー上のディスクキャッシュの間のデータ転送を行います。 

► ブロックレイヤーは、ディスクキャッシュと物理デバイスの間のデータ転送を行います。 

ユーザープロセス 

システムコール 

ブロックレイヤー 

リクエストキュー 

リクエストキュー 

VFS 

I/O スケジューラー 


ファイルシステム 

address_space 

_operations 

デバイスドライバー 

file_operations 

ディスクキャッシュ 

データ転送 

物理デバイス 






I/O サブシステムの構造 (2) 

• VFS (Virtual Filesystem) 

► ユーザープロセスにブロックデバイスを利用するための、統一的なインターフェースを提供します。 

– デバイスに格納されたデータを、デバイスやファイルシステムの種類によらず、ツリー構造のディレクトリ内のファイルとし 

て見せます。 

– open(), read(), write(), close() などのシステムコールを通じて、各ファイルへのアクセスを提供します。 

► VFS に登録された各ファイルシステムは、データアクセスに必要な関数群である、file_operations テーブル 

と address_space_operations テーブルを提供します。 

– file_operations テーブルは、メモリー上のディスクキャッシュにデータを読み書きするための関数群です。 

– address_space_operations テーブルは、ブロックレイヤーのリクエストキューに、物理デバイスとディスクキャッシュの 

データ転送を依頼するリクエストを登録するための関数群です。 

• ブロックレイヤー 

► 各物理デバイスは、それぞれ独立したリクエストキューを持ちます。各リクエストキューの I/O スケジューラー 

が、キューに登録されたリクエストに基づいて、物理デバイスとディスクキャッシュの間のデータ転送を行いま 

す。 

– 各リクエストキューの I/O スケジューラーは、物理デバイスの特性に応じて、異なったスケジューリングポリシーを持つこと 

が可能です。 

► デバイスドライバーは、物理デバイスにアクセスするために必要な関数を I/O スケジューラーに提供します。 

– SCSI デバイスの場合、デバイスドライバー自身も、上位モジュール(sd_mod)、中間モジュール(scsi_mod)、下位モ 

ジュール(ホストアダプター用ドライバー)からなるレイヤー構造となっています。 





ファイルの Read 処理の流れ 

• VFS の処理とブロックレイヤーの処理は、非同期に実行されます。 

• ファイルの read 処理は以下の流れになります。 

► ユーザープロセスはシステムコールにより、read 要求を発行します。 

► VFS はディスクキャッシュに該当データが存在するか確認します。 (*) 

– ディスクキャッシュに該当データが存在する場合、データをユーザープロセスに返して、処理を終了します。 

► ディスクキャッシュに該当データが存在しない場合、リクエストキューに read 要求を登録して、要求を発行し 

たユーザープロセスを、一旦 sleep 状態にします。 

– 具体的には、該当するディスクキャッシュのメモリー領域を Lock し、Lock が解除されるまで sleep します。 

► リクエストキューの I/O スケジューラーは、リクエストに応じて、物理デバイスからディスクキャッシュへのデー 

タ転送をデバイスドライバーを通じて行います。 

► ディスクキャッシュへのデータ転送が完了すると、I/O スケジューラーは、該当するディスクキャッシュのメモ 

リー領域の Lock を解除します。 

– この時、Lock 解除待ちで sleep していたユーザープロセスが再び起動し、VFS はディスクキャッシュ上のデータをユー 

ザープロセスに返して、処理を終了します。 

(*) Linux カーネルはファイルの先読み機能を持っており、これが有効な場合は、ディスクキャッシュ上の該当データを検索する 

前に、要求されている範囲よりも先の部分を含めたファイルの物理 read 処理 ( 物理デバイスからディスクキャッシュへのデータ 

転送 )を行います。ここでは、ファイルの先読み機能は考慮していません。 





ファイルの Write 処理の流れ 

• ファイルの write 処理は以下の流れになります。 

► ユーザープロセスはシステムコールにより、write 要求を発行します。 

► VFS はディスクキャッシュに該当データを書き込みます。 

► ディスクキャッシュの使用状況から物理デバイスへのデータ転送 ( 書き込み)が必要か判断し、必要に応じて、 

カーネルスレッド pdflush を起動します。 

– pdflush を起動する条件は p.35 『pdflush について』を参照。 

– ユーザープロセス側の処理は、ここで終了します。 

► カーネルスレッド pdflush が、リクエストキューに write 要求を登録します。 

► リクエストキューの I/O スケジューラーは、リクエストに応じて、ディスクキャッシュから物理デバイスへのデー 

タ転送をデバイスドライバーを通じて行います。 





VFS 

(Virtual Filesystem) 





ファイルシステムの管理オブジェクト 

• ext2, ext3, vfat, iso9660 など、構造の異なるファイルシステムを統一的に扱うため、ファイルシス 

テムの種類によらず、下記の 4 種類のデータでファイルを管理します。 (*) 

► スーパーブロックオブジェクト 

– マウント中のファイルシステム全体の構成に関する情報を保持します。マウント中の 1 つのファイルシステムにつき、1 つ 

のスーパーブロックオブジェクトが存在します。 

– スーパーブロックオブジェクトに格納されるデータの種類は事前に定義されていますが、具体的なデータの内容や設定方 

法は、ファイルシステムによって異なります。 

► inode オブジェクト 

– ディスク上の個々のファイル、および、ディレクトリの管理情報を保持します。1 つのファイル(もしくはディレクトリ)につき、 

1 つの inode オブジェクトが対応します。 

– ファイルシステムのマウント時に全てのファイルの inode オブジェクトを作成するのではなく、ディスク上のファイルにアク 

セスしたタイミングで、そのファイルに対する inode オブジェクトを作成します。 

► file オブジェクト 

– オープン中のファイルの管理情報を保持します。 

– 同一のファイルを複数のプロセスがオープンした場合、同一のファイルに対して、複数の file オブジェクトが作成されます。 

► dentry オブジェクト 

– ファイルの存在するディレクトリパス名から対応するファイルの inode オブジェクトをポイントするオブジェクトです。 

– ディレクトリパス名でファイルが指定されたときに、対応する inode オブジェクトをすばやく検索するために利用します。 

(*) これらの『オブジェクト』は、カーネルメモリー上の変数に格納されるデータであり、ext2/ext3 ファイルシステムの 

( 物理ディスク上に存在する)スーパーブロック、および、inode とは異なる概念です。 





ファイルシステム固有の情報 

• カーネルが利用可能なファイルシステムは、file_system_type オブジェクトに登録されています。 

► 各ファイルシステムを使用するためのカーネルモジュールをロードした時に、該当ファイルシステムの情報を 

持つ file_system_type オブジェクトが作成されます。 

► file_system_type オブジェクトは、スーパーブロックオブジェクトにデータを設定する関数 get_sb() を提供し 

ます。get_sb() は、必要に応じて物理ディスク上の情報を読み込み (*) 、inode オブジェクトを操作する関数群 

(super_operations テーブル)をスーパーブロックオブジェクトに登録します。 super_operations テーブルは、 

各ファイルシステムに固有の関数となります。 

• 物理ディスク上のデータの配置方法は、ファイルシステムによって異なります。super_operations 

テーブルを起点として、このような、ファイルシステム固有の設定がなされていきます。 

► super_operations テーブルは、inode オブジェクトを操作する関数を提供します。特に、inode オブジェクトを 

作成する関数を含みます。 

► super_operations テーブルから作成された inode オブジェクトは、ディスクキャッシュにアクセスする関数群 

(file_operations テーブル)、および、物理ディスクへのアクセス要求をリクエストキューに登録する関数群 

(address_space_operations テーブル)を含みます。address_space_operations テーブルの関数群は、ファ 

イルシステムに固有の配置で物理ディスク上にファイルのデータを配置します。 

(*) 例えば、ext2/ext3 ファイルシステムの場合、get_sb() は、( 物理ディスク上に存在する)ファイルシステムのスーパー 

ブロックを読み込んで、スーパーブロックオブジェクトのデータの一部として格納します。ただし、スーパーブロックオブ 

ジェクトは、スーパーブロックそのものよりも広範なデータや機能を持っています。 





管理オブジェクトの関係 

• これまでに紹介した管理オブジェクトの関連を表す図です。例として、ユーザープロセス 1 と 2 が / 

にマウントした ext2 ファイルシステム(ルートファイルシステム)の /var/log/messages ファイルを 

参照している状況を示しています。 

► 詳細は次ページからの説明を参照してください。 

file_system_type 

ext2 

get_sb() 

マウント中のファイルシステム / 

スーパーブロックオブジェクト 


ポインターによる参照 

関数による操作 

super_operations 

inode オブジェクト 

address_space 

_operations 

データ転送 

dentry オブジェクト 

/var/log/messages 


ユーザープロセス 1 

ファイル 

ディスクリプター 

file オブジェクト 

file_operations 

ユーザープロセス 2 

file オブジェクト 





ファイルシステムのマウント処理 

• マウントするファイルシステムの種類に応じた file_system_type オブジェクトの情報に基づいて、 

スーパーブロックオブジェクトが作成され、super_operations テーブルが定義されます。 

► file_system_type オブジェクトに登録された get_sb() 関数が物理デバイスから必要なデータを読み込んで、 

スーパーブロックオブジェクトにデータとして格納します。 ext2 ファイルシステムであれば、物理デバイス上の 

スーパーブロックが読み込まれます。 

• 右図は ext2 ファイルシステムの super_operations 

の定義です。定義名から inode オブジェクトを操作 

する関数が含まれていることが想像できます。 

► 特に .read_inode 関数 (ext2_read_inode)は、物理デ 

バイスから ext2 ファイルシステムの inode 情報を読み 

込んで、対応する inode オブジェクトを構成する関数で 

す。これにより、物理ディスク上の個々のファイルにアク 

セスする準備ができたと言えます。 

► また、read_inode は、各 inode オブジェクトに対して 

file_operations テーブルと address_space_operations 

テーブルも定義します。(ここで定義された 

file_operations は、file オブジェクトが作成された時に、 

各 file オブジェクトにコピーされます。) 

static struct super_operations ext2_sops = { 

.alloc_inode = ext2_alloc_inode, 

.destroy_inode = ext2_destroy_inode, 

.read_inode = ext2_read_inode, 

.write_inode = ext2_write_inode, 

.delete_inode = ext2_delete_inode, 

.put_super = ext2_put_super, 

.write_super = ext2_write_super, 

.statfs = ext2_statfs, 

.remount_fs = ext2_remount, 

.clear_inode = ext2_clear_inode, 

#ifdef CONFIG_QUOTA 

.quota_read = ext2_quota_read, 

.quota_write = ext2_quota_write, 

#endif 

}; 





inode オブジェクトの作成 

• 指定のファイルパスから、物理ディスク上のファイルを検索し、対応する inode オブジェクトを作成 

する処理は下記の流れで行われます。( 例として /var/log/messages ファイルの場合を示します。) 

► ファイルシステムのマウント時に、マウントポイントのディレクトリに対応する inode オブジェクトおよび dentry 

オブジェクトが作成されています。一般に、ディレクトリの inode オブジェクトは、ディレクトリ直下のファイルお 

よびサブディレクトリを検索し、それらの inode オブジェクトを新規に作成する機能を持ちます。 

► 指定されたファイルパスの起点となるディレクトリ / の inode オブジェクトを利用して、その直下のディレクトリ 

/var の inode オブジェクトを作成します。( 必要に応じて、物理ディスクから /var ディレクトリの inode を読み込 

みます。)また、この結果を記憶する意味で、”/var” というパス名に対して、対応する inode オブジェクトをポイ 

ントする dentry オブジェクトも作成します。 

– 次回に /var の inode オブジェクトが必要になった場合は、再度、/ の inode オブジェクトから検索するのではなく、/var に 

対応する dentry から、ポイントされる inode オブジェクトを取得します。 

– シンボリックリンクなどにより、同一のファイルが複数のファイルパスを持つ場合、それぞれのファイルパスに対応した 

dentry が作成されますが、これらは、同一の inode オブジェクトをポイントします。 

► 同様に /var の inode オブジェクトを利用して、/var/log の inode オブジェクトと、対応する dentry オブジェク 

トを作成します。 ( 必要に応じて、物理ディスクから /var/log ディレクトリの inode を読み込みます。) 

► 最後に /var/log の inode オブジェクトから /var/log/messages の inode オブジェクトと、対応する dentry オ 

ブジェクトを作成します。 

• 上記のように、ファイルパス名に含まれるディレクトリの inode オブジェクトを順に構成することで、 

任意のファイルの inode オブジェクトを取得することができます。 





ファイルのオープン処理 

• ユーザープロセスが指定したファイルパスに基づいて、該当するファイルをオープンする処理は、下 

記の流れで行われます。 

► 前ページの処理により、指定したファイルパスから該当するファイルの inode オブジェクトと dentry オブジェ 

クトを作成します。また、新たに file オブジェクトを作成し、dentry オブジェクトへのポインターを設定します。 

– file オブジェクトは、該当ファイルをオープンするごとに作成されます。複数のプロセスが同一のファイルをオープンした場 

合、同一の dentry オブジェクトをポイントする、複数の file オブジェクトが作成されます。 

► inode オブジェクトが保持する file_operations テーブルを file オブジェクトにコピーします。 

– file_operations は、該当ファイルの内容をディスクキャッシュに対して読み書きする関数を提供します。特殊なオプション 

でファイルをオープンした場合、オプションに応じて、コピーされた file_operations が修正されることもあります。 

► ユーザープロセスのファイルディスクリプターテーブルに file オブジェクトへのポインターを設定します。(ファ 

イルディスクリプターテーブルについては次ページを参照。) 

• 以上の結果、ユーザープロセスは、ファイルディスクリプターから file オブジェクトを取得して、該当 

ファイルにアクセスすることが可能となります。 

► ユーザープロセスがファイルディスクリプタを指定して、read()、write() などのシステムコールを発行すると、 

それに対応する file_operations が実行され、ディスクキャッシュとのデータのやりとりが発生します。(ディスク 

キャッシュと物理ディスクの間のデータ転送については、次章で説明します。) 





ファイルディスクリプターテーブルについて 

• 各ユーザープロセスは、ファイルオブジェクトへのポインターを格納する配列を持ちます。これを、 

ファイルディスクリプターテーブルといいます。 

► この配列の添字番号が、いわゆる、ファイルディスクリプター番号になります。通常、0, 1, 2 番はそれぞれ、 

標準入力、標準出力、標準エラー出力に対応するファイルオブジェクトをポイントします。 

► 各ファイルディスクリプターに対応するファイルは proc ファイルシステムから確認することができます。ディレ 

クトリ /proc//fd/ の下にファイルディスクリプター番号があり、対応するファイルへのシンボリックリンクと 

なっています。 

– 図は sendmail プロセスのファイルディスクリプターの例です。Linux カーネルは、ネットワークソケットも file オブジェクト 

で管理しており、この例では、3 番と 4 番が TCP ソケットをポイントしています。 

# ls -l /proc/2417/fd/ 

total 6 

lr-x------ 1 root root 64 Jan 18 16:03 0 -> /dev/null 

l-wx------ 1 root root 64 Jan 18 16:03 1 -> /dev/null 

l-wx------ 1 root root 64 Jan 18 16:03 2 -> /dev/null 

lrwx------ 1 root root 64 Jan 18 16:03 3 -> socket:[5459] 

lrwx------ 1 root root 64 Jan 18 16:03 4 -> socket:[5452] 

l-wx------ 1 root root 64 Jan 18 16:03 5 -> /var/run/sendmail.pid 










ディスクキャッシュの種類 

• ディスクキャッシュには、ページキャッシュとバッファキャッシュの 2 種類があります。 

► ファイルシステム上のファイルにアクセスする場合は、ページキャッシュを使用します。ファイルシステムを経 

由せずに、ブロックデバイスに直接アクセスする場合は、バッファキャッシュを使用します。 (*) 

– 後者の例には、ユーザープロセスが、デバイスファイル(/dev/sda など)を介してブロックデバイスにアクセスする場合と、 

Linux カーネルが(スーパーブロックや inode を読み取るために)ブロックデバイス上の特定の 1 つのブロックのデータに 

アクセスする場合があります。 

► free コマンドや vmstat コマンドでは、ページキャッシュとして使用しているメモリー容量とバッファキャッシュと 

して使用しているメモリー容量をそれぞれ確認することができます。 

# f r e e 

t o t a l u s e d f r e e s h a r e d b u f f e r s c a c h e d 

M e m : 1 2 6 2 0 8 1 1 1 9 9 2 1 4 2 1 6 0 1 2 3 7 6 4 8 5 1 6 

- / + b u f f e r s / c a c h e : 5 1 1 0 0 7 5 1 0 8 

S w a p : 2 6 5 0 6 4 0 2 6 5 0 6 4 

# v m s t a t 

p r o c s - - - - - - - - - - - m e m o r y - - - - - - - - - - - - - s w a p - - - - - - - i o - - - - - - s y s t e m - - - - - - c p u - - - - 

r b s w p d f r e e b u f f c a c h e s i s o b i b o i n c s u s s y i d w a 

0 0 0 1 4 2 1 6 1 2 3 7 6 4 8 5 1 6 0 0 5 6 1 0 1 0 2 8 0 2 9 6 1 

(*) カーネル 2.4 とカーネル 2.6 でバッファキャッシュの使い方が変わっており、カーネル 2.4 では、この関係は成り立ちません。 





ディスク上のデータ配置 

• 物理ディスクは、通常、512B のセクター単位でデータを書き込みます。 

• 各ファイルシステムには、セクターの整数倍の大きさのブロックサイズが定義されており、ファイルシ 

ステム内のファイルは、この大きさのブロック単位に分割して物理ディスクに書き込まれます。 

► ブロック内のデータは、物理ディスク上で連続した領域に書き込まれることが保証されます。 

► 1 つのファイルが複数のブロックに跨る場合、異なるブロックは、物理ディスク上で離れた位置に配置される 

場合もあります。 

► ext2/ext3 ファイルシステムのブロックサイズは、ファイルシステムの作成時に mke2fs コマンドの –b オプショ 

ンで指定します。作成済みのファイルシステムのブロックサイズは図の tune2fs コマンドで確認できます。 

ファイルデータ 

・・・ 

# t u n e 2 f s - l / d e v / s d a 1 | g r e p " B l o c k s i z e " 

B l o c k s i z e : 1 0 2 4 

物理ディスク 

1 つのブロック 





ページキャッシュの構造 

• Linux カーネルは、メモリーを 4KB のページと呼ばれる単位に分割して管理します。 (*) 

• ページキャッシュに割り当てられたメモリーページには、ファイルの連続する領域のデータがブロッ 

ク単位で書き込まれます。 

► ファイルシステムのブロックサイズは、整数倍が 4KB のページサイズに一致する大きさのみが選択可能です。 

具体的には、512B, 1KB, 2KB, 4KB のいずれかになります。 

► 1 つのページキャッシュ内のブロックで、物 

理ディスク上で連続した領域に書き込まれて 

いる部分を、特に、セグメントといいます。 

ファイルデータ 

セグメント 

・・・ 

• ページキャッシュと物理ディスクの間の 

データ転送は、原則として、ページ単位で 

行われます。 

► 通常、ページ内の一部のブロックのみを物 

理ディスクに対して読み書きすることはありま 

せん。 

ページキャッシュ 


(*) このドキュメントでは、ディスクキャッシュ(ページキャッ 

シュ、もしくは、バッファキャッシュ)として使用されるメモ 

リーページを、一般に、『キャッシュページ』と呼びます。 

1 つのブロック 





ページキャッシュの管理 

• Linux カーネルは、各ページについて、そのページの情報を記憶するページディスクリプターを持ち 

ます。特に、ページキャッシュに割り当てられたページでは、対応するページディスクリプター内の変 

数に、下記の情報が保存されます。 

► mapping : ファイルの inode オブジェクトに含まれる address_space オブジェクトへのポインター 

– 各 inode オブジェクトは、その中に、address_space オブジェクトと呼ばれるデータを持ちます。mapping 変数は、その 

ページにデータが保存されたファイルの inode オブジェクトに含まれる、address_space オブジェクトをポイントします。 

► index : ファイル内のデータの位置 

– そのページに保存されたデータの、該当ファイル内での位置 (ページサイズ単位で先頭から何個目の位置か)を表します。 

► flags : キャッシュの状態を表すフラグ 

– PG_dirty : キャッシュの内容が物理ディスクに書き出されていないことを示します。 

– PG_writeback : キャッシュの内容を物理ディスクに書き出す処理が実行中であることを示します。 

– PG_locked : ページにアクセスロックがかけられていることを示します。 

• 上記の情報により、そのページキャッシュに含まれるデータが、どのファイルのどの位置に対応する 

かが分かります。 (*) 

► mapping 変数でポイントされる address_space オブジェクトを所有する inode オブジェクトを特定することで、 

どのファイルのデータが含まれるかが分かります。 

► index 変数の値から、該当ファイルのどの位置のデータが含まれるかが分かります。 

(*) 逆に、あるファイルの特定の位置のデータを含むページキャッシュを検索するために、Linux カーネルは、Radix Tree と 

呼ばれる、検索用ツリーデータも保持しています。 





バッファーキャッシュの構造 

• ファイルシステム上のファイルを介さずに、ブロックデバイスに直接アクセスする場合、物理ディスク 

とディスクキャッシュの間のデータ転送は、ブロック単位で行われます。 

► これは、ユーザープロセスが、デバイスファイル(/dev/sda など)を介してブロックデバイスにアクセスする場 

合と、Linux カーネルが(スーパーブロックや inode を読み取るために) 特定の 1 つのブロックにアクセスする 

場合があります。 

• バッファーキャッシュは、メモリーページをバッファーページとして割り当てた後、バッファーページを 

ブロックサイズのブロックブッファーに分割することで作成します。 

► データ構造上は、バッファーページはページキャッシュと同じ構造を持っており、後述のバッファーヘッドがア 

サインされている点のみが異なります。 (*) 

• バッファーページに対応するページディスクリプターには、下記の情報が保存されます。 

► mapping : ブロックデバイスに対応するデバイスファイル(/dev/sda など)の inode オブジェクトに含まれる 

address_space オブジェクトへのポインター 

– VFS の機能により、デバイスファイルに対しても inode オブジェクトが提供されます。 

► private : バッファーページ内の、先頭のブロックバッファーに対するバッファーヘッドへのポインター 

– 各ブロックバッファーには、その情報を保存するバッファーヘッドがアサインされます。バッファーページ内のバッファーヘッ 

ドは、次ページの図のように循環するポインターで互いをポイントしています。 

(*) ページキャッシュも、物理ディスクとの読み書きのタイミングで、補助的にバッファーヘッドを使用します。 





バッファーキャッシュの管理 

• バッファーヘッドには、対応するブロックバッファーの下記の情報が保存されます。 

► b_dev : 対応するブロックデバイスを示すディスクリプターへのポインター 

► b_data : バッファーページ内のブロックバッファーの位置 

– 先頭から何個目のブロックバッファーかを表します。 

► b_blocknr : ブロックデバイス内のデータの位置 

– そのブロックバッファーに保存されたブロックの、ブロックデバイス内での位置 (ブロック単位で先頭から何個目か)を表し 

ます。 

►b_state : ブロックバッファーの状態を表すフラグ 

– BH_Uptodate : ブロックバッファーに最新の 

データが読み込まれていることを示します。 

– BH_Dirty : ブロックバッファーの内容が物理 

ディスクに書き出されていないことを示します。 

– BH_Lock : ブロックバッファーにアクセスロッ 

クがかけられていることを示します。 

ページディスクリプター 

バッファーヘッド 

• 上記の情報により、ブロックバッファーに 

含まれるデータが、どのデバイスのどの 

位置に対応するかが分かります。 

バッファーページ 

ブロックバッファー 





ブロックレイヤー 





ブロックレイヤーの管理オブジェクト 

• ブロックレイヤーは、物理デバイスに対するデータの読み書きを実施するために、下記の 4 種類の 

オブジェクトを利用します。 

► gendisk オブジェクト 

– 個々の物理ディスクについて、その構成情報、デバイス番号 (メジャー番号、マイナー番号 )などのデータを保持します。 

特に、次のリクエストキューオブジェクトへのポインターを持ちます。 

► リクエストキューオブジェクト 

– 1 つの gendisk オブジェクトに対して、1 つのリクエストキューオブジェクトが割り当てられます。これは、リクエストオブ 

ジェクトが連なるキューと、個々のリクエストを実際に処理する I/O スケジューラーから成ります。 

► リクエストオブジェクト 

– 物理ディスクに対するデータの読み書きを依頼するリクエストデータである bio オブジェクトをまとめたオブジェクトです。リ 

クエストキューが新たな bio を受け取ると、リクエストキュー内の既存のリクエストに追加するか、もしくは、新たなリクエス 

トを作成して、キューに追加します。 

– 1 つのリクエストオブジェクトに含められる bio オブジェクトの構成は、I/O スケジューラーのアルゴリズムによって決まりま 

す。データ転送は、リクエスト単位で処理されますので、ユーザープロセスの PID 単位でリクエストを分けて、全てのプロ 

セスのリクエストを平等に受け付ける、などのアルゴリズムが考えられます。 (*) 

► bio オブジェクト 

– ディスクアクセスリクエストの最小単位であり、物理ディスク上の 1 つの連続した領域に対する、データの読み書きのリク 

エストを記述します。 

(*) 実際には、Linux カーネルには、後述の 4 種類のアルゴリズムが実装されており、個々のリクエストキューは、それぞれ 

異なるアルゴリズムの I/O スケジューラーを持つことができます。 





bio オブジェクトの構造 (1) 

• bio オブジェクトは、物理ディスク上の 1 つの連続領域に対するアクセス要求を表し、次のデータを 

持ちます。 

► bi_sector : アクセスする領域の最初のセクター番号 

► bi_size : 転送するデータ量 (Byte) 

► bi_rw : データ転送の方向 (Read または Write) 

► bi_io_vec : この bio に含まれる bio_vec オブジェクトの配列へのポインター( 次の説明を参照 ) 

► bi_end_io : この bio に含まれるデータ転送か完了したときに実行する関数へのポインター 

• 一般に、物理ディスク上の連続領域に対応するディスクキャッシュは、複数のセグメントに分割され 

ます。1 つの bio オブジェクト内に含まれる各セグメントは、bio_vec オブジェクトで表現されます。 

► 例えば、2 ページ分のキャッシュのデータ 

が、図のように配置されていた場合、この 2 

ページ分のデータ転送要求は、次のように 

表現されます。 

– 物理ディスク上の連続領域が 2 つあるので、 

対応する 2 つの bio で表現されます。 

– 各 bio は、それぞれ 2 つのセグメントを持つ 

ので、それぞれ 2 つの bio_vec を持ちます。 

– 図で bio 1は、セグメント1とセグメント4の 

bio_vec を持ちます。bio 2は、セグメント2 

とセグメント3の bio_vec を持ちます。 

ページキャッシュ 

セグメント1 セグメント2 セグメント3 セグメント4 


bio 1 

bio 2 





bio オブジェクトの構造 (2) 

• bio_vec オブジェクトは次のデータを持ちます。 

► bv_page : 対応するキャッシュページのページディスクリプターへのポインター 

► bv_len : セグメントの大きさ(Byte) 

► bv_offset : キャッシュページ内のセグメントの開始位置 (Byte) 

• 図は、bio オブジェクトが、物理ディスク領域を、データを転送するべきメモリー領域とどのように結 

び付けているかを表しています。 

bv_page 

bio_vec オブジェクト 

bv_len = 512 × 3 

bi_io_vec 

bio オブジェクト 

bi_size = 512 × 6 

bv_page 

bv_offset = 0 

bio_vec オブジェクト 

bv_len = 512 × 3 

bv_offset = 512 

bi_sector 


ページ 

キャッシュ 

セグメント1 

セグメント4 







リクエストキューオブジェクトの仕組み 

• 各リクエストキューオブジェクトは bio オブジェクトを受け取る関数 make_request_fn を提供します。 

► bio オブジェクトを受け取ると、リクエストキューオブジェクトに付随する I/O スケジューラーのアルゴリズムに 

従って、キュー内の既存のリクエストオブジェクトに追加するか、もしくは、新たなリクエストオブジェクトを作成し 

て、キューに追加します。 

• リクエストキューオブジェクトは、キューに溜まったリクエストを処理するモード(device unplugging) 

と、実際のデータ転送は行わず、キューにリクエストを溜めていくモード(device plugging)を切り替 

えながら処理を進めます。 

► unplugging、および、plugging を実行するタイミングは、厳密には、I/O スケジューラーのアルゴリズムに依 

存します。大雑把には、3 msec (もしくは、4 個以上のリクエストオブジェクトがキューに溜まるまで)の 

plugging の後、全てのリクエストがなくなるまで unplugging されます。 

► このようにして、物理的に連続する領域のリクエスト(bio)を、さらに、ある程度、溜めてから処理することで、 

ディスクヘッドの動きの少ない、最適化されたデータアクセスを実現します。 

• リクエストキューオブジェクトは、自分が所属する gendisk オブジェクトに対応したデバイスドライ 

バーの情報を持っており、最終的なデータ転送処理は、デバイスドライバーを通じて実行します。 

► デバイスドライバーは、1 つの bio に対する処理が終るごとに、bio オブジェクトの bi_end_io データで指定さ 

れた関数を実行します。Read アクセスの場合、この関数は、通常、対応するキャッシュページのロックを解放 

します。(p.8 『ファイルの Read 処理の流れ』を参照。) 





I/O スケジューラーの動作概要 

• I/O スケジューラーは、次のようにして、bio オブジェクトの受け入れと、物理 I/O の実施を行います。 

► リクエストキューオブジェクトが関数 make_request_fn で受け取った bio オブジェクトは、一旦、I/O スケ 

ジューラーに固有のサブキュー内にリクエストオブジェクトとして追加され、その後、I/O スケジューラーのアル 

ゴリズムに従って、実際に I/O 処理を行う順序でディスパッチキューに移動されます。 

► ディスパッチキューにある程度のリクエストオブジェクトがたまると、対応するデバイスドライバーが提供する 

request_fn 関数を呼び出して device unplugging モードに移行します。デバイスドライバーが、ディスパッチ 

キューに含まれる全てのリクエストの処理を終えると、再び device plugging モードに移行して、ディスパッチ 

キューへのリクエストの移動を再開します。 

– ディスパッチキューに含まれるリクエストをどのような順序で処理するかは、デバイスドライバーの実装に依存します。 

デバイス 

ドライバー 

request_queue 

オブジェクト 

make_request_fn 

リクエストオブジェクト 

request_fn 

queue_head 

リクエストオブジェクトに 

従って物理 I/O を実施 

ディスパッチキュー 

サブキュー 







I/O スケジューラーの選択 

• デフォルトの I/O スケジューラーは、カーネルの起動オプション elevator で指定可能で、下記の 4 

種類が選択可能です。 

► noop (No Optimization) 

– 受け取った bio は、物理ディスク上のセクターの位置に応じて、キューの先頭、または、キューの末尾に追加されます。 

► cfq (Complete Fairness Queueing) 

– 受け取った bio は、それを送ったユーザープロセスの PID をキーとするハッシュで 64 本のサブキューに分類されます。 

次に、各サブキューから一定量のリクエストを順に処理していきます。これにより、各プロセスに対して公平に I/O の処理 

が実行されます。 

► deadline (Deadline) 

– 受け取った bio は、物理ディスク上のセクターの位置に応じて、キュー上の既存のリクエストの中の最適な位置 (ディスク 

ヘッドの動きを最小とする位置 )に挿入されます。ただし、キューの前のリクエストに新しい bio が挿入され続けて、一定時 

間、処理されなかったリクエストは優先的に処理が行われます。(この “Deadline” 時間は、Read リクエストで 500 msec、 

Write リクエストで 5 sec です。) 

► as (Anticipatory) 

– Deadline に対して、次に受け取る bio を『予想する』機能を追加したものです。例えば、プロセス A からの Read 要求を 

受け取った直後に、プロセス B からの要求を受け取った場合、プロセス A からの Read 要求が続けて送られる可能性が 

高いため、プロセス B の要求を処理する前に、一定時間 (7 msec 程度 )、次のリクエストを待ちます。 

• これらのアルゴリズムは、ドライブヘッドが 1 つの、単純なハードディスク装置を前提としています。 

► RAID コントローラーなどを持つディスクシステムの場合は、ディスクシステム自身がアクセス処理の最適化 

を行いますので、noop が推奨される場合もあります。 





I/O リクエストの発行 





bio の組み立てとリクエストの発行 

• 実際に bio を作成し、make_request_fn を呼び出してリクエストキューに登録する処理は、各ファイ 

ルの inode オブジェクトの address_space_operations テーブルに登録された readpage、 

readpages および、writepages 関数が行います。 (*) 

► ページキャッシュ上のデータが物理ディスク上のどの位置に配置されるかは、各ファイルシステムのアルゴリ 

ズムで決まりますので、address_space_operations は、ファイルシステムごとに定義されています。 

• これらの関数は、物理ディスク上の連続領域ごとに 1 つの bio オブジェクトを作成し、 

make_request_fn で対応するリクエストキューに登録します。 

• これらの関数が実行される、主なタイミングは次の通りです。 

► p.8 『ファイルの read 処理の流れ』の『リクエストキューに read 要求を登録』の部分で、 readpage 関数が実 

行されます。( 同ページの脚注に記載の、『ファイルの先読み機能』でデータを読み込む時は、複数のページを 

連続的に処理する readpages 関数が実行されます。) 

► p.9 『ファイルの write 処理の流れ』の『カーネルスレッド pdflush が、リクエストキューに write 要求を登録』 

の部分で、writepages 関数が実行されます。 

(*) readpage と readpages は異なる関数ですので注意してください。 





readpage の実装 

• readpage 関数の実装は、ファイルシステムによって異なりますが、多くの場合、mpage_readpage 

関数を利用しています。 

► ファイルシステムに固有となるのは、主には、ファイル内のデータの位置 (ファイルの先頭から何ブロック目 

か)を、物理ディスク上の位置 (ディスクの先頭から何ブロック目か)に変換する部分です。このブロック位置変 

換の関数のみを独自に用意して、その他の一般的な処理は共通の mpage_readpage 関数で行います。 

• 例えば、ext2 ファイルシステムでは、ブロック位置変換の関数を ext2_get_block として、readpage 

関数は、mpage_readpage(page, ext2_get_block) を呼び出します。 

► mapge_readpage は、ブロック位置の変換が必要になると、第 2 引数で指定された ext2_get_block 関数を 

使用します。第 1 引数の page は、データを書き込むべきページキャッシュのページディスクリプターです。 

► 同様に、readpages 関数は、複数のページを連続して処理する mpage_readpages を呼び出します。( 本質 

的には、mpage_readpage と同じ処理を複数のページに対して実施します。) 

• mpage_readpage および、mpage_readpages は、読み込み対象のキャッシュページの情報から、 

物理ディスク上のデータの位置を求め、データセグメント(キャッシュページ内の物理ディスク上で連 

続する部分 )ごとに bio を構成し、リクエストキューの make_request_fn で、リクエストキューに登 

録します。 





writepages の実装 

• writepages 関数も、readpage と同様に、多くのファイルシステムで、共通の mpage_writepages 

関数を利用しています。 

• 例えば、ext2 ファイルシステムでは、ブロック位置変換の関数を ext2_get_block として、 

writepages 関数は、mpage_writepages(mapping, wbc, ext2_get_block) を呼び出します。 

► mapge_writepages は、ブロック位置の変換が必要になると、第 3 引数で指定された ext2_get_block 関数 

を使用します。第 1 引数および第 2 引数は、書き込み対象のページキャッシュを指定する情報を与えます。 

• mpage_writepages は、書き込み対象のキャッシュページの情報から、物理ディスク上のデータの 

位置を求め、データセグメント(キャッシュページ内の物理ディスク上で連続する部分 )ごとに bio を 

構成し、リクエストキューの make_request_fn で、リクエストキューに登録します。 





pdflush について (1) 

• ユーザープロセスから見た、ファイルの書き込み処理は、キャッシュページ上にデータが書き込まれ 

た時点で終了します。キャッシュページから物理デバイスへのデータの書き出しは、カーネルスレッ 

ド pdflush がバックグラウンドで実行します。 

• pdflush は、任意のジョブをバックグラウンドで実行するためのカーネルスレッドです。特に、物理デ 

バイスへのデータの書き出し処理のために、background_writeout、および、wb_kupdate の 2 種 

類のジョブを実行します。 

• background_writeout は、キャッシュページへのデータの書き込み処理が行われた後、Dirty フラ 

グのセットされたキャッシュページ( 物理デバイスにまだ書き出されていないページ)の割合が 

dirty_background_ratio (%) 以上になった場合に起動されます。 

► Dirty フラグのセットされたキャッシュページを、順に、writepages で物理デバイスに書き出します。 

► Dirty フラグのセットされたキャッシュページの割合が dirty_background_ratio (%) 以下になると、実行を終 

了します。dirty_backgrond_ratio の値 (デフォルトは 10 %)は、proc ファイルシステムの 

/proc/sys/vm/dirty_backgrond_ratio から確認、変更が可能です。 

► 実際には、全ての書き込み処理の後に起動されるわけではなく、ある一定の頻度で起動されます。Dirty フラ 

グのセットされたキャッシュページの割合が dirty_ratio (%) 以上になると、起動頻度が高くなります。 

dirty_ratio の値 (デフォルトは 40 %)は、proc ファイルシステムの /proc/sys/vm/dirty_ratio から確認、変更が 

可能です。 





pdflush について (2) 

• kw_kupdate は、タイマーによって一定時間ごとに起動されます。 

► 起動時間間隔は、proc ファイルシステムの /proc/sys/vm/dirty_writeback_centisecs ( 単位は 1/100 sec) 

から確認、変更が可能です。デフォルト値は 500、つまり 5 secです。 

► dirty_expire_centisecs ( 単位は 1/100 sec)よりも長い間 Dirty フラグがセットされているキャッシュページを 

全て、物理デバイスに書き出します。 dirty_expire_centisecs の値は、proc ファイルシステムの 

/proc/sys/vm/dirty_expire_centisecs ( 単位は 1/100 sec)から確認、変更が可能です。デフォルト値は 3000、 

つまり 30 sec です。 

► 従って、デフォルトでは、書き込まれてから 30 sec 以上経過したキャッシュページは、5 sec 以内に物理デバ 

イスに書き出されることになります。(ただし、書き出すページが多く、kw_kupdate による書き出し処理に時間 

がかかる場合は、これよりも遅くなることはあります。) 





参考資料 





参考資料 

• Understanding the LINUX KERNEL (3 nd Edition) 

►http://www.oreilly.com/catalog/understandlk/ 

• Linux Device Drivers (3 nd Edition) 

►http://www.oreilly.com/catalog/linuxdrive3/ 

《商標について》 

• Linux は、Linus Torvalds 氏の商標または登録商標です。 

• その他、表示されている会社名、製品名は一般に各社の商標または登録商標です。 





変更履歴 

• Version 1.0 2006/01/25 作成 

• Version 1.1 2008/06/11 外部公開 

• Version 1.2 2009/11/06 I/O スケジューラーの動作概要を追加

hX1P8B

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?