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

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

  • by Anonymous Coward on 2002年09月18日 17時40分 (#168141)
    ext3, Reiser, XFS とジャーナリングファイルシステムって 色々あるんですが、どれを選ぶかは趣味? 好み? なんでしょか?
    • by gand_hi (1923) on 2002年09月18日 17時52分 (#168150)
      IBM のこの記事 [ibm.com]はいかがでしょうか?
      親コメント
    • 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 なんとかのスペックには
                「データ書き込み中に電源が落ちた場合に失われるかもしれないセ
    • by ramsy (8353) on 2002年09月18日 18時06分 (#168158) ホームページ 日記
      ext3 は 2にジャーナリングファイルを付け加えただけなので、 現行のサーバを移行するのは非常に楽ですね。
      fs周りのツールとkernelを対応の物に更新
      tune2fs -J たーげっと
      fstab ext2からext3に置き換え
      mount -o remount /hoge
      でお終い。
      ただし、ext2を拡張しただけあってパフォーマンスは他の二つに比べて落ちます。
      --
      # rm -rf ./.
      親コメント
    • by bnez (11270) on 2002年09月18日 19時05分 (#168195) ホームページ
      単なる経験談なので参考になるかどうかはわかりませんが。

      ReiserFSとext3をどちらも1年以上使っています。現時点で自分が管理しているPCが4台、!PCな小型マシンが2台あって、ReiserFS使ったりext3使ったり混在させたりしています。
      # ポリシがないな > 自分

      数度のクラッシュを経験してますが、どちらのファイルシステムについても特に困った経験はないです。また、ファイルシステムに大きな負荷をかける使い方をしていないので、性能的に困ったこともないですね。

      ということで、個人的にはReiserFSとext3の2つについてはわりと安定している印象があります。
      親コメント
      • by ramsy (8353) on 2002年09月18日 19時38分 (#168217) ホームページ 日記
        えーと、運が良いですね(^^;;)
        色々遊んでるひとは、fs飛んだ~とかkernelこけた~とか悲鳴を聞いた覚えがあります。
        ReiserFSって中身はDB(の様な物)なので、 それなりに準備すればDBとして使うことも可能とか。(うろ覚え)
        私的印象は以下の通りです。
        • ext3
           ext2 との高い上下互換性の為、取っつきやすい
           作業時間に対するC/P率が一番高い(すぐ設定できる割にそれなりの安全性)
        • ReiserFS
           スクラッチから作られ、高性能及び高機能のため将来性十分
           ext2 との相互互換性はないのが多少難点
        • XFS
           基本的にSGI 自身による移植。開発チームの一部ごたごたがあったにもかかわらず存続している
           SGI のマシンで培われた信頼性が維持できれば有望株となれるはず
          # すんません、使ってないのでよく知りません(^^;;)
        # 誤解など誤情報を含んでいる可能性高
        --
        # rm -rf ./.
        親コメント
        • > えーと、運が良いですね(^^;;)

          なるほどそうかも。

          XFSについてはほとんど情報を持っていませんが、一度だけ試したことがあります。確かカーネルモジュールがReiserFSとext3よりも相当に大きかった覚えがあります。単なるモジュールのサイズなので稼働時のメモリ消費量を表すわけではありませんが。

          XFSはもともとSGIのWS用に設計されているので、常時大量のメモリを確保して性能を発揮するような構造を持っていたように思います。だとすると、高性能なファイルサーバなどには向いているけど資源の貧弱な環境には厳しいのでは?
          # 誤解かもしれないので識者のツッコミ希望
          親コメント
          • by tanh (4900) on 2002年09月19日 0時36分 (#168405)
            > 資源の貧弱な環境には厳しいのでは?

            XFS のメーリングリストでは、486DX4(100MHz), メモリ24MBの
            マシンでカーネルをコンパイルしたとき、ext2 よりも XFS を
            使った方が (少しだけ) 速かったという報告がされていました。

            ストリーミングデータを扱うのでなければメモリ16MBでも動作に
            問題はないだろうということです。
            親コメント
        • 捕捉。とんだ~とかはReiserFSの話です。
          --
          # rm -rf ./.
          親コメント
          • 実体験しました。。 2GB超のファイルを置くためにSambaをReiserFSで使っていて、二度ほど飛びました。(Vine 2.5, Samba 2.3.xだったかな)
            • ReiserFS+NFS で填った、とかいうはなしがあります
              --
              # rm -rf ./.
              親コメント
              • by cyber205 (4374) on 2002年09月18日 21時46分 (#168275) ホームページ 日記
                > ReiserFS+NFS で填った、とかいうはなしがあります

                極端に遅くなるらしいですな。あんまり気にしてないけど。
                (多分、10BASE-TでLAN組んでるからだと思いますが)

                ツールが揃っていて安定感があって、一番使いやすいのは
                ext3じゃないかな。うちは古くからサーバにしてたマシンとかの
                大きなパーティションを、カーネルとツールを入れ換えて
                順次ext3にアップグレードして使ってますよ。

                信頼性の必要な既存のサーバに導入するのならお勧め。
                ジャーナリングがメタデータだけでなく、
                ファイルそのもののデータにも効くのも特徴です。
                ただ、ジャーナリング処理の分、ext2よりも遅いですけど。

                まぁ、僕の場合はslackベースのplamoを使ってましたから、
                これが一番やりやすかったというのもあるかも。

                XFSは大容量ファイルを扱うのに長けているので、
                巨大なムービーとか、でかいデータベースとかの
                大きなデータをガンガン使う用途にいいみたい。

                Reiserfsはこまごましたファイルを高速に操作するのが
                上手みたいなんで、コンパイルの時に威力を発揮します。
                # ただ、ReiserFSはフルに常用すると、なんか不安定っぽい。

                よって、基本はext3、大容量ファイルストレージにはXFS、
                ゴリゴリコンパイラで開発する部分にはReiserFSって感じかな。
                親コメント
              • > 信頼性の必要な既存のサーバに導入するのならお勧め。

                本当に信頼性ってありますか?
                この辺り、ちょっと疑問なんですが。

                # 普段はsoftupdatesなFreeBSD User
              • この場合の信頼性は他(reiserfsやXFS)に比べるとってことでしょ。
                じゅうぶんな動作実績のあるext2に+αしただけなんで、歴史の浅いreiserfsなんかよりは安心できるって程度の話。

                # FreeBSDマンセーなやつはウザイ。
    • 比較検討してるページがいくつかあるので、それを参考にすると良いと思われ。
      ってことで、ここでURIをいくつか貼るべきなんだけど、ブックマークしていたページがことごとく404……。

      ……わたしゃXFS使ってます。って、これじゃ何の参考にもならないわな。
      親コメント
    • ext3 とその他の2つ ReiserFS, XFS との違いで個人的にでかいなと感じたのに、ReiserFS, XFS ではinodeの管理にbtreeが使われているというのがあります。
      このため1つのdirectoryに沢山のファイルが出来るような 使い方をする人はReiserFS か XFS を使うと幸せになれるのではないかと思います。適当なdirectory に20,000くらいファイルを作って ls とかしてみるとパフォーマンスの違いを体感出来ます。
      親コメント
    • Network Applicance製のWAFLを知ってからというもの、ログ構造化ファイルシステムに興味があるのですが、Linuxのファイルシステムにはこの実装はあるんでしょうか? 将来、Reiser4では導入されるみたいですが。
      • もはや開発されていないようですが、LinLogFS [tuwien.ac.at]なんていうものがあるようです。
      • LFS はVMのサポートがかなりないときついから、2.4.*の時みたいにVMがぐるぐる変わると誰も近寄れないんじゃない?少なくともしばらくの間は。

        ちなみにWAFL って、daemon本とかに載ってる LFS と違うよね。

        Pre 型の Journal を RAM-DISK に書いて(バックアップにバッテリーが載ってるらしい)、そこから先を完全非同期にしてるし、

        巨大な単位で IO できるように IO の単位が大きくて、その中ではデータをなるべく連続
        • どうしてもRAMディスクのデータ保障は普通のPCベースではまね出来ないなー。

          ファイルのバージョン管理なり自動バックアップを効率よくやろうと思うと、どうしてもログ構造化ファイルシステムあたりに行き着いてしまう。

          • > どうしてもRAMディスクのデータ保障は普通のPCベースではまね出来ないなー。 PCI ボード型になっている RAMDISK+Battery Backup ボードはあるようです。NetApp 製品も実はPCにこのボードつけて、Raid4をつないだだけっぽい(中は一度しか見たこと無いが)。 RAMD

私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike

処理中...