最近のLinuxで有効になっているI/Oバリア機能と、RDBへの影響 | Unofficial DB2 BLOG
比較的新しいカーネルを採用したLinuxディストリビューションでは、ファイルシステムのI/Oバリア (I/O barrier)機能がデフォルトで有効になっています。例えばRedhat Enterprise Linux (RHEL) 6やSUSE Linux Enterprise Server (SLES) 11等はインストール直後の状態でext4ファイルシステムのI/Oバリアが有効になっているようです。 I/Oバリアは簡単にいうと、「バリア命令」の後で発行されたI/Oは、バリア命令の前に発行されたI/Oの後に必ず実行されるようにする仕組みです。つまりI/Oの順序（物理ディスクに反映される順番）をまもらせる仕組みといえます。 ファイルシステムにI/Oバリア機能が追加されたのは、ファイルシステムが不整合な状態になる可能性を減らすためです。 そもそも、急な電源断でもファイルシステムの不整合が起こ
第6回 UNIXプログラミングの勘所（4） | gihyo.jp
ファイルの保存 ここまでいくつかの見落としがちな処理を見てきましたが、最後にどんなプログラマでも必ず行う「ファイルの保存」についての注意点を考察してみたいと思います。 ファイルを確実に書き込むためには、どのようなコードを書けばよいでしょうか。「fsync」を呼べばいい。それだけではありません。実際には、次の2点も必要になってきます。 （内容の差し替えだった場合に）書き換え途中の状態にならないこと ユーザに対して書き込み完了を返したあとは、ディスクがクラッシュしない限り、データが消えないこと UNIX系OSでこれらの要件を満たすには、まずテンポラリファイルに新しいデータを書いてディスクに同期し（①②）、（必要ならば）古いファイルをバックアップファイル名を使っても参照できるよう別名を付与し（③）、次にテンポラリファイルのファイル名を差し替え対象になっているファイルの名前に切り替え（
Linux の close は fsync 相当を調べる - naoyaのはてなダイアリー
Linuxのcloseは暗にfsyncするから、ここであげられている 100000回繰り返し open 8K write close というパターンだとfsyncコストが見えちゃうので良くないんじゃないかな とのことで、そうなのか! と思ったので例によって深追いしてみました。 まず fsync(2) の実装は fs/sync.c にあります。 asmlinkage long sys_fsync(unsigned int fd) { return __do_fsync(fd, 0); } static long __do_fsync(unsigned int fd, int datasync) { struct file *file; int ret = -EBADF; file = fget(fd); if (file) { ret = do_fsync(file, datasync);
Ext3のコミット間隔を当てにしたアプリケーションは、Ext4でデータロスの恐れあり | スラド
4月にリリースされる予定のUbuntu 9.04（開発コード名：Jaunty Jackalope）のオプションで提供されているファイルシステムExt4を使用した場合、Ext3のコミット間隔を当てにしたアプリケーションによってはデータロスが発生する恐れがあるそうだ（本家記事より）。 バグレポートではKDE 4のデスクトップファイルがロードされた後にクラッシュし、KDEコンフィギュレーションなどのデータが全て失われるという状況が報告されている。 Ext4の開発者Ts'o氏によると、Ext4はXFSのように遅延アロケーションが用いられており、新しいデータの書き込みは最大60秒かかることもある。遅延アロケーションはディスク領域の割り当てを効率化し、書き込みパフォーマンスを向上させることが出来るのが利点とされている。KDEやGNOMEのデスクトップアプリケーションはコンフィギュレーションファイルなど
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
