Windowsからファイル・ツリーが消える日 96
大きな前進…の予感 部門より
同ネタでたくさんのタレコミをいただいたが、一番早かったbrake-handle曰く、"ZDNetの記事によると、Microsoftは次期Windows「Longhorn」でファイル・システムの刷新を計画している。その特徴を一言でいうと「データベース」。ファイルの内容は全てformalに記述されている。その上でファイルの内容をDBMSがアクセスすることにより、名前空間の中からファイルを捜し出すというもの。
...grep(1)した方がずっと楽でないかい?"
ファイル・システムのDBMS化はこれまでにも試みられてきた。初期のBeOSやOSレスOracleも亜種として数えられるだろう。しかし過去の事例とMicrosoftのそれでは事情が異なる。MS OfficeやIEがXMLに対応し、.NET構想を謳っているMicrosoftなら、より今日的かつ実用的な仕上がりを期待できるからだ。後は信頼性と互換性だが。…
なおタレコミニスト毎に切り口が違い、興味深いコメントが多かったので併せて紹介する。
Joga曰く、"実現できればすばらしいことだと思うが、果たして実現できるのだろうか?また、実現したとしてもアプリの互換性に問題が出そうで、かなりの混乱が予想される。MSは、多くの問題をクリアしてこの新ファイルシステムを提供することができるだろうか?"
white 曰く、 "技術自体に新味は感じないが、実際に広く使われるOSで実装するとなれば、なかなか挑戦的な試みだと思う。
実際、既存の様々なファイルシステムは、拡張性という点ではかなり劣悪。ところがオブジェクト指向なファイルシステムなら、必要に応じて「ファイル」の構造そのものを拡張できてしまうはずだ。
初期バージョンが不安定でさえなければ面白いチャレンジだと思うのだが、どうだろう。個人的には、定説通りに3世代後のWindows系OSに期待、ってところ。"
こういう製品構成はどう? (スコア:5, おもしろおかしい)
マルチタスクだけどシングルタスクしか許さない・・
"MDBベースのファイルシステム"を採用したホームエディション
マルチタスクだけど5タスクまでの制限をかけられている・・
"MSDEベースのファイルシステム"を採用したプロフェッショナルエディション
ほんとにマルチタスクでタスク制限なし・・
"SQL Serverベースのファイルシステム"を採用したエンタープライズエディション
でもってお値段は1/3/200(単位は万円)って事でよろしく。
ファイルシステムを変更することに関しては賛成ですが、ほんとにここまで変わるのであれば互換性は捨ててくださいと言いたい。但し、WindowsXPだけでもいいからサポートは20年はやってくれ。
#20年の基準はおれが現役でがんばりたい年数だ
職業としてのプログラマ
期待はもてる、しかし・・・ (スコア:3, 興味深い)
しかし、以下のような点が問題になってきそうな気がします。
Re:期待はもてる、しかし・・・ (スコア:5, 参考になる)
いちばん恐れてるのは、ファイルシステムそのものに何か特許技術が使われてしまい、そのために、Linux や BSD からそのファイルシステムを扱うためのドライバを書くことができない、という状況です。
Re:期待はもてる、しかし・・・ (スコア:1)
Re:期待はもてる、しかし・・・ (スコア:1)
今調べてみたところ、2003年6月19日に切れるようです。
Re:期待はもてる、しかし・・・ (スコア:1)
Re:期待はもてる、しかし・・・ (スコア:3, 参考になる)
既存のファイルシステムもある意味非常に制限されたDBMS と言えなくはないわけで、それをより高度なDBMSに置き換える というのは自然な方向であるとは思います。
実際、業務で大量のデータを扱っていると、ファイルシステムが DBMSだったらと思うことは多いです。検索というより、メタデータ による分類ができることが重要ですね。 例えば大量の文書を、作成日時による 年/月/日という階層で見たり、部門/案件という階層で見たりしたい、とか。findやgrepではデータ量が多くなると実用になりませんし、 リンクでどうにかしようとしても、ルールに従わない アプリケーションが一つでもあると整合性が崩れてしまう。
思い余ってNFSを細工したり、libc.soを置き換えて ファイルアクセスを乗っ取るというようなことも 試してみましたが、アドホックなアプローチではあちこちに 限界が出て来ます。なにより、既存のファイルシステムと 同等の信頼性と性能を実現できるのかというのが一番の 問題点でした。 業務で既に普通のファイルシステムの性能を 目一杯のところまで使っているので、性能を落すことは 許されないのです。
MSがそれを解決できる目処があるならいいんですが。
Re:期待はもてる、しかし・・・ (スコア:1)
こういうことすると『permission』という概念と真っ向から対立してるみたいな。
むしろ (スコア:2, 興味深い)
DBが介在する分、普通のファイルシステムよりきめ細かく 拡張性の高いパーミッションコントロールができるはず… 理屈では。
現実には、ファイルのパーミッションなんて概念は ユーザのメンタルモデルがある程度出来上がってしまってて、 複雑なことをしようとするとユーザがついてこれないという ことはありますね。
これまでファイルシステムを賢くしようとした製品が 結局広く受け入れられなかった一因に、何でもできるようにすると ユーザがどうしたら良いのかわからなくなってしまうという 問題があるのかもしれません。
Re:期待はもてる、しかし・・・ (スコア:2, おもしろおかしい)
#どの程度にてるでしょうね?
内容には (スコア:3, すばらしい洞察)
互換性うんぬんの話も出ていますが、基本的に互換性の維持は難しいでしょう。
あえて互換性にとらわれずにやる勇気が必要かもしれません。
#Beはソフトの互換性無くて失敗しましたが … ※
全てがいきなりシフトするわけではないでしょうし、
移行の際に最も重要な「データの互換性」の問題さえクリアできれば、
ビジネスユースでは今のWindows+Officeのシェアをそのまま持っていける、
もしくは、さらに増やせるのではないでしょうか。
#商品の魅力を消費者に伝えるのには長けているでしょうし。
#ソフト屋もついてくるでしょうし。
#Beはダメでしたが … ※
ただ、ZDNet [zdnet.co.jp]の記事(3ページ目) [zdnet.co.jp]を見てちょっと不信感を持ちました。
なんか、「ユーザがインフラ技術の変化の早さについていけて居ない」というように言われています。
私、ユーザがMSのリリースに追従していかないのは、
コストと信頼性が問題だと思っていたのですが、違っていたのでしょうか。
コストについては、変化のスピードにも関係しますので、言っていることに矛盾はありませんが、
信頼性についてはどうしたのでしょう。
忘れてしまっているのでしょうか?
それとも、知らないふりを?
こんなことでは信用できません。
ユーザとしては、せめて、信頼性の問題に言及しつつ、
新技術に於いて、それをいかに克服するかについて述べてもらいたいところです。
※注:現在もBeOSを愛用中です
Re:内容には (スコア:2, 参考になる)
>なんか、「ユーザがインフラ技術の変化の早さについていけて居ない」というように言われています。
>私、ユーザがMSのリリースに追従していかないのは、
>コストと信頼性が問題だと思っていたのですが、違っていたのでしょうか。
これは「プログラマーにとっても,企業にとっても,インフラ技術の変化は速すぎる。ユーザーは付いていけずにいる。」
というところのことだと思うけど、このこといってるのはコンサル会社の人で、
別にMSがそう思ってるわけではないと思うけど。
#もしかしたらそう思ってるかもしれないけど。
それに、このあたりの話は一般的な話を言ってるのだと思われ。
ベンダーにしてみれば、ユーザーがついていこうといくまいと、どんどん新しいものを出していかざるを得ないし、
それにユーザーがついていってくれないと困るので、あらゆる手段でついてこさせようとするけれど、
これだけ変化が速いとユーザーは中々ついていけないよね、という話では。
#MSだって、プログラマあたりはひーひーいいながらついていってるんだと思うよ。
江戸の仇を長崎で (スコア:3, 興味深い)
そうなると、第三者からさくさく読み書きできるね、あやしげなプロテクトだのなんだのも無くなるね、ハッピーだね、
とかいう話を、こないだまで話していたんでしたよね。
と喜んでいたら、それより1つ下の「ファイルシステム」の部分が、
プロテクトだのなんだの掛け放題状態に、なっちゃうぞっていう話なわけですね、これって????
いや、技術的には、古典的"ファイル"システムなんてそろそろもういいや
っていう感じなのは確かです。プログラムが拡張子連動で似非Object指向
しているなんてのと同じ方向性(>>MIMEに結実した??)で、悪い話じゃない。
だけど、10の技術をダシにして100の独占を行なう(笑)のが常であるMSが、
技術と善意による世界への貢献のためダケに、そういう「プログラム(OS)から支配しやすい」新ファイルシステムを
導入するとは、残念だが思いにくいっす。
とりあえず、mp3とかの「コピー」プロテクトは、osレベルでかけやすくなるかもね。
今までのosはアプリからのread()(ってのか)の要求に対して単に従順であったわけですが、
これからは介入し放題っす。データそのものもそうだし、DBならば
アプリがDB上に作った「メタ」データをosが読むことも自由に出来るだろうから、
「ああこれはmp3ファイルなのね。じゃあアッチからコッチへのコピーは不許可ね」
とかいう制御を、osレベルでやれるようになるだろうなあ、と。
つまり今まではこういうレベルをプロプラエタリにすることは不可能だったが、
今後は可能になるってこと。ひえー。
「この種類のファイルを不正にコピーしようとしたアプリケーションを、強制終了しました」
とかいうダイアログを目にするのも、もう間もなくなのでしょうね(T_T)
#CDと違って、ファイルやファイルシステムにはレッドブックは無いから(笑)、
#OS屋のやりたい放題なんだよねー。くわばわくわばら。
Oracleがようやく実現したこと (スコア:3, 参考になる)
ファイル形式を選ばない全文検索システム、多彩なプロトコル
(SMB,HTTP,FTP,webDAV,NFS...)でのアクセス。
ありとあらゆるファイルをDBに格納し、検索・集計・出力できるように
するという壮大な(端から見れば無謀な)この夢をOracleは8iの頃から
追い求め続けていました。iDevelop99 [oracle.co.jp]でこの構想を初めてみたときは
とてもワクワクしました。あれから3年近く経ち、9iでようやくその夢を
実現しました。
“なんの役に立つの?”と問われれば、やはり何十万、何百万の
ファイル数を扱うシステム、大量のデータファイルを扱うようなシステム
(Computer Graphics を扱うところとか)で威力を発揮して
くれそうです。Security Systemさえ整えば、社内に置いているファイル
サーバーをInternet Zoneに配置してどこからでも好きな方法でアクセス可能に
することができます。バージョン管理ができれば、ファイルの内容を
間違った状態で保存しても元に戻すことができます。この恩恵をすべての
ファイルに対して受けさせようとするのがiFSです。
Microsoftはその夢を追いかけようとしているわけです。何年・何円かけて
実現するかわかりませんが、気長に待つだけの価値はあるでしょう。この
システムができる頃にはきっと既存のFile Systemでは扱え切れないほどの
Fileを私たちは扱うことになるのでしょうから。
OracleのiFSについては以下のURLをどうぞ。
http://www.oracle.co.jp/9i/think9i/ccm/eKit/qt/index.html [oracle.co.jp]
過去のアプリとの互換性は? (スコア:2, おもしろおかしい)
互換性 (スコア:2, すばらしい洞察)
MS は、互換性を保つということについては、かなり重点を置いているはず。FAT → VFAT もよく考えてあると思うし、日本語版 Windows で Unicode の U+005C をバックスラッシュじゃなくて円記号にしたところなんか、どんなに汚くてもいいからとにかく (初心者ユーザから見た) 互換性を最優先で考えた結果でしょう。
互換性至上主義は、シェアを大きく伸ばすことで多くの初心者ユーザを抱え込んだ MS の宿命でしょう。そのために、新ファイルシステムも、VFAT や日本語 Unicode (?) のようにとてつもなく汚く複雑なものになってしまうのではないでしょうか。
Re:互換性 (スコア:1)
>とてつもなく汚く複雑なものになってしまうのではないでしょうか。
むしろ、新ファイルシステムをスマートに作って、その上に「FAT/VFATシェル」のような物を1枚かぶせることで互換性を保つようにするのではないでしょうか。
新システムがスマートであればあるほど、シェルも作りやすいし、結果として互換性も高くなると思います。
というか、新ファイルシステム対応OS上で、仮想PCみたいに「Windows」や「DOS」が走って、その中ではFAT/VFATが使える、見たいな。
なんていうか、「ファイルシステムミドルウェア」って感じでしょうか。
Re:互換性 (スコア:1)
しかしまあ、それでもやはり返り値がごっそり反対になったりとか、逆の例もありますが・・・
ファイルシステムに関する本 (スコア:2, 参考になる)
本文でもちらりと触れられていますが、BeOSのファイルシステムであるBFS の最初のバージョンは、RDBな構造でした。しかし、それでは他のファイルシステムと統一的に扱うのが困難だということで、検索インデックスつきの通常ファイルシステムになりました。
実際に Be,Inc.でBFSを開発した Dominic Giampaolo 氏が、 他のファイルシステムとの比較を含め、ファイルシステムの基礎やBFSの構造を解説した本「Practical File System Design [mkp.com]」を出しています。 出版は1999年ですが、当時はファイルシステムに関する技術書はほとんどなかったので、かなり参考になりました。(某出版社から日本語翻訳版も出ていますが、訳がどうしようもなく悪いので、興味ある方には原書をお勧めします。)
方向性は正しいけれども… (スコア:2, すばらしい洞察)
アプローチとしては、ファイルシステムを OS の中に置くのは、 正しい。「dir /s」(find . -print の方が分かりやすい?) も高速化されるだろう。
ファイルシステムの構造が隠蔽化されるといっても、元々、 Windows内のプログラムが、API以外の方法で、 ファイルシステムをごちゃごちゃ触るのは そもそもイレギュラーな話なのだし。
心配なのは、他の OS から、MS の新ファイルシステムを 除くのが困難になるということ。大丈夫かな…。 (いらぬ心配かな)
/boot/windows希望? (スコア:1)
どうせ「真似」が専売特許なのですから、/の下に全てのディレクトリがあるという構造にしてもらえると有り難いのですが、、、。
無理か、、、。
----------- 一生勉強を続けなきゃ!
Re:/boot/windows希望? (スコア:1)
Re:/boot/windows希望? (スコア:1)
概念と実態の乖離が有りすぎだから、こういう見せ方は
よろしくないと思いますデス。
OS2の様に素直にDesktopというディレクトリを作りやがれ:)
OS2のデスクトップはあくまでもフォルダーの変種という
扱いなんです。最初に開いて、最後に閉じられると言う。
で、フツーのフォルダーでも作業域というオプションを付けると
そのフォルダーから起動したオブジェクトは、親フォルダーを
閉じるとみんな閉じられたりする。
自分はOS2ユーザーなんでこういう作りの方がうれしいなぁ。
-----------------
#そんなワタシはOS/2ユーザー:-)
OFSというくらいで (スコア:1)
# たとえば、cd /MS Office/Word/document するとディスク中の全てのワード文書が見つかったりする!?
-----
gen+nob+ash
Re:OFSというくらいで (スコア:1)
「保存済み検索」と「検索結果を保存したもの」とは、違います。
検索の"やりかた"を保存するだけならば、次回検索して何が得られるかは動的(^^;に決まりますが、
ある時点での検索の結果の参照(ポインタというかlnというか)を保存するならば、ソレを何回openしてみても結果は同じです。
ちなみにこれは、「どっちかにしろ」という意味ではなく、
「どっちも併存可能だ」という話です(と希望します(^^;))。
つまりqueryオブジェクトもcollectionオブジェクトも
どっちもオブジェクトとして保存可能であるという世界、ね。
どっちもダブルクリックすればそれぞれに見合った振舞い(多態)をして答えを表示してくれる、と。
Re:/boot/windows希望? (スコア:1, 参考になる)
/usr/local/windows/ 希望 (スコア:3, すばらしい洞察)
まちがっても /sbin とかではない。
/lost+found とかでも可。
Re:/boot/windows希望? (スコア:1)
--S0R5
SQLServerとWindowsの統合? (スコア:1)
Re:SQLServerとWindowsの統合? (スコア:1)
こんどはオラクルがつぶされるのね。
基本パーティションとか拡張パーティション (スコア:1)
パーティションの構造とかも変わってくるんでしょうかね?
個人的には、綺麗さっぱりなくなって、すっきりしてほしいです……
本当かい♪本当かい♪
Re:基本パーティションとか拡張パーティション (スコア:2, すばらしい洞察)
最も、パーティションの仕組みまで変わってしまったら、一台のハードディスクに複数のOSをインストール出来なくなってしまいますし。
Re:基本パーティションとか拡張パーティション (スコア:1)
>一台のハードディスクに複数のOSをインストール出来な
>くなってしまいますし。
逆にLinuxなどの複数のOSをインストールできなくする
ために,パーティションの仕組みを変えてしまう可能性
は,あるのでは?
(そうならない事を祈る.)
Re:基本パーティションとか拡張パーティション (スコア:1)
>ために,パーティションの仕組みを変えてしまう可能性
>は,あるのでは?
PC-ATの制限もあるから、これは無理でしょ。
このあたりを変えようとすると、MSだけでどうこうできるレベルの話ではなくなるので。
少なくとも、LBAだとかMBRだとかを変える事はまず無理なんで、
このあたりが変わらなければどうとでもなるかと。
MS自身も、互換性は保たなきゃいけないはずだしね。
#もっとも、変わったところで何とか対応しちゃう人はいくらでもいそうだけど(笑)
Re:基本パーティションとか拡張パーティション (スコア:1)
>MS自身も、互換性は保たなきゃいけないはずだしね。
新OSが旧OSのファイルシステムをサポートしないといけないが,
旧OSが新OSのファイルシステムをサポートしてないですよね.
# DBがディスクをrawデバイスでアクセスするなんて,よくある
#話です.
Re:基本パーティションとか拡張パーティション (スコア:1)
#新ファイルシステムに合うように変える可能性はあるかも。
この変更は意味がある? (スコア:1)
ReiserFS (スコア:1, 興味深い)
問題は・・・・・ (スコア:1)
FSがバグったら、まるごと、逝ってしまいますから。
現状では、まともに使えるようになる頃には、世間が先回りしていたりして。
Re:問題は・・・・・ (スコア:1)
穴が増えるだけじゃないでしょうか。過去の例から言えば。
〜◍
ハードウェア (スコア:1)
ってことは、ファームがファイル読めないとだめなんですよね?
(?疑問? 有識者様、ご指導の程。)
この疑問とは関係ないんですが、
同一ファイルの別バージョンを管理する方法が欲しいなあ。
ランタイムのライブラリなんかにうれしいでしょうね。
-- LightSpeed-J
Re:ハードウェア (スコア:1)
この疑問とは関係ないんですが、
そーゆーヒトは.NETのアセンブリについて調べるといいかもよ。同一ファイルの別バージョンを管理する方法が欲しいなあ。
ランタイムのライブラリなんかにうれしいでしょうね。
Re:ハードウェア (スコア:1)
>ってことは、ファームがファイル読めないとだめなんですよね?
ブートローダだけ読めればよいのでは。
てゆーか、BIOSはディスク上のデータを読めればいいだけで、
ファイルシステムには絡まないので関係ないかと。
Re:そんな事をしても (スコア:1)
なかなか野心的な試みで、ワタシは期待してます。
<おふとぴ>
MacOS9以前のファイルシステム(HFS)モドキにならないでね
</おふとぴ>
オフトピに無粋なツッコミ (スコア:1)
階層なしでデータベース風味ということなら、
HFSより古代のMFSを引き合いに出したほうが妥当と思われ。
ついでに言うなら、HFS+が使えるようになったのはMac OS 8.1からですね。
Re:そんな事をしても (スコア:1, 参考になる)
ファイルシステムが認識される前にOSはどこからロードされるの?って質問とDBがレポジトリのOSでOSはどこにあるの?って質問は同じですね。
「DBが落ちたら」の心配もエディタで編集中にOSが飛んだらパーってのと同じことです。
私としてはドライブレター撲滅をどうするのかが一番興味深いところです。
Re:IEの二の舞にならないよう願う。 (スコア:1)
6.5の時の話だけどロックの競合が起きたままDBシャットダウンしたら
再起動時、DBまるごと回復中のまま永久にお亡くなりになったのは参った。
使い方、プログラムが悪いと言えばそうなんだけどさぁ・・・
最近の新しいのは改善しているのかな??
ファイルシステムに採用されたとしたら電源ブッチンした時とかがちょっと怖いですね。
(まぁ今のファイルシステムのままでも怖い事には変わりありませんが)
どのみち当分怖くて使えないという事になると思ふ。
重蔵。
Re:Keep It Simple! Stupid!! (スコア:2, すばらしい洞察)
treeが(一番)シンプルだと、なぜ言えるのか、教えてください。
概念的にはtree型も表型もnetwork型も大差ない「複雑さ」だし、
実装もさほど差が有るように思えないです。
単に、従来方式との差を「プログラマが(笑)」理解するのに
いくばくかの負担がかかる、という話じゃないかなーと。
>それこそコンパイラから書き直していかないと、完全な最適化は無理だ
関係ないだろうな。人間がマゴつくのと比べて数億分の1しか
コンパイラはマゴつかないと思う。
なぜならそういう「ライブラリ」が有れば済むからです(^^;。
既存のファイルシステムだって、ライブラリ(systemcallでも同じこと)経由で
我々は大抵いつもアクセスしてたわけですから、おあいこかと。
心配なのはどっちかってーと、新fsを相手にしたプログラマが
旧fsの延長にすぎない方法でばかりアクセスしようとして
主にそのせいでパフォーマンスを損なう、という可能性のほうじゃないかな。
そういや今月だかのDBマガジンでは、Object指向DBとRelationalDBとの差の話が特集だったなあ。
それこそプログラマ側の問題についても色々書かれてました。両者は何よりも「概念が」違うんだよね。
>円盤が補助記憶装置で有り続けるかどうかは
更に関係ないっす。ラムディスクだってラムDB(?)だってアリなわけですから。
メンタルモデルのミスマッチ (スコア:2, 興味深い)
> 実装もさほど差が有るように思えないです。
同意します。むしろ、実装をイメージできるプログラマなら
理解しやすいと思います。
私の経験では、ある程度tree構造のファイルシステムというものに
慣れていて、Unixでもlsとかcpとか簡単なシェルスクリプトは
書けるノンプログラマの人の方が混乱するようです。ファイル
システムはtree型、というモデルが出来上がってしまっていて、
network型を前にするとさっぱりわからなくなる (ディレクトリ
階層の順番を決めるのに悩んだりとか)。
> そういや今月だかのDBマガジンでは、Object指向DBとRelationalDBとの差の話が特集だったなあ。
> それこそプログラマ側の問題についても色々書かれてました。両者は何よりも「概念が」違うんだよね。
OODBを入れたけどコアプログラマ以外にわかりづらいと
評判で、RDBに見せるためのレイヤを書いた経験アリ。
これも、内部を理解できるプログラマより、Accessとかで
若干RDBに触れた経験のあるノンプログラマの方が理解に
てこずってました。
Re:OS/2 の IFS方式は? (スコア:2, 興味深い)
いわゆるデータベースのノリに慣れてくると逆に、
明示的commitのタイミングが存在せず、
ましてrollbackなんて概念も存在しない、
旧来のファイルシステムを使うことのほうが
違和感や不安(笑)を覚えるようになったりします。
「しなければならなく」というよりも「することができる」ってのが
前向き(^^;な解釈かと。
ふつーのファイルを使って信頼性(?)のあるプログラムを作ろうとすると、
なんだかんだいってcommitやrollbackの概念に相当する処理を
なにかしら書く羽目になりますよねえ。
バックアップファイルを一時的に作っておいたり、
ロックファイルを作ってみたり。
あーゆーのを全部おまかせできる(乱暴)という意味では
よりインテリジェントなDBなるものにデータを保管するのは
嬉しいことかも。
まぁ「どういうアーキテクチャの」DBに保存するかによって
プログラマの頭(笑)との間に不幸なインピーダンスミスマッチが
生じたりはしますけど。