パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

Linux Kernel 2.6.11 リリース」記事へのコメント

  • by Anonymous Coward on 2005年03月04日 0時51分 (#703092)
    以下の文書の37ページから42ページあたりで指摘されている
    http://www.dd.iij4u.or.jp/~okuyamak/Documents/2004-11-19-Fedora-Study/Doubt-Intro-for-FedoraJP.notemp.pdf

    正しく同期書き込みしないバグは直ったのでしょうか?

    やっぱり、*BSD 辺りを選んだほうが無難かな…
    • 症状はかなり減った。が、まだおかしい。

      http://developer.osdl.jp/projects/doubt/

      少なくとも2.4でo_sync周りにあったバグは、2.6ではなくなっている。これはo_syncの実装が async write + fsync という実態に変わったから。ただしfsyncが問題ないかといわれると問題はある。

      1) HDDのwrite cacheに対してwrite back型の書き込み命令を発行している。
          ATAの場合、どうやらこれが起こっているらしい。本来は write through を実行しなくてはいけない(もちろん、そういうコマンドがある)。

      2) device driver errorがちゃんと返ってこない。
            たとえば、USB HDD上のファイルシステムに書き込みをやっておいて、USB ケーブルを引っこ抜く。HALDとかが動いていない場合、ext2はタイミングによってはEIOが検出できない。
          ext3はもっと酷くてRead Only File Systemなどというエラーを返す。
      --
      fjの教祖様
      親コメント
    • 読んだのですが、 どこにも「*BSDなら問題ない」という証拠が
      無いのに、BSDを大丈夫だとするのが気になりました。

      というか、HDDの書き込みの点一つを理由に「BSDを使いましょう」ってのは
      非常に極端だなぁ、という感じですね・・HDDの書き込みに同期を取ってれば
      何のOS使ってても良いのかなぁ、とか、ならWIndowsで良いじゃん、と、
      そんな感じがしました。
    • 質問です。指摘のように正しく同期書込しないと
      1.どんな問題が起こるのですか?
      2.kernel2.6だけの問題なのでしょうか?
      3.同様の検証を各種BSDに行っても問題は発生しないのでしょうか?

      知りたいところです。
      私は現在、kernel2.4のお世話になっていますので、あまり切迫感
      はないのですが、、、。

      #BSDもLinuxも好きなのでAC
      • 1. 高い信頼性が要求されるもの以外はふつうは問題にならない。
        2. いつからは知らないが2.6だけではなかったと記憶してます。
        3. 正しく同期書き込みしているかはわからりませんが、バグは別としてああいうテストで問題になったことはなかったはず。
        • 暇なんで、問題になる場合でわかりやすい例を2つほど書いてみる。

          動作中にストレージAを外すことを考えてみよう。
          手順としては
              sync -> umount -> sync -> 物理的に外す
          だろう。このとき間違ってストレージBを外してまったとしよう。ストレージBが同期書き込みなら、物理的に外すときに書き込みがなければOK。非同期書き込みなら、2回目のsycn以後に書き込みがなければOK、そうでなければNG。Linux の場合はどっちもどれもNG。
          別のストレージを umount してしまった
        • >ファイルシステムやDBがおかしくなる原因は他にもあるし、サーバーでもあまり気にする必要のないことだと思います。

          いいかげんだなぁ…
          ちゃんと同期書き込みしないとRAID組んでDBMS動かしても、
          データを突然失う可能性がありますよね。
          #まあ、commit のタイミングが怪しいシステムに、
          #どんな強固なDBやファイルシステム与えても無駄だけど。
          • 信頼性を落として見かけの性能を上げるというアプローチもあって良いと思います。高い信頼性を必要としないものに Linux を使うのも良いでしょ。

            ところで、Linux は同期書き込みのときにI/Oの順番が保証されていないのでしょうか。
            • linuxにかぎりませんが、ファイルシステムはデフォルトは非同期書き込みになっていて、信頼性は無いが性能は高いという状態になっています。同期書き込みをさせるには、わざわざopen(2)の際にオプションをつけたり、fsync(2)を呼び出したりしなくてはいけません。
              つまり「意図的に信頼性を優先してくれ」と言われた場合にはじめて、同期書き込みをしているわけです。このような場合にまで性能を優先するのは戦略として間違っていると言わざるをえません。
              --
              fjの教祖様
              親コメント
            • >信頼性を落として見かけの性能を上げるというアプローチもあって良いと思います。高い信頼性を必要としないものに Linux を使うのも良いでしょ。

              その場合、ext2 が最適と考えます。
              わざわざ、ジャーナリングするファイルシステムを用意する必要はありません。

              >ところで、Linux は同期書き込みのときにI/Oの順番が保証されていないのでしょうか。普通に考えるなら保証が無くなるのですが、実際の動作が、非同期書き込みで、でき
    •  いや、こんなまわりくどいテストするより、ソースを見るほうがはやいんじゃないかと思うんだが・・・

       まあ、奥山はおとなしくfjでbsdと戯れてろってこった

弘法筆を選ばず、アレゲはキーボードを選ぶ -- アレゲ研究家

処理中...