革命の日々！ writeではtmpfsよりpage cacheが遅い理由
注意： 以下の記事は完全に間違っています。ext3はflushメソッドがNULLなので、closeのときにfsyncされないよん。ごめんなさいm(_ _)m http://d.hatena.ne.jp/naoya/20070521/1179754203 のコメント欄 naoya 『read はキャッシュに載ってれば常にメモリアクセスのみで済むけど write はページに dirty フラグを立ててプロセスに制御が戻ったあと、pdflush がどこかのタイミングでディスクに書き出しして必ず物理的にディスクにアクセスしますよね。 その時の排他処理周りなんじゃないかなあと思いますが、その辺が実ははっきりしないんですよね。だいぶ追ってみてはみたんですが。』 (2007/05/22 00:24) naoya 『普通に考えれば write はディスク更新があるから云々というのは想像がつくけど、じゃあ具
ファイルを unlock して問題になるくらいなら、OS 任せにするほうがよい - kなんとかの日記
476 名前: デフォルトの名無しさん Mail: sage 投稿日: 2008/03/05(水) 23:48:04 ファイルの排他制御のテストプログラムを書いています。 ただ単に１つのカウントファイルを１００万回インクリメントするプログラム #!/usr/bin/env python for i in range(1000000) : f = open("count-file", "r+") fcntl.flock(f.fileno(), fcntl.LOCK_EX) cnt = f.readline() cnt = int(cnt) + 1 f.seek(0) f.write("%d\n" % cnt) fcntl.flock(f.fileno(), fcntl.LOCK_UN) f.close() を同時に２つ実行するとcount-fileの値が 2000000 になるはずが、 19
naoyaのはてなダイアリー - Linuxのページキャッシュ
世間では PHP が、Perl が、と盛り上がっているようですが空気を読まずまたカーネルの話です。今回はページキャッシュについて。 /dev/shm に参照系ＤＢを持っていくと I/O 負荷が激減した件（当たり前だけど） - drk7jp で、ディスク上にあったファイルを /dev/shm (tmpfs) に移したら I/O 待ちがなくなって負荷がさがった、ということなんですがおそらくこれは tmpfs に置く必要はないかなと思います。Linux (に限らず他の OS もそうですが) にはディスクの内容を一度読んだらそれはカーネルがキャッシュして、二度目以降はメモリから読む機構 = ページキャッシュがあります。tmpfs にデータを載せることができた、ということは物理メモリの容量に収まるだけのデータサイズかと思うので、放っておけば該当のファイルの内容すべてがメモリ上にキャッシュされて io
辞書が壊れない仮名漢字変換エンジンの作者を雇うのは案外に難しいのかもしれない，という話 - NyaRuRuが地球にいたころ
ファイルクローズと内容の同期 MS-DOS ならいざ知らず、最近の OS なら f.close() するときに「バッファの flush」と「ファイルの unlock」の両方をしてくれる。つまり OS が面倒見てくれるから、必要な後処理は OS に任せてしまいましょう、ということ。プログラマーが勝手に unlock して問題になるくらいなら、OS 任せにしたほうがいい。resource を管理するために OS があるんだから。 先日 Windows でまさにこの話を追いかけていたばかりなので，ちょっと気になって軽く調べてみました． Linux の close は fsync 相当を調べる - naoyaのはてなダイアリー Linux I/O のお話 write 編 - naoyaのはてなダイアリー どうやら Linux での日常的な風景も，Windows でのそれと基本的には同じ．つまり，デ
Linux カーネル内の flush と fsync - kazuhoのメモ置き場
re ディスクの情報とメモリ上の情報 - odz buffer re 辞書が壊れない仮名漢字変換エンジンの作者を雇うのは案外に難しいのかもしれない，という話 - NyaRuRuが地球にいたころ re Linux の close は fsync 相当を調べる - naoyaのはてなダイアリー 以下の理解であってると思う。たぶん... だよね？ file_operations::flush は、ネットワークファイルシステムにおいて書き込みの成否を確認するための呼び出し ファイルの内容が「ユーザプロセスAが書き込んだ最新のデータを他のユーザプロセスBが読める」ことを保証するための呼び出し ext3 において noop なのは、ext3 がローカルファイルシステムであり flush を呼ばなくても書き込みの成功が保証されるから nfs 等においては nfs サーバへの書き出しを保証する? 「ディス
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
