NTTが耐障害型ファイルシステムNILFSをリリース 99
ストーリー by yoosee
もっと高信頼、もっと高品質 部門より
もっと高信頼、もっと高品質 部門より
ramsy曰く、"NTT研究所のニュースリリースによると、同研究所は、スナップショットを常時連続で取得することで耐障害性を高めたファイルシステム「NILFS」を開発し、GPLv2で公開した。NILFS は今年 6月に行われた Linux Conference 2005 で発表(PDF) されていた。
このファイルシステムは、データの追加や変更分をチェックサム付きでディスクの空きスペースへ常時書き込む事がミソのようだ。
TODOに上げられているとおり、bootloaderサポートなどまだまだ未実装なところが多いが、将来性は十分にあると思う。いつの日かKernel Treeにマージされる事を心躍らせて待つこととしたい。
なにはともあれ日本発だ。さぁ hack hack hack!"
使ってみてナンボ (スコア:5, 参考になる)
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のかたまりになるのか?
とにかくこれから進化していって、カーネルに組み込まれるとうれしいかな。
-- やさいはけんこうにいちば〜ん!
Re:使ってみてナンボ (スコア:1)
-- やさいはけんこうにいちば〜ん!
なんで (スコア:3, おもしろおかしい)
Re:なんで (スコア:1)
Re:なんで (スコア:1)
#武蔵野の連中が騒ぎ出しそうな(笑)
/* Kachou Utumi
I'm Not Rich... */
Re:なんで (スコア:1)
Re:なんで (スコア:1)
フラグメンテーションが多発するのですね。
おや (スコア:3, 興味深い)
Re:おや (スコア:1)
研究開発費で損金処理したほうが、節税になるから...。
対耐障害型ファイルシステムクラッシュウィルス (スコア:2, 興味深い)
作っては消し、作っては消しを繰り返し、
ディスクの空き容量をあっという間に消費させ、
古い記録が追い出されてなくなったところで本格的な破壊活動に、
というのはどうでしょう?
Re:対耐障害型ファイルシステムクラッシュウィルス (スコア:1)
ウィルスを仕込むのにそこまで細かいことしなくてもいいだろうし、そこまでやってもバックアップをアプリ層でやっていればその手の手法への防御は出来る。
それよりもどっちかというとファイルシステムをアップデートできないようなDoSをやる方が容易な感じがするんですけど…
Re:対耐障害型ファイルシステムクラッシュウィルス (スコア:1)
出てくるでしょうね~。 たぶん。
それはそれとして、
> データの追加や変更分をチェックサム付きでディスクの空きスペースへ
これが有効に機能するためには、予定使用容量の何倍のディスクが必要ななんだろ。
みんなが、膨大なネットワークストレージ抱えてる訳じゃ無い訳からね~。
hoihoi-p 得意淡然、失意泰然。
課金向け (スコア:2, 興味深い)
ディレクトリ構造が作れるテープと考えればよいのかな?
任意の時点に戻せるっていうのも「GCが必要」を裏返して言っているだけの気がする.
課金の為のロギング用だね.
ホットスワップできるようにしておいて,定期的にバッチ用マシンで処理すると…
ほかに用途が思い浮かばない.
Re:課金向け (スコア:2, 興味深い)
いけないけど、そうするとfsyncが多過ぎて思ったように性能が
出ないということになりそうな気がする。
Log-structured Filesystem (LFS) ではfsyncをするとinodeの
位置を示すファイルを末尾に書き込む必要があるからね。
LFSの発想は大きなメモリを持っているマシン上でディスク
書き込み速度を活かすということなので読み込みが多少遅いのは
仕様と言っていいと思う。
でも、長時間稼働させれば良く使うデータはバッファキャッシュ
上に乗ると思うから結果的に大抵のディスクアクセスはそんなに
遅くはならないのではないかと思う。
今まで出来てる実装までだとまだLFSの恐ろしさに入ってないね。
LFSはもともとSpriteOS、4.4BSDで開発されて来たけど、
この系列で使える状況になっているのは恐らくNetBSDだけ。
兄弟OSであるFreeBSDでは使われなくなったブロックの
ガーベッジコレクションをするCleanerの実装が難し過ぎて
バグバグだったから匙投げちゃった (CVS treeから抹消) と
いう歴史がある。
そこんところ、NetBSD LFSv2も含めてどう対応してくるかが見物。
NetBSD LFS (スコア:1)
NILFSのサイトからリンクされてるWikipediaエントリ [wikipedia.org]によると
だそうで.現状「使える」とは言いがたい(3.0までに何とかしようという)状況かと.
Re:課金向け (スコア:1)
# え、エロサイト?
まぐろたべたい
Re:課金向け (スコア:1)
しかし、ネトゲもリアルタイムな書き込み性能が重要なのでゲームサーバ向きではないかと思われ。
ネトゲ利用にしても課金システムが落としどころなんじゃないかしら。
重要なファイルと一時的なファイルの区別はするのかな (スコア:2, 参考になる)
変更履歴を残しておく必要のある重要なファイルと一時的なファイル
(たとえばコンパイル時に一時的に作られるファイルとか、Webブラウザが
勝手にキャッシュするエロ画像など)との区別はするのでしょうか。
区別をしないとすぐディスクがいっぱいになってしまうと思います。
アプリケーション側で重要/非重要の属性を付けろというのは酷ですし、
一時ファイルの拡張子を登録しておくのも漏れが出てきそうです。
love && peace && free_software
t-nissie
Re:重要なファイルと一時的なファイルの区別はするの (スコア:1)
あるいは、あるアプリケーションの使用するファイルに最適なファイルシステムを選択することは運用上良くやりますよね。
Re:重要なファイルと一時的なファイルの区別はするの (スコア:1, 参考になる)
# テンポラリディレクトリ / MyDocuments / Program Filesという区切りがさらに増える感じ
# 要は、すべてを同じFSで賄う必要は無いと。
ちなみに、いわゆるLFSの仕組み自体はけっこう歴史長いのでその辺の心配は大丈夫です。余った領域を回収する処理が結構重いって問題はありますが、そもそもHDDの残りを気にするようなタイプの人にには向きません。
逆に、やる気になれば後からFSの容量を増強することが可能です。
Plan9だと古いデータはCD-Rのようなライトワンスメディアに捨てていけばいいじゃんという発想。
Re:重要なファイルと一時的なファイルの区別はするの (スコア:1, 参考になる)
上書き禁止……というか上書きが無理なメディアに、過去から現在までの全ての状態のファイルが保存されている。
「ストレージが溢れたら? その頃にはもっと容量の多いストレージが安価で買えるはずさ」って言う思想(今から10年くらい前)
最近は、VentiっていうBlock Level Strageをバックエンドストレージに使う。(File Levelじゃなくてね)
スナップショットは、長期的(永久的)な物を長めのスパン(1日1回とか)で取るのと、短期的なものを頻繁に(1日経ったら消すようなスナップショットを5分に1回とか)取るのを組み合わせたりとか
ただ、その主目的は多分、人間にとって過去のファイルがいつでも使える事であって
ファイルシステムの信頼性向上自体を目的としてるわけじゃない
NILFSとはやっている事は似ていても、目的が違うんじゃないかな
どんなトラブルでも保護される? (スコア:2, 興味深い)
特にメモリの不良だと、FS自体のロジックがトチ狂ってしまって、結局データの破損につながってしまいそう。。。
#ECC Registeredメモリが壊れてデータ破損のひどい目にあったのでAC
Re:どんなトラブルでも保護される? (スコア:1)
#レイヤが違うけど,RAIDを使っててもウィルスにやられたらアウトなのと同じこと.
ログファイルシステムはスナップショットが取りやすいので,バックアップもやりやすくていいんでないかな.
Re:どんなトラブルでも保護される? (スコア:1)
もっとも、メモリモジュール単位ではなくてメモリ増設ボード単位みたいですが。その機種(DL560,580,740,760)は故障時にHot plug/deplugもできるらしいです。
# rm -rf ./.
ファイルシステム版CVS? (スコア:1)
開発現場でもls打ったら
hoge.conf hoge.conf.orz_20050920 hoge.conf.orz_20050924 hoge.conf.orz_20050924_2 hoge.conf.orz_20050926
な状態を減らせるかも…
#間違ってJavaのアプリケーションサーバや普通のRDBとかを
#乗せてしまうとすごいことになりそうですが…
DB≒FS(Re:ファイルシステム版CVS?) (スコア:2, 興味深い)
Re:DB≒FS(Re:ファイルシステム版CVS?) (スコア:2, 興味深い)
そうかなあ? 特定のファイルシステムに依存したアプリケーション開発が普及するなんて、想像できないな。ファイルシステムが高級化の方向へ進むであろうことには同意するけれど、DBMSとファイルシステムの境が曖昧になったりすることはないと思うよ。
モデル駆動開発 [atmarkit.co.jp]こそが未来の開発スタイルだと思うんだけど、そこではファイルシステムやネットワークを抽象化するレイヤーがクラスライブラリで実現されることになると思うんだがな。そうなるとすれば、特定のファイルシステムにのみ存在する高級な機能はあまり利用されないはずだよ。
Re:DB≒FS(Re:ファイルシステム版CVS?) (スコア:2, 興味深い)
その次の段階として.NETやJavaなどのクラスライブラリによる抽象化が一般のユーザ向けに提供され、最後にPOSIXの様にカーネルAPIが標準化されるんじゃないかと思っています。
そこまでくる、ユーザ数が限られるWebアプリ等を作るのにエンタープライズで使われるような本物のDB製品を使う必要はなくなっちゃうと思いますね。
Re:DB≒FS(Re:ファイルシステム版CVS?) (スコア:2, 興味深い)
「select filename from 'C:\' where 概要 like 'slashdot'」
みたいなアクセスや、それをラップしたAPI群を提供することで
新しい次元のファイル管理を実現するというコンセプトのはず。
さすがに標準化を図るにはまだまだ煮詰まってないでしょうから、
今は独自実装で行くしかないんでしょうね。
それはMSにとってはメリットなのでしょうし。
次世代OSと次世代ファイルシステムと次世代開発環境を
一気にリリースして、革命を起こす作戦は雲行きが怪しいですが・・・
モデル駆動は、まだまだ汎用性を持たせるには夢の世界なので、
とりあえず実現可能な次世代へのアプローチとして
現実的な選択だと思いますよ。
いやぁ、こんなに難航するとは思ってなかったんだろうけどさ。
上書きじゃなくて空きスペースに書き込み (スコア:1)
フラッシュは書き込み回数に制限がある為、
上書きよりも別の場所に書き込む方が寿命が伸びるので。
TomOne
Re:上書きじゃなくて空きスペースに書き込み (スコア:2, 参考になる)
特別なドライバなどは必要無かったので、多分コントローラがやっているのだと思います。
Re:上書きじゃなくて空きスペースに書き込み (スコア:1, 興味深い)
容量ギリギリまで使った所で
読み書き消しを繰り返すと局地的に寿命が短くなっちゃうのかな…
Re:日本発 (スコア:1)
例えば?
Re:日本発 (スコア:1)
Re:日本発 (スコア:1)
BTRO(ry って言うならまだ分かりますが。
> 国産に拘っているソフトウェア自体がそんなに無い予感
この点は同意。
TRONは例外的に国産に拘っているソフトウェアなのでは。
国産に拘っているソフトって他に思い当たらないんですが。
Re:日本発 (スコア:2, 興味深い)
リソースの少ないMCUではITronは使えるOSの一つではあったけど、カーネルAPIしか統一されておらず、実装ごとにミドルウェアが違うわ、特権プロセスの概念がなくて一個のアプリケーションプロセスが死ぬと他も巻き込まれる場合が結構あるわで、2001年頃には既に開発工数の足を引っ張る代物になっていた。
そのあたりはかなり解消されているようですが…今からITron使うならせめて(特権モードなかった気がするけど)eCosあたりのTronエミュレーション使わせてくれ…と言うのが本音です。
Re:日本発 (スコア:1)
そもそもI-TRONは規格だけだったのが大きいのでは無いでしょうか。
その反省に立ってT-Kernel [t-engine.org]なんてのが出て来てるわけで。
> eCosあたりのTronエミュレーション使わせてくれ
いや、eCosもI-TRON v3相当のAPIを実装しているI-TRONの一つの実装なのでは。
まあ、エミュレーションという表現もあながち間違っては居ないと思いますが。
Re:日本発 (スコア:1)
>いや、eCosもI-TRON v3相当のAPIを実装しているI-TRONの一つの実装なのでは。
まぁ、そうなんですけどね、独自のAPI部分が国内メーカのTronよりもマトモなのと、eCosのカーネルAPIやnewlibなどでアーキテクチャに依存しないAPIや開発環境を供給していますから…
国内メーカのTron v3は、MCUアーキテクチャごとに違うAPIだったりミドルウェアが違ったりするうえにコンパイラやアセンブラにもそれぞれ癖があったりして勉強するだけでも一苦労でしたので…くだらないところで時間を喰っていましたから。(-_-;
Re:日本発 (スコア:1)
コアなファンが一部いる割には、日の目を見ないB-TRONはかわいそうに思えます。
でも、NTTの交換機とかで採用されていたC-TRONとかの活躍を考えれば、そっちの方が地味すぎるよなぁ…
はっ、まさか、NILFSはキャリアグレード…
/* Kachou Utumi
I'm Not Rich... */
Re:日本発 (スコア:1)
ハイフン余計。ITRON/BTRON/CTRONですね。
# LINAXと書くのと同程度にアレだと思う。
from もなか
Re:日本発 (スコア:1)
/* Kachou Utumi
I'm Not Rich... */
Re:日本発 (スコア:1)
LINAXと書いてある資料は私もよく見ますが、焼きつくことはありませんでした。
from もなか
Re:日本発 (スコア:1)
・日本発・日本製であることにこだわっているソフトがある
・これらのソフトにはまともなものはない(=全てろくでもない)
という話で、そうこき下ろすからには色々と思いあたるものも
あるわけでしょ。
じゃあどういうソフトがそうなのかご高説をうけたまわって
あげますよ? というわけで。
>でも、ないよね。
ってのは、「日本発とかうたうソフトはないよね」ということなのか
「日本発などとうたっているソフトの中でまともなものはやっぱり
ないよね」のどっちなんでしょう?
Re:日本発 (スコア:1, すばらしい洞察)
「日本発」ってのはマルチバイト文字対応がしっかりしてて、
素人が何も考えずに利用出来ると言う意味を持っている。
それはそれで素晴らしい事だと思う。
Re:日本発 (スコア:1)
Re:日本発 (スコア:1)
(年寄りの戯言)
Re:日本発 (スコア:1)
/* Kachou Utumi
I'm Not Rich... */
Re:日本発 (スコア:1, おもしろおかしい)
Re:GPLv2? (スコア:2, 興味深い)
# rm -rf ./.
Re:教祖様降臨希望 (スコア:1)
品質はテストしてみないとわからない。まだソースは見ていない。
Project DOUBT はまだこのファイルシステムについて何もやってません。何か見つかったら、Project DOUBT のページで報告される事でしょう。
VM周りのバグの影響を一番強く受けるFSなので、テストするといろいろ新しいものが発見できそうで、その意味では他のFSより期待大です。
すでに判っている最大の弱点は…1024bit FS じゃないことかな。
fjの教祖様