パスワードを忘れた? アカウント作成
3920 story

Linus、XFS を 2.5 カーネルにマージ 63

ストーリー by kazekiri
まだ恐いな~ 部門より

Anonymous Coward曰く、"SGI のジャーナリングファイルシステム XFS が Linus の BitKeeper tree にマージされました。"

本家でも LWN.net での記事を引用して2.5.36カーネルでマージされることが 報じられている。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by ramsy (8353) on 2002年09月18日 15時38分 (#168068) ホームページ 日記
    出てます

    Andrew Morton akpm@digeo.com:
        o low-latency zap_page_range
        o resurrect /proc/meminfo:Buffers
        o hugetlb pages
        o fix reverse map accounting leak
        o add /proc/meminfo:Mapped
        o ext3 ceanup: use EXT3_SB
        o hold the page ref across -readpage
        o fix a bogus OOM condition for __GFP_NOFS allocations
        o clean up the TLB takedown code, remove debug
        o add dump_stack(): cross-arch backtrace
        o various small cleanups

    cattelan@sgi.com:
        o XFS: "AutoVersion"

    Christoph Hellwig hch@sgi.com:
        o XFS: update pagebuf comments
        o XFS: Return -ENOMEM on vmap failure in _pagebuf_lookup_pages
        o Import XFS CVS from 10092002

    Peter Anvin hpa@zytor.com:
        o CPU detection fixes

    James Simmons jsimmons@maxwell.earthlink.net:
        o These files missed the handle_sysrq change
        o Removed selection.h header. It is not needed and in the future
            selections will be a pure userland solution. Use set_current_state
            instead in tty_ioctl.c
        o Renames console.c and vt.c. The idea is to break these massive
            files into smaller ones. The main goal is to move all the high end
            tterminal emulation into one file. This way we can have a light
            weight printk without the extra weight. nice for embedded systems

    Mark Lord lord@sgi.com:
        o XFS: remove dead code paths from create/mkdir/link/symlink
        o merge xfs up to 2.5.35

    mark@alpha.dyndns.org:
        o ov511 1.62 for 2.5.34

    pdelaney@lsil.com:
        o Fusion-MPT driver update

    stern@rowland.harvard.edu:
        o USB storage: Merging raw_bulk.c with transport.c

    Anton Altaparmakov aia21@cantab.net:
        o NTFS: Pages are no longer kmapped around calls to

    Ben Collins bcollins@debian.org:
        o IEEE-1394 updates

    David Gibson david@gibson.dropbear.id.au:
        o Remove CONFIG_SMP around wait_task_inactive()

    David S. Miller davem@redhat.com:
        o sparc64 2.5.x file corruptions found

    David Woodhouse dwmw2@infradead.org:
        o Add three functions for rbtree manipulation -- rb_next(), rb_prev()
            and rb_replace_node()
        o Remove bogus rb_root_t and rb_node_t typedefs in favour of 'struct
            rb_node' and 'struct rb_root' Remove duplicate implementation of
            rb_next() in net/sched/sch_htb.c while we're at it.

    Eric Sandeen sandeen@sgi.com:
        o XFS: teach icmn_err about CE_WARN
        o XFS: change symlink perms to 777
        o XFS: add error checks to linvfs_direct_IO

    Greg Kroah-Hartman greg@kroah.com:
        o USB: change the contact email address for the omninet driver
        o Driver Model: add dev_get_drvdata() and dev_set_drvdata() functions
        o Driver Model: fix oops when device is removed from system
        o USB: Convert the core code to use struct device_driver
        o USB: convert usb-serial drivers to new driver model
        o USB: convert the drivers/usb/class files to the new USB driver
            model
        o USB: convert the drivers/usb/image files to the new USB driver
            model
        o USB: convert the drivers/usb/input files to the new USB driver
            model
        o USB: convert the drivers/us
    --
    # rm -rf ./.
    • Re:長い… (スコア:1, 参考になる)

      by Anonymous Coward on 2002年09月18日 20時55分 (#168243)
      ポインタだけでいいんでないの?
      全文に目を通す人なら、アンカーぐらいクリックしてくれるさ。
      親コメント
      • by Anonymous Coward
        どのみちお尻切れてるし。

        詳細なChangeLog欲しがるような人は kernel.orgか、bk changes
        で見てるんじゃないの?どうせ。

        # 無意味な全文引用の代表だな、こりゃ。
      • by Anonymous Coward
        自ページへのリンクは知らせてくれと書いてある。
        つまり、ChangeLogへのリンクにも許可が必要だと考えたってことさ。
  • 激ウレシー!!! (スコア:2, 参考になる)

    by Digitune (119) on 2002年09月18日 22時57分 (#168315) ホームページ 日記
    / パーティション一つしかない Debian マシンをちょっと前に XFS
    にして以来、IEEE1394 経由の外付け HDD も含めて全て XFS Only
    で使ってきた身としては、本当に嬉しいです。ARMA だけじゃなく標準
    で採用してくれる Distribution が増えるといいなぁ。

    fsck が超早い、というジャーナリングのメリット以外に、明らかな
    メリットを感じたことは実はあまりないんですけどね。ext2 との比較
    では、普通に使っている分には体感できるほどの性能差はない感じ。

    PCMCIA の無線 LAN カードのドライバが調子悪くて kernel が panic
    した時に、直前に編集した /etc/default/pcmcia ファイルが、サイズ
    は変わらないながら中身が全部 '\0' になってしまったことがあって、
    「セキュリティ上の配慮?」なんて思ったこともありました。4ヶ月ほど
    使っていますが、この件以外ではファイル消失などのトラブルは一切な
    いです。ナカナカ安定してますよん。
    --
    Only Jav^Hpanese available :-)
    • 「'\0' でファイルが埋めつくされる」件は、上で紹介されている IBM
      の文書で XFS 1.0 の不具合として紹介されていましたね (^^;。

      つい先日 2.4.19+最新の XFS パッチにバージョンアップしたところな
      のでこの問題ともオサラバできる…かな?
      --
      Only Jav^Hpanese available :-)
      親コメント
    • by chui (460) on 2002年09月18日 23時49分 (#168364) ホームページ
        fsck が超早い、というジャーナリングのメリット以外に、明らかな メリットを感じたことは実はあまりないんですけどね。ext2 との比較 では、普通に使っている分には体感できるほどの性能差はない感じ。

      ですね。ext2 自体ジャーナルじゃないだけで、普通のデスクトップとして使っている分には全然見劣りしません。 でも、XFSがマージされたことはうれしいです。 これでようやく、kernel のバージョンアップが非常に楽になる。
      XFS を /home にしてるので、普通に kernel.org からソース落して、
      カーネルの最構築をしても、
      kernel panic という状態 ー> 手で渋々マージ
      という作業から解放されるので。

      #パッチ当てればいいじゃんと思うかも知れないけど、なんとなく、一からコンパイルし直したいし、ブート時にカーネルのバージョンを選択したいので。
      親コメント
    • by Anonymous Coward
      以前何となくですがXFSのfsck、fsck.xfsのソースをみてみたことがあります。main関数の中には唯、以下の1行が書かれているだけでした。

      return 0;

      をを・・・。
      XFSも以前使ってましたが、トラブル等は(カーネルが
      • XFSにはxfs_repairというコマンドがあって、これがfsckの代わりになります。
        親コメント
      • by Anonymous Coward
        reiserfsってマルチプロセスで読み書きすると極端に遅くならない?
        今は違うのかな。
      • by Anonymous Coward
        オンラインマニュアルにも
        "fsck.xfs simply exits with a zero exit status."
        って書いてますね。

        先日新しいHDDを取り付けて xfs にフォーマットしましたが、
        一瞬で終りました。しかし、よくわかってませんがbad block
        のチェックはどうすりゃよかったの
        • by akiu (7087) on 2002年09月19日 20時57分 (#168804) 日記
          badblocksってコマンドがあるけど、ext2以外で使えるかは不明。ファイルシステムを作成する前に使用すればいいだけだけど。
          ただ、DOSのformat.exeが検出した不良ブロックを検出できなかったことがあるんだよね。format.exeが誤検出してる可能性もあるけど、ちと怖いんでwindowマシン(ゲーム用なんで壊れてもOK)で使用してる。
          親コメント
  • by yakusouX5 (8222) on 2002年09月19日 16時07分 (#168691) ホームページ 日記
    vfatが良いよ!
    --
    うすっぺらいコメントがあらわれた! ▼
  • 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回目ですか?
                #教えてもらってもすぐ忘れる奴>わし。
                親コメント
        • >> softupdateは…? 鰯の頭
    • 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 とかしてみるとパフォーマンスの違いを体感出来ます。
      親コメント
typodupeerror

日々是ハック也 -- あるハードコアバイナリアン

読み込み中...