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

Linus、XFS を 2.5 カーネルにマージ」記事へのコメント

  • ext3, Reiser, XFS とジャーナリングファイルシステムって 色々あるんですが、どれを選ぶかは趣味? 好み? なんでしょか?
    • by tyamaguchi (7612) on 2002年09月18日 19時43分 (#168220) ホームページ
      私はこのページ [iij4u.or.jp]を参考にしました。

      ちょっとlinuxに関して手厳しい意見に見えるかも
      しれませんが、とにかく、これだけファイルシステムに
      関して詳しく解説しているところって滅多にないんじゃ
      ないかと思います。是非、御一読を。

      #私は、これを呼んでファイルシステムはXFSにしました。
      #「linuxのファイルシステム」の中では、「仕組み的には」
      #XFSが一番堅牢らしい。って読めたんだけど、これって
      #読み間違い?
      親コメント
      • by Anonymous Coward on 2002年09月18日 20時17分 (#168230)
        その文章は
        *jbdはジャーナルの書き込みにext2を使っていない
        *ディスクはリクエストを出した順序に処理を行うという保証はない
        という点で事実誤認をしています
        嘘をまき散らす人と信じる人がいるわけですね
        親コメント
        • jbdってのはこの辺で解説されてる [ibm.com]Journaling Block Deviceレイヤーのこととして話を進めますが、仮にあなたの意見が正しいとしても、現在のLinuxのVFSレイヤーにraw disk I/Oが無い以上、その上で動作するファイルシステムはどれもダメ(=Journalの正しさを保証できない)という件の文章の結論が変わるとは思えません。

          「ディスクはリクエストを出した順序に処理を行うという保証は無い」という文章も今一つ意味が判りません。Linuxの非同期ディスクアクセスについては件の文章でも言及されているので、その話ではありませんよね。ハードウェア的に発行された書き込み命令の順序が、ディスク側で入れ替わる可能性がある、ということですか?
          (外付けのRAID箱ならそういう場合もあるかも知れんが)

          他人の文章を事実誤認と非難するのであれば、第3者にも判るように説明する必要があると思います。で、その結果が件の文章にフィードバックされれば、ためになる情報が蓄積され、より多くの人が幸せになれると思うんですが。

          親コメント
          • by Anonymous Coward on 2002年09月19日 0時25分 (#168398)
            > 現在のLinuxのVFSレイヤーにraw disk I/Oが無い以上、
            > その上で動作するファイルシステムはどれもダメ

            違います。
            なぜ raw disk I/O(そもそもこの用語で何を仰りたいのかよくわかりませんが)
            が無ければ書き込み操作の完了が保証されないとお考えなのでしょうか。
            正しく排他処理を行えば簡単に実現できます。
            最もナイーブに作ればログの書き込みは
            1. ログデータを書き込むためのロックを獲得
            2. オンメモリのログデータを変更
            3. I/O リクエスト発行
            4. I/O リクエストの完了待ち
            5. ログデータを書き込むためのロックを解放
            のようになります。

            > ハードウェア的に発行された書き込み命令の順序が、ディスク側で入れ替わる可能性がある、ということですか?

            はい、あります。
            ハードディスクの書き込みキャッシュを利用している場合、
            個々の書き込み操作の間の順序関係は守られないかもしれません。
            守りたい場合は書き込みごとに書き込みキャッシュを
            フラッシュする必要があります。
            この場合、softupdate はフラッシュだらけになってしまいますが
            LFS や JFS の場合はトランザクションの開始と終了(コミット)だけ
            書き込み順序が守られていればよいのでフラッシュの回数を抑えられる、
            かもしれません。
            # Linux のファイルシステムはどれも対応してないようですが…
            # というか、現在の所、正しく対応しているファイルシステムの実装はない?
            親コメント
            • 判りやすい解説ありがとうございますm(__)m

              ACさんなんで#168239 [srad.jp]と同じ方かどうか判りませんが、初めからこういう風に書いてあれば私なんぞが異論を挟む余地はありません。

              raw disk I/Oってのは、HDD上のキャッシュ以外の要素を考慮しなくて良い直接的なディスク操作、という意味で使ってます。おっしゃる通り、きちんと排他処理がなされていれば結果は同じですね。

              でも、HDD上のキャッシュをソフトからフラッシュする汎用的な方法ってあります?SCSIならありそうな気がしますが、IDEの場合そんな高級な操作って出来るのかな…

              親コメント
              • http://www.google.com/search?num=30&hl=ja&inlang=ja&ie=EUC-JP&oe=eucjp&q=0xe7+0xea+flush+cache&lr=
                今時のATAコマンドはSCSIと変わりません。
            • 誤解があるといけないので、
              親コメントの補足説明です。

              「ハードディスクの書き込みキャッシュ」とは
              「ハードディスクに搭載されている書き込みキャッシュ」のことです。
          • >>現在のLinuxのVFSレイヤーにraw disk I/Oが無い
            意味わかって書いてます?
        • 木を見て森を見ず、ってやつですか。

          なぜ「…という点が間違っているので注意」と書けないのかな。
          • 示されている資料は [iij4u.or.jp]
            Ext3 や Linux のファイルシステムに関して誤認があるのだから、
            XFS と他の ファイルシステムとの比較に役に立つとは思えません。
            そもそも具体的なデータを示してあるわけでもありませんし。
      • 親コメントで示されている資料 [iij4u.or.jp]には
        次のような記述があります。

        > 図 4.4(d) ではじめて inode が更新される。
        > inode は一般に HDD の sector サイズよりも小さいので、
        > この更新は all or nothing で実行される。
        > 従って、inode が「破損」する可能性は考えなくて良い。

        これは嘘です。
        大抵のハードディスクでは、
        セクタへの書き込み中に電源が落ちると、
        そのセクタのデータが壊れる可能性があります。
        このことは各社
        • そのページの上の方にある、前提条件の2番目↓を見落としていませんか?

          > 2つ目は、 Storage はある単位での write リクエストに対して、
          > 完全実行か無実行になることだ。 もっと分かりやすく言えば、
          > SCSI IO request の単位でもいいし、 IDE のコマンドの単位でもいいし、
          > sector 単位の書き込みでもいいから、 とにかく「この命令を実行し始めたら、
          > これだけは最後までやり遂げる」 という基本単位を保証してもらわ
          > なくてはいけない、と言うことだ。 一般には、これは Sector 単位で
          >保証されていて、 ある Sector を上書きし始めたら、その Sector
          > の書き込みに関しては HDD 側が保証するのが一般的だ。

          指摘されてる件は、現実的ではあっても、上述の前提条件を満たして
          いない場合ですよね。これを仮定しないと「いわゆるジャーナル
          ファイルシステム以外全部ダメ」の結論しか出ない。

          それ以外の優劣を論じるためにクリティカルセクションの大きさを
          基準にしている。

          と、読んだのですが違ってますか?

          #現実の電源断でセクタが壊れる可能性自体は認めますよ。もちろん。
          親コメント
          • うーん、ファイルシステムの Robustness を論じる上で、
            現実的でないモデルにもとづいて

            > それ以外の優劣を論じ

            ることにどれだけ意味があるのでしょうか。

            むしろ私は、

            > これを仮定しないと「いわゆるジャーナル
            > ファイルシステム以外全部ダメ」の結論しか出ない

            から、都合のよい前提条件を仮定したのではないか、
            と、読んだのですが違ってますか?

            そもそも、元の資料 [iij4u.or.jp]の

            > このRobust なファイルシステムの実装には3つの前提がある。
            • 最初に断っておきますが、親コメントが文脈を見落とした上での
              断罪に見えたので反応しただけです。私自身が有識者ではありません。

              >むしろ私は、
              (略)
              >から、都合のよい前提条件を仮定したのではないか、
              >と、読んだのですが違ってますか?

              それらが優れているのは認めながらも、それで終りにしたくなかったん
              じゃないかと勝手に想像してます。

              >そもそも、元の資料 [iij4u.or.jp]の
              >> このRobust なファイルシステムの実装には3つの前提がある。
              >の部分がおかしいです。

              こっちの方は、あの文書の弁護や代弁しようとは思いません。

              #ただ、あれは3年ぐらいは前の文書ですよね。多分。

              代わりに、私の疑問を提出しときます。
              別コメント [srad.jp]で「HDDがコマンドを順に実行するとは限らない」
              という情報が出て来てます。これは、、、

              (1) 本当ですか?
              (2) LFSやJFSの設計に影響しますか?

              これらがどちらもyesだとしても、LFSやJFSが無意味なわけではないですよね?
              あの文書とsoftupdateも、当時は(FreeBSDでは現在も)同程度に意味が
              あった(ある)のだと思います。

              #ほとんど歴史文書だと分かんないことが問題。
              親コメント
              • 「HDDがコマンドを順に実行するとは限らない」
                という情報が出て来てます。これは、、、

                (1) 本当ですか?

                推測なんですが、本当なんじゃないでしょうかね。たとえば SCSI-2 だと command queuing があって reorder が許されてたと思います。本当にそういうことをするデバイス(ディスクドライブ)があるかどうかは知りませんが、あってもおかしくはないのではないかと(物理セクタに不良があった場合など、reorder とかしてるかも)。

                (2) LFSやJFSの設計に影響しますか?

                本当なら影響するんだけれど、個々のデバイスの内部での reorder は機種やメーカーによって

              • どもです。

                FSとHDDとでそれぞれ現状を仮定して、別々に設計の最適化を行っているのが
                うまく噛みあってないみたいですね。両者が集まってモデル作りをしないと
                いけないのでしょう。

                メタデータの書き込みと一般のデータの書き込みを分離して、メタデータ側は
                reorderしないことぐらいが最低限の必須要件なんですかね?
                親コメント
              • LFS や JFS がハードウェアに要求する最低限の必須条件は

                「2つの書き込みがあったときに どちらが先に書き込まれるかを指定する手段があること」

                だけです。そして現行のハードディスクはこの条件を守っています。

                この条件が満たされれば、ファイルシステムはログに対するトランザクションの開始と終了を確実に行えま
              • 自分なりにまとめてみると、

                「重要なのは、トランザクションに続いてデータが書き込まれるという
                順序で、それぞれの中での書き込み順は問題ではない。完了したか、
                しなかったかが分かればよい」

                ということでしょうか?

                どうも、私はメタデータとトランザクションとを混同していたようです。
                ども、長々とありがとうございました。

                #ところで、この話題って2回目ですか?
                #教えてもらってもすぐ忘れる奴>わし。
                親コメント
              • > ということでしょうか?

                LFS や JFS に関していえば、そうです。

                > #ところで、この話題って2回目ですか?
                > #教えてもらってもすぐ忘れる奴>わし。

                はやく前回のトランザクションがコミットされてるかたしかめて!
        • >> softupdateは…? 鰯の頭
        • でも、電圧降下を調べて head を待避すると言うよ?しかも最近は大きなコンデンサを載せて、電圧降下を検出したらそのセクタを最後にする機能もあるという。PCの電源自体にもそこそこのコンデンサが載ってるしね。以外と「sector が壊れる」のは難しいだろう。故障とかならともかく、停電とかならば。

          ま、それで駄目ならあきらめでしょう。少なくとも、softupdate の書き順で書
          • > でも、電圧降下を調べて head を待避すると言うよ?

            ヘッドを退避するのはクラッシュを防ぐためです。
            普通に考えればヘッドを退避してしまったらデータの書き込みは完了できません。
            (ちなみに「大きなコンデンサ」はこのヘッドの退避に使われます。)

            > 電圧降下を検出したらそのセクタを最後にする機能もあるという。

            それは初耳です。どのハードディスクか教えてくれませんか?

            > sector 異常は CRC で検出してくれるから、間違ったデータが出てくる確率は低いだろうし

            それは違います。
            ハードディスクで使われている ECC は
            「書き込みが途中で止
            • i ノードへの書き込みよりディレクトリエントリへの書き込みのほうが大きな問題になりますね。
              • いや、directory entryへの書き込みは
                書き込み順番に気をつければ大丈夫だと思います。
                やはり問題はi-node(を含むsector)への書き込みが失敗する場合でしょう。

                # 確率は低そうですが…
            • >> でも、電圧降下を調べて head を待避すると言うよ?
              > ヘッドを退避するのはクラッシュを防ぐためです。
              > 普通に考えればヘッドを退避してしまったらデータの書き込みは完了できません。
              > (ちなみに「大きなコンデンサ」はこのヘッドの退避に使われます。)

              データ書き込みがIO命令の単位で完成する必要はないんじゃないの?セクタ単位で十分でしょう?

              >> 電圧降下を検出したらそのセクタを最後にする機能もあるという。
              > それは初耳です。どのハードディスクか教えてくれませんか?

              HとかIとか海とか、今時大抵そうだという話を聞きますが?
              #本当かどう
              • > データ書き込みがIO命令の単位で完成する必要はないんじゃないの?セクタ単位で十分でしょう?

                「セクタ単位で完了するとは限らない」ということが問題なのです。

                > HとかIとか海とか、今時大抵そうだという話を聞きますが?
                > #本当かどうか調べたわけではありませんので確証はありませんし、
                > #SCSI用の話しか聞いてないのでATAがどうかも知りませんが。

                少なくとも各社のハードディスクのマニュアルには記載されてません。
                例えば、I 社の SCSI ハードディスク U なんとかのスペックには
                「データ書き込み中に電源が落ちた場合に失われるかもしれないセ

普通のやつらの下を行け -- バッドノウハウ専門家

処理中...