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

NTTが耐障害型ファイルシステムNILFSをリリース 99

ストーリー by yoosee
もっと高信頼、もっと高品質 部門より

ramsy曰く、"NTT研究所のニュースリリースによると、同研究所は、スナップショットを常時連続で取得することで耐障害性を高めたファイルシステム「NILFS」を開発し、GPLv2で公開した。NILFS は今年 6月に行われた Linux Conference 2005 で発表(PDF) されていた。

このファイルシステムは、データの追加や変更分をチェックサム付きでディスクの空きスペースへ常時書き込む事がミソのようだ。 TODOに上げられているとおり、bootloaderサポートなどまだまだ未実装なところが多いが、将来性は十分にあると思う。いつの日かKernel Treeにマージされる事を心躍らせて待つこととしたい。 なにはともあれ日本発だ。さぁ hack hack hack!"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by densuke (113) on 2005年09月27日 10時30分 (#805143) 日記
    ということで使ってみました。カーネルは2.4.14-rc2-mm1です。
    LVM環境なんで、論理ボリュームを作成し、mkfs.nilfsでフォーマットしてからマウントして、ちょっとファイルを作成したり。

    チェックポイントはinspectコマンドで取得でき、マウント中でもかまわないみたい。

    % sudo /sbin/inspect /dev/mapper/system-nilfstest
    magic 0x3434 rev 1.0
    block_size 4096
    s_nsegment 256 segment chunk 2
    s_blocks_per_segment 1024
    s_crc_seed 0xecc339c3
    s_last_segment [blk#] 63
    s_last_seq [seq#] 0
    nilfs> listcp
                      1 6 Mon Sep 26 21:48:35 2005 MajorCP|LogiBegin|LogiEnd
                      7 8 Tue Sep 27 10:04:19 2005 MajorCP|LogiBegin|LogiEnd
                    15 10 Tue Sep 27 10:04:29 2005 MajorCP|LogiBegin|LogiEnd
                    25 8 Tue Sep 27 10:04:29 2005 MajorCP|LogiBegin|LogiEnd
                    33 4 Tue Sep 27 10:04:29 2005 MajorCP|LogiBegin|LogiEnd
                    37 8 Tue Sep 27 10:05:52 2005 MajorCP|LogiBegin|LogiEnd
                    45 10 Tue Sep 27 10:05:54 2005 MajorCP|LogiBegin|LogiEnd
                    55 8 Tue Sep 27 10:05:59 2005 MajorCP|LogiBegin|LogiEnd
                    63 4 Tue Sep 27 10:05:59 2005 MajorCP|LogiBegin|LogiEnd
                    67 8 Tue Sep 27 10:07:50 2005 MajorCP|LogiBegin|LogiEnd
                    75 10 Tue Sep 27 10:07:51 2005 MajorCP|LogiBegin|LogiEnd
                    85 8 Tue Sep 27 10:07:51 2005 MajorCP|LogiBegin|LogiEnd
                    93 4 Tue Sep 27 10:07:51 2005 MajorCP|LogiBegin|LogiEnd
                    ↑
                これがチェックポイント番号
    nilfs> quit

    で、番号を確認したところで

    # mount -t nilfs -o cp=????(チェックポイント番号) -r /dev/でばいす /mnt/どっか

    でマウントできます。利用中のパーティションでもそのままできますが、読み込み専用で行いましょう(snapshotに書き込めたらヤバイでしょ、たぶん安全装置があるだろうけど)。

    LVMではスナップショット機能を使って、対応しているファイルシステムのスナップショットを取って同様のことができます。パーティションの容量が残っている限り、いくらでもスナップショットが取れるので(LVM snapshotはVGの空き領域から待避領域を追加して行う)ある程度の使い分けをすれば便利かもしれません。
    今のところチェックポイントをコマンドラインから簡単に取得する方法がない(inspectで対話的にしか取得できない)ので、自動的にチェックポイント番号を確認して最新のポイントをマウントすることが難しいのですが、ツールの充実に伴い解決していくかと思われます。

    あと、各チェックポイントの間でなにがあったのかがもう少し具体的にわかるようにしてほしい気がします(ファイルを作った、消した、いじったとか)、ってこれができるとファイルシステムがchangesetのかたまりになるのか?

    とにかくこれから進化していって、カーネルに組み込まれるとうれしいかな。
    --
    -- やさいはけんこうにいちば〜ん!
  • なんで (スコア:3, おもしろおかしい)

    by Anonymous Coward on 2005年09月27日 0時45分 (#804975)
    NTTFSにしなかったんだろう
  • おや (スコア:3, 興味深い)

    by ncube2 (2864) on 2005年09月27日 8時53分 (#805097)
    数年前にNTTの研究所の人から「これはもう商用にはしないから、本当はフリーで公開したいんだけど、NTT分割絡みで『研究所の成果は事業会社に貢献すべし』となって、フリーでの公開が困難になった」と聞いたことがあるのですが、今はフリーで公開もOKになったのかな?
  • by Anonymous Coward on 2005年09月27日 0時25分 (#804963)
    ランダムデータで埋めた小さなファイルをひたすら
    作っては消し、作っては消しを繰り返し、
    ディスクの空き容量をあっという間に消費させ、
    古い記録が追い出されてなくなったところで本格的な破壊活動に、
    というのはどうでしょう?
    • ウィルス仕込む以前にDoS対策をどうしているかが興味あります。
      ウィルスを仕込むのにそこまで細かいことしなくてもいいだろうし、そこまでやってもバックアップをアプリ層でやっていればその手の手法への防御は出来る。
      それよりもどっちかというとファイルシステムをアップデートできないようなDoSをやる方が容易な感じがするんですけど…

      親コメント
    • ファイルシステムをクラッシュさせるのは追いかけっこですしねー。
      出てくるでしょうね~。 たぶん。

      それはそれとして、
      > データの追加や変更分をチェックサム付きでディスクの空きスペースへ

      これが有効に機能するためには、予定使用容量の何倍のディスクが必要ななんだろ。
      みんなが、膨大なネットワークストレージ抱えてる訳じゃ無い訳からね~。
      --
      hoihoi-p  得意淡然、失意泰然。
      親コメント
  • 課金向け (スコア:2, 興味深い)

    by cljack (22418) on 2005年09月27日 0時51分 (#804981)
    読み込み性能を捨てて追記性能に特化したファイルシステムですね.
    ディレクトリ構造が作れるテープと考えればよいのかな?
    任意の時点に戻せるっていうのも「GCが必要」を裏返して言っているだけの気がする.

    課金の為のロギング用だね.
    ホットスワップできるようにしておいて,定期的にバッチ用マシンで処理すると…
    ほかに用途が思い浮かばない.
    • Re:課金向け (スコア:2, 興味深い)

      by shojin (28072) on 2005年09月27日 11時40分 (#805176) 日記
      課金向にしてしまうとファイル作成、追記のたびにfsyncしないと
      いけないけど、そうするとfsyncが多過ぎて思ったように性能が
      出ないということになりそうな気がする。
      Log-structured Filesystem (LFS) ではfsyncをするとinodeの
      位置を示すファイルを末尾に書き込む必要があるからね。
      LFSの発想は大きなメモリを持っているマシン上でディスク
      書き込み速度を活かすということなので読み込みが多少遅いのは
      仕様と言っていいと思う。
      でも、長時間稼働させれば良く使うデータはバッファキャッシュ
      上に乗ると思うから結果的に大抵のディスクアクセスはそんなに
      遅くはならないのではないかと思う。

      今まで出来てる実装までだとまだLFSの恐ろしさに入ってないね。
      LFSはもともとSpriteOS、4.4BSDで開発されて来たけど、
      この系列で使える状況になっているのは恐らくNetBSDだけ。
      兄弟OSであるFreeBSDでは使われなくなったブロックの
      ガーベッジコレクションをするCleanerの実装が難し過ぎて
      バグバグだったから匙投げちゃった (CVS treeから抹消) と
      いう歴史がある。
      そこんところ、NetBSD LFSv2も含めてどう対応してくるかが見物。
      親コメント
      • by Vorspiel (2391) on 2005年09月27日 12時27分 (#805207) ホームページ

        NILFSのサイトからリンクされてるWikipediaエントリ [wikipedia.org]によると

        It appears to be no longer completely functional as of NetBSD 2.0.2, having not been maintained for many years. There has been work, however, since in the recent 3.0 branch to bring the file system back up to production standard.

        だそうで.現状「使える」とは言いがたい(3.0までに何とかしようという)状況かと.

        親コメント
    • ネトゲ屋に売り込むのかなぁ。

      # え、エロサイト?
      --
      まぐろたべたい
      親コメント
    • by mr_spock (908) on 2005年09月27日 2時26分 (#805032)
      ネトゲ屋てのは、なかなかいい目の付け所カモ。
      しかし、ネトゲもリアルタイムな書き込み性能が重要なのでゲームサーバ向きではないかと思われ。
      ネトゲ利用にしても課金システムが落としどころなんじゃないかしら。
      親コメント
  • Plan9のファイルシステムもこんなかんじだったと思うのですが、
    変更履歴を残しておく必要のある重要なファイルと一時的なファイル
    (たとえばコンパイル時に一時的に作られるファイルとか、Webブラウザが
    勝手にキャッシュするエロ画像など)との区別はするのでしょうか。
    区別をしないとすぐディスクがいっぱいになってしまうと思います。
    アプリケーション側で重要/非重要の属性を付けろというのは酷ですし、
    一時ファイルの拡張子を登録しておくのも漏れが出てきそうです。
    --
    love && peace && free_software
    t-nissie
    • 例えば、今では同期I/Oと非同期I/Oを使い分けられるOSがほとんどだと思います。アプリケーション自身が区別するというのは悪くないと思いますよ。
      あるいは、あるアプリケーションの使用するファイルに最適なファイルシステムを選択することは運用上良くやりますよね。
      親コメント
    • by Anonymous Coward on 2005年09月27日 11時06分 (#805159)
      大抵のOSは複数のファイルシステムを使い分けられますから、マウントポイント(ディレクトリの位置)で区別してAPIでは区別しないというのが現状の方針ということで。

      # テンポラリディレクトリ / MyDocuments / Program Filesという区切りがさらに増える感じ
      # 要は、すべてを同じFSで賄う必要は無いと。

      ちなみに、いわゆるLFSの仕組み自体はけっこう歴史長いのでその辺の心配は大丈夫です。余った領域を回収する処理が結構重いって問題はありますが、そもそもHDDの残りを気にするようなタイプの人にには向きません。
      逆に、やる気になれば後からFSの容量を増強することが可能です。

      Plan9だと古いデータはCD-Rのようなライトワンスメディアに捨てていけばいいじゃんという発想。
      親コメント
    • by Anonymous Coward on 2005年09月27日 11時23分 (#805167)
      Plan 9は、昔はWORM(Write Once Read Many)ストレージ(CD-R Jukeboxとか)に変更をガンガン書き込んでた。
      上書き禁止……というか上書きが無理なメディアに、過去から現在までの全ての状態のファイルが保存されている。
      「ストレージが溢れたら? その頃にはもっと容量の多いストレージが安価で買えるはずさ」って言う思想(今から10年くらい前)

      最近は、VentiっていうBlock Level Strageをバックエンドストレージに使う。(File Levelじゃなくてね)
      スナップショットは、長期的(永久的)な物を長めのスパン(1日1回とか)で取るのと、短期的なものを頻繁に(1日経ったら消すようなスナップショットを5分に1回とか)取るのを組み合わせたりとか

      ただ、その主目的は多分、人間にとって過去のファイルがいつでも使える事であって
      ファイルシステムの信頼性向上自体を目的としてるわけじゃない
      NILFSとはやっている事は似ていても、目的が違うんじゃないかな
      親コメント
  • by Anonymous Coward on 2005年09月27日 3時26分 (#805045)
    カーネルパニックでの停止とか、メモリ不良といったハードウェアのトラブルには効果がないのでしょうか?
    特にメモリの不良だと、FS自体のロジックがトチ狂ってしまって、結局データの破損につながってしまいそう。。。

    #ECC Registeredメモリが壊れてデータ破損のひどい目にあったのでAC
  • 好きな時にシステム構成へのコメントとか付けられたりすると、自宅マシンのスナップショット作成とかに便利そうですねぇ。
    開発現場でもls打ったら
    hoge.conf hoge.conf.orz_20050920 hoge.conf.orz_20050924 hoge.conf.orz_20050924_2 hoge.conf.orz_20050926
    な状態を減らせるかも…

    #間違ってJavaのアプリケーションサーバや普通のRDBとかを
    #乗せてしまうとすごいことになりそうですが…
    • データベースってのは要するに高級ファイルシステムですよね。 今後はWindows でWinFSとか、UNIX系の各種ジャーナリングファイルシステムとか、ファイルシステムの高級化により所謂データベースシステムとの境が曖昧になっていくと思います。
      親コメント
      • そうかなあ? 特定のファイルシステムに依存したアプリケーション開発が普及するなんて、想像できないな。ファイルシステムが高級化の方向へ進むであろうことには同意するけれど、DBMSとファイルシステムの境が曖昧になったりすることはないと思うよ。

        モデル駆動開発 [atmarkit.co.jp]こそが未来の開発スタイルだと思うんだけど、そこではファイルシステムやネットワークを抽象化するレイヤーがクラスライブラリで実現されることになると思うんだがな。そうなるとすれば、特定のファイルシステムにのみ存在する高級な機能はあまり利用されないはずだよ。

        親コメント
        • まず、これらのファイルシステムはDBエンジン自体が利用するんじゃないでしょうか。
          その次の段階として.NETやJavaなどのクラスライブラリによる抽象化が一般のユーザ向けに提供され、最後にPOSIXの様にカーネルAPIが標準化されるんじゃないかと思っています。
          そこまでくる、ユーザ数が限られるWebアプリ等を作るのにエンタープライズで使われるような本物のDB製品を使う必要はなくなっちゃうと思いますね。
          親コメント
        • by r5 (24383) on 2005年09月27日 11時49分 (#805182) 日記
          もともと、WinFSはYukon(SQLServer)と一体化した存在となる予定で、
          「select filename from 'C:\' where 概要 like 'slashdot'」
          みたいなアクセスや、それをラップしたAPI群を提供することで
          新しい次元のファイル管理を実現するというコンセプトのはず。

          さすがに標準化を図るにはまだまだ煮詰まってないでしょうから、
          今は独自実装で行くしかないんでしょうね。
          それはMSにとってはメリットなのでしょうし。
          次世代OSと次世代ファイルシステムと次世代開発環境を
          一気にリリースして、革命を起こす作戦は雲行きが怪しいですが・・・

          モデル駆動は、まだまだ汎用性を持たせるには夢の世界なので、
          とりあえず実現可能な次世代へのアプローチとして
          現実的な選択だと思いますよ。

          いやぁ、こんなに難航するとは思ってなかったんだろうけどさ。
          親コメント
  • 最初見た時、フラッシュを思い出しました。

    フラッシュは書き込み回数に制限がある為、
    上書きよりも別の場所に書き込む方が寿命が伸びるので。
    --
    TomOne
typodupeerror

身近な人の偉大さは半減する -- あるアレゲ人

読み込み中...