OSDN -- Develop and Download Open Source Software
edit | Title Index |  Recent Changes  | 

Show page source of internal22-67-トリッキーなバッファ管理 #25440

[[PageNavi(internal22-navi)]]

{{{ comment
h2w-title:トリッキーなバッファ管理
}}}
 

= トリッキーなバッファ管理 = #SECTION032120000000000000000

表面的にソースを見ただけでは分からないが, バッファとディスクの同期のメカニズムは非常にトリッキーである. Linuxは性能を稼ぐため(と勝手に解釈している), 書き込みI/O途中のバッファのデータを参照/更新することが可能である.

ディスクI/Oの為のロック処理は存在しないため, 例えば以下の処理を行った後のディスク上のデータの値は不定である.

{{{
        bh = getblk();
        bhが管理するバッファのデータを更新
	mark_buffer_dirty(bh);
	ll_rw_block(WRITE, 1, &bh);
	wait_on_buffer(bh);
}}}

一見, バッファに書き込んだ値がそのままディスクに反映されるようにだまされてしまうが, getblk関数で得られたバッファがちょうど書き込みI/O中であることがありうる.

まだドライバ内のキューに継れている状態であれば, 運よく今回の更新がディスク上に反映されるが, I/Oコントローラに処理が渡っている場合(もしくは上記処理中にI/Oコントローラが動き出した場合)は, 中途半端にバッファ更新されたバッファがディスクに書き込まれてしまう.

実は, その様な場合でも上手く誤魔化すためのトリックが隠されている. I/O中のバッファに対してmark_buffer_dirtyを行うと, バッファにI/O処理中フラグBH_Lockと共にBH_Dirtyフラグが立つ. ll_rw_block関数はI/O中のバッファに対しては何も処理を行わず全ての処理をスキップする. このような状態になった中途半端なバッファも, いづれkflush/kupdateデーモンにより再度書き込みが行われ, そこで初めて辻褄があうことになる.

ただしこの動作は, 明示的なディスク更新が出来ない事を意味しており, 以下のような場合期待した動作をさせることができない.

  *  syncモードマウントにおけるメタデータの同期更新
  *  fsyncシステムコール

----

''(NIS)HirokazuTakahashi [[BR]]2000年06月11日 (日) 22時29分57秒 JST''1

[[PageNavi(internal22-navi)]]
show edit history