reiser4開発者Eduard Shishkinへのインタビュー

エドワードが忙しいという事実のために、インタビューの物語は無期限に広がった。 しかし、すべてにもかかわらず、reiser4開発者は時間をかけてHabrとENTの尊敬されているコミュニティからの質問に答えました。 それの由来-カットの下で読んでください。



-カーネルでのreiser4のプロモーションについてはどうですか？



技術的な障害はもうありません。有名な「包含リスト」の問題はすべて解決されました。 VFSとの関係を明確にすることだけが残っており、出版のための対応する記事はまだ準備ができていません。



一般に、Linuxカーネルにreiser4を昇格させることは今では優先度が低くなっています。 シンプルです。VFS/ブロックレイヤーのすべての変更にすぐに対応する必要があります。 そして、私はいつもそのような機会があるわけではありません。 -mmブランチでは、誰もこれを必要としません。 何かが壊れた場合、Andrew Mortonは通知を送信します。 そして、時間を見つけたらそれを修正します。



「reiser4はカーネルに含まれず、死ぬ」という一般的な予測については、プロジェクトをLinuxカーネルのメインブランチに含めることによって与えられる「命のチケット」への執着が理解できないと言いたいと思います。 Reiser4は、特定のオペレーティングシステムに関連付けられていない、データストレージの分野における18年間の研究の結果です。 多くの科学者が取り組んだ結果。 彼らはLinuxではそれをオンにしないだろう-彼らは私たちのアイデアが面白いと思われる別のOSでオンにします。 Linuxでは、ライトはウェッジを収束しませんでした...



-イメージを改善するために、reiser4に関する広告キャンペーンのような何かを行うことは理にかなっていますか？



最高の広告キャンペーンは、それがどのように機能するかを人々に説明することです。 誰もが彼女のコードを見ているため、誰も何も理解していません。 ここにオープンソースがあります。 これを説明する方法は？ 評判の良い出版物で出版された記事のみ。 そして、もちろん、ウィキペディアの話はありません。 ウィキペディアは、ルネサンスの芸術家の作品をカバーするのに適しています。 そして、あなたのプロジェクトのページは、競合他社の便所になる危険があります。



私の側では、いくつかの記事を公開します。 1つ目はモジュールアーキテクチャに関するもの、2つ目はダンスツリーモジュール（ これまで利用可能な唯一のTREEインターフェイスプラグイン ）に専念します 。 非常に興味深いでしょう。このモジュールで使用される手法は、最も洗練された手法の1つです。 さらに、トランザクションマネージャと他のプラグインがどのように機能するかを説明するのは良いことですが、コードからこれを理解することもできます（ ツリーについて言えない場合 ）。



-BFS（ CPU-scheduler ）、BFQ（ I / O-scheduler ）について個人的にどう思いますか？



正直に言うと、私は長い間プランナーをフォローしていませんでした：私のラップトップでは、テキストエディターとブラウザーは別として、少し起動します。 BFSの登場の前に、かなり不愉快な話があったことを思い出します（ ちなみに、Linuxカーネル開発モデルの特徴 ）。 しかし、ハンスはかつてエレベーターに非常に興味を持ち、常にさまざまなアイデアを実行するように指示されていました。 約10年前、私は彼の指示に基づいて何らかのエレベーターを改造しました。 確かに、彼はこれからうまく機能しませんでした。 たぶん私はエレベーターに興味がなかったからでしょう...



-なぜもっと生で信頼性の低いFS ext4がほとんどすぐにカーネルに受け入れられたと思いますか？



まあ、これは事実上の標準のLinux ext3ファイルシステムの論理的な拡張です。 ここに赤信号があった場合、それは驚くべきことです。



-コアの膨大な量のFSについてどう思いますか？ それは正当化されますか？



もちろん、正当化されていません。 この動物園は、ファイルシステムを不透明なモノリシックモジュールと見なしている古いVFSの概念によって大幅に促進されています。 以前は、FSがそれほど多くありませんでした。 そして今、怠け者だけが彼らの多くが同じことをしていることを理解するでしょう。 結論を出すときです。 状況を改善するための多くの提案があります （ すべて記事に記載されます ）。



-今年と来年、どの展示会やフォーラムで講演する予定ですか？



彼らはまだ誰も招待していません。 私自身は決してイニシアティブを示しません。



-reiser4を開発する動機は何ですか？ 結局のところ、他にも多くのFSがあります。



強い動機はありません。 最初は、最終的に透過的な圧縮を完了したかった。 その後、2007年に彼女が発表した後、私は何もすることがないためにReiser4で忙しくしました。長い間仕事を見つけることができませんでした。 今、私はReiser4が基づいているデータストレージ科学のいくつかの側面に興味を持ち続けています。 残りのローカルFSは、私にとっては面白くないものです。



-ハンズとコミュニケーションをとるために、「舞台裏」で非公式に続けていますか？ 彼は開発に参加していますか？



別の方法で通信することはできなくなりました。 彼はすべての可能な支援を提供しようとしているものの、コンピューターサイエンスから完全に離れましたが、完全に参加するには彼が持っているはずのないコンピューターが必要です。 そして、ハンスは遊べないため、本を重ねて古い趣味である物理学を設定しました。 だから、私は特別な相対性理論に矛盾を見つけたので、彼の新しい記事をレビューするロシアの科学者を見つけるように頼んだ。 彼は「科学が何も入れられていない弁護士の国」アメリカを呪っている。 彼はロシアを暖かく思い出します。 彼は、ソ連の科学と教育のかつての名声を復活させようとしているアンドレイ・フルセンコ大臣のイニシアチブに興味を持って従います。 彼は彼のプロジェクトに外国人のための場所があると信じており、彼は一般的にロシアに移り、最終的にロシア語を学ぶ準備ができていると言います。



-あなたの主な仕事は何ですか？



私はRed Hatファイルシステム部門で働いています。



-reiser4を実行するのに十分な時間はありますか？



比較的言えば、それは十分ですが、サポートのためだけです。私は通常、VFS、ブロックレイヤーで実行されるすべての変更を最新の状態にしています。 それらにreiser4を適合させるには、通常、週末で十分です。 開発とは、新しいプラグインのプログラミングを意味します。 これは、完全雇用を意味します。 つまり これは給料に対してのみ可能であり、これまでのところ誰もそれに対して支払うつもりはありません。



-サポートに参加している人は何人ですか？ reiser4のサポートを突然放棄した場合、後継者がいますか？



私は今のところ一人です。 以前のすべての開発者は仕事に行きましたが、新しい開発者はいません。 このエリアへのダイビングは簡単ではありません。 これは一日中モニターに座って穴を開ける必要があります。 咲く年に、通常前ではありません。 まあ、人がすでに30歳以上であるとき、彼は安定した仕事とお金を望んでいます。 どこで入手できますか？



-独自のOSで使用するためにreiser4コードのライセンスを取得することは可能ですか？



私はそのような質問にはほど遠い。 ハンスに非常に面白いかどうか尋ねることができます。



-reiser4は、RHELの次のリリースの1つでデフォルトのFSになることができますか？



これはむしろ、マネージャーに対する質問です。RedHatの計画について議論することはできません。 これまでのところ、私は誰にも何も提供していませんが、誰も私に何も質問していません。



-reiser4をFreeBSDに移植する予定はありますか？ おそらく、FUSEを使用してポートを作成することを検討する必要がありますか？ コアの変更を受け入れるポリシーについてどう思いますか？



一般に、そのような移植は私にとって決して面白くありませんでした。 しかし、私はFreeBSDが学問的ルーツを持つオペレーティングシステムであると聞いた（ カリフォルニア大学バークレー校 ）。 そしてこれは、高い確率で、開発者と共通言語を見つけることを意味します。 いずれにせよ、彼らは「アルゴリズム」という言葉を誤解してあなたを見ないでしょう。 Linuxでは、重要な概念はパッチの概念です。 そして、カーネル内でこのパッチを受け入れるかどうかを決定する（ おそらく自分の直感に基づいて、また主としてカーネル開発チームと「仲良くする」パッチの作者の能力に基づいて）特定の人々の委員会があります。 私はこのアプローチが好きではありません。MGIMOではなくモスクワ州立大学を卒業しました。



-日常業務でreiser4を試してみたいと思う「落とし穴」は何ですか？ その安定性をどのように評価しますか？



一般的なコメント：過去4年間、適切に機能するハードウェアでreiser4パーティションのデータを失った人はいません。 私はfsckの仕事について不平を言っている数人の人々からアプローチされました。 最終的に、彼らはすべてデータと機能するfsckを入手しました。



最も不愉快なことは、アップグレード後にカーネルの前のバージョンにロールバックする必要があるかもしれないことです （ 次のバージョンのパッチをあまりテストしていません ）。 次の迷惑はデフラグユーティリティの欠如です。 また、再現が困難な古いバグが依然として存在し、「キーの不一致」の報告につながります。 いずれにせよ、reiser4に連絡することにした場合は、間違いなく我慢する必要があります。 問題がある場合は、バグレポートをメーリングリストに送信するか、直接私に送信する必要があります（ 英語がわからない場合 ）。 私はそれらをすぐに解決することを考える必要はありません：reiser4で私は仕事と週末の後でしか時間がない。 文字への応答を停止した場合は、恥ずかしがらずにもう一度自分自身を思い出させてください。 まあ、フォーラムについて不平を言うことは、問題を解決する最も非効率的な方法です。



-デフラグ用のユーティリティを作成する予定はありますか？ たとえば、トレントのあるセクションでreiser4を使用すると、700メガバイトのファイルごとに11000を超えるフラグメントが判明し、この数字を少なくとも数百に減らすことはできませんでした。 同時に、生産性に目に見えるマイナスの影響がありました。



はい、計画されています。 そのようなユーティリティを持つことが重要です。 Reiser4 Transaction Managerは、ロギングとコピーオンライトの技術を組み合わせて使用​​します。 後者自体は、すでにフラグメンテーションを意味しています。 それを取り除くためには、単一のコピーでは十分でない可能性があります。結局、空きディスク領域も断片化される可能性があります。 一般に、デフラグユーティリティは、ツリーのいくつかのパスで状況を大幅に改善します。 外部フラグメンテーションと戦うことができます-これはFSの文章ではありません。



トレントについて。 約3年前、このような場合のフラグメンテーションを防ぐように設計されたLinuxシステムコールfallocate（2）が登場しました。 アプリケーションは、事前にファイル内のピースのオフセットとサイズを指定する必要があり、ファイルシステムはこのピースにディスク領域を（ できるだけ断片化しないで）割り当てる必要があります。 ただし、reiser4はまだこのシステムコールをサポートしていません。 そのような支援をすることは難しくありませんが、近い将来、私はおそらくそれに応じないでしょう。



-reiser4の使用時に特定のハードウェアに問題はありますか？



私はそのようなことを聞​​いたことがない。 雑食のようです。



-grub2のreiser4サポートは、reiser4開発者自身によって実装されますか？



そうなることを願っています。 これは骨の折れる作業ですが、成功することが保証されています。 grub-0.97のパッチがあります。 それに基づいて、奇跡的に、grub2のreiser4サポートを整理できます。 既存のパッチの欠点は、対応するバイナリが大きすぎて、割り当てられた62セクタに収まらないために、ダウンロードがstage1_5を通過できないことです。 また、stage1_5を介して起動できないことは、デフラグツールがパーティションで動作するたびに、grubを再インストールする必要があることを意味します。 grub2のreiser4のサポートでは、すべてが適切に行われる必要があります。 マルチデバイスからbtrfsをロードするモジュールは、62個のセクターに収まります。 reiser4がそこに収まらないのはなぜですか？



-将来、ユーザー空間のプラグインを削除することは可能ですか？ 何か計画はありますか？ カーネル空間とユーザー空間の両方にプラグインをロードできるインフラストラクチャを作成する予定ですか？



ユーザー空間で個々のプラグインを削除することはあまり意味がありません。 それらはどのように相互作用しますか？ 各プラグインはサービスを実行し、次に他のプラグインにサービスを要求します。 カーネルで実行されているXプラグインには何らかの運用サービスが必要であり、それを提供するYプラグインはユーザースペースで動作すると想像してください。 良いことは何もありませんか？ カーネルモジュールとしてプラグインを動的にロードすることは便利ですが、これは面白くて書き込みの問題ではありません。 さて、それらを動的にロードできるようにしましょう...



-FSの強度をさまざまな方法でテストし、問題を示す一連のテストを作成することは価値がありますか？ たとえば、アグレッシブな並列書き込み、読み取り、削除を行い、書き込みデータとの読み取りデータの対応を表示し、ファイルシステムの構造に問題がないかどうかを確認するperlスクリプトのセットです。



このようなテストを行うことは多くの人の夢です。 そのため、30分間実行した後、自信を持って次のリリースを行うことができます。 ここではすべてが非常に難しいとしか言​​えません。 ソフトウェア製品の問題領域を特定する包括的なテストを作成することは、非常に困難な作業です。 はい、テストは主に他のカーネルサブシステムのリグレッションで行われます。 そして、それらを修正するか、誰かが修正するのを待ちます。



-zfs / btrfsはreiser4にどのように影響しましたか？



まさか。 Reiser4は、xfs（ 遅延割り当て手法 ）の開発によって部分的に影響を受けました。 基本的に、彼らは独自の開発を使用しました。



-btrfsの開発に直接関与していますか？



一部は雇用主に代わって。 grub-0.97でbtrfsをサポートしました（ ディストリビューションはgrub2では動作しません ）。 他に何が託されるのか分かりません。 トレンディな機能が「データ重複排除」である可能性があります。



-メイソンとの最近のセンセーショナルなやり取りに続くbtrfsの現状について、あなたの意見はどうですか？



なぜ「センセーショナル」なのですか？ 通常の作業環境。 私はエンタープライズシステムでのbtrfsの適用性を調査するために割り当てられたため、残りのFSが問題なく動作するモデルで強力な内部フラグメンテーションが見つかりました。 したがって、これが間違いなのか「機能」なのかを見つけ始めました。 確かに、半年がすでに過ぎていて、btrfsアルゴリズムについて理解できることはまだ聞いていません。 どんな意見がありますか？ 私は、reiserfsファイルシステムのテールパッキング機能が必要であり、後者のアルゴリズムとデータ構造がどのように機能するかを完全に理解していないことに気付きました。 Bツリーでは、「テールパッキング」の概念にはまったく意味がないとしか言​​えません。 さらに、そのようなツリーに可変サイズのアイテムを配置しようとすると、内部の断片化が無制限になります。 また、Reiserfs は Bツリーとそのよく知られた変更を使用しません 。 彼らは完全に異なるアルゴリズムを使用しています（ ちなみにロシアの科学者の発明 ）-90年代初頭にNamesysの歴史が始まりました。 また、btrfs設計で必要とされるトップダウンバランシングのためにそれらを変更することは、従来のBツリーとは異なり、完全に簡単な作業ではありません。



ダンカン・マクラウドがすべての前向きな経験を借りて、Namesysで働いていたbtrfsのメンテナーであるChris Masonが非常によく耳にします。 当分の間、私は反対のみを見ます。 何らかの理由で、彼はキーを節約しました（ btrfsのキーは136ビット、reiser4-192ビット ）が、バランスが取れていないため、ユーザーのテラバイトのディスクスペース（ およびRAM ）を節約しました。 追加のキーフィールドは、さまざまな方法でデータとメタデータをグループ化する機能です。 そして、何、これはすべて必要ではない??? 私の意見では、上から下へのバランス調整は完全な妥協です。バランスのスクイーズフェーズ、およびデータ圧縮と暗号化は、「遅延割り当て」手法のように延期することはできません。 そして、そのようなツリーで適切なロックスキームを編成できないため、これらの人はスケーラビリティの問題に直面するように思えます。 多数のプロセスに「木工」を分配する方がはるかに有益であり、それらの一部を（ 下から上に ）移動させ、共通のルートを介してこのツリーにすべて侵入することはできません。



一般的に、私は知りません...もちろん、私はできる限り助けますが、これは事実です。プロジェクトが悪いアイデアに基づいている場合、それからキャンディーを作るのは難しいです。 ちなみに、Namesysの全歴史は、学術機関（ モスクワ州立大学、ロシアアカデミーオブペレスラヴリザレスキーのソフトウェアシステム研究所）との継続的な接触です。 XFSは、シリコングラフィックスの学校でもあります。 そして、Btrfsは何の物語ですか？ 低レベルのワークショップのペア？ そして、存在しない機能が発表されるイベントに名前を付ける他に何がありますか？ 私は長い間奇跡を信じることをやめました...



-FSの将来をどのように見ていますか？ どのような機能がありますか？



ファイルシステムは、ディスクスペースリソースを管理するサブシステムです。 そして、そのすべての「機能」は、このリソースの効果的な管理を目的とする必要があります。 そしてこれは、ファイルシステムの未来がより高度なアルゴリズム、すなわち より良い仕事をする人のために。 ただし、新しい物理メディア、読み取り/書き込みテクノロジがあり、一部はユーザー空間からカーネルに移行しています（ 原子性、透過圧縮、暗号化など ）。 既存のファイルシステムは時代遅れになりつつあります：それらは革新に適応するよりも書き換えが安価です。 ファイルシステムは、このような機能に「対応」できる必要があります。 毎回それらを書き換えないでください...そして、このために、彼らは適切な技術的基盤を持たなければなりません。



そのようなベースを作成する試みは、reiser4で行われました。その前身とは異なり、完全にモジュール化された構造を持っています。 reiser4では、file_operations、inode_operations、address_space_operationsメソッドのすべての実装は単なる薄層です。どのプラグイン（ モジュール ）を次に制御を移すかを決定するディスパッチャです。 また、各モジュールは、インターフェイスの特定のサブスキーマの抽象クラス（インターフェイス）を実装し、データ（ メタ ）を保存するという概念を反映しています。



これがどのように機能するかを指で説明しようと思います。 btrfsの機能（ スナップショットなど ）を実装するとします。 ご存知のように、このFSはトランザクションのコピーオンライトモデルを使用します。これは、ツリーを上から下にバランスさせることに基づいて実装されています。 これは、Reiser4が現在提供しているものとの主な違いです。したがって、「TMGR」インターフェースの新しい「プラグイン」プラグイン（トランザクションマネージャー）、およびルートファミリー（「history」）を持ち、上からバランスを取るストレージツリーの「TREE」インターフェースの新しい「マルチルートツリー」プラグインを作成する必要があります。ダウン。この場合、後者には独自のロックスキームを装備する必要があります。 TMGRに関しては、これは次の記事でパーティクルと呼ばれるオブジェクトを管理するための抽象クラスです（transcrashプリミティブのデュアルコンセプト、記事はこちらです）。



異なるファイルシステムのトランザクションマネージャーをよく見ると（現在、このようなマネージャーには3つのタイプがあります）、それらの共通機能のいくつかに気付くのは簡単です。つまり、TMGRインターフェイスでは、次の主要なメソッドのセットを区別できます。

• enter_context（）;
• try_capture（）;
• exit_context（）。

最初と最後は、実際のファイルシステムからのプロセスの開始時と終了時にそれぞれ呼び出されます。 2つ目は、データ（ページまたはバッファ）が変更されるすべての場所です。 reiser4は単一のTMGRプラグインを実行します。これを「jcow」（履歴を保存しないジャーナリングとコピーオンライトのテクニックの共生）、メソッド-> try_capture（）がいわゆるブロックに追加します「Atom」（reiser4の「粒子」の特別な名前）。また、新しく作成したプラグイン「cow」では、このメソッドはストレージツリーの新しいルートをバディします（btrfsコードでは、対応する関数はbtrfs_cow_blockと呼ばれます）。



自宅での演習として、この場合の「原子」とは何かを理解することを提案します（つまりディスク全体に送信する必要があります）。教育プログラムについては、Ohad Rodehの記事「Bツリー、シャドウニング、およびクローン」を参照できます。



これらの新しいルートを追加および抽出する方法を知っておく必要があります。「書き込み可能なスナップショット」機能が必要な場合は、2回インデックス付けされたセットを形成する必要があります。しかし、これは問題ではありません。たとえば、btrfsはこの目的のために別個の「ルートツリー」を使用します。



合計で、btrfs機能を取得するために必要な新しいプラグインは2つだけです。そして本当に：なぜ他の何かが必要なのでしょうか？ FILEインターフェースプラグインは、TREEインターフェースのメソッドに従ってツリーからアイテムを選択し、特定のツリーがどのようにバランスがとられているかを知る必要はありません。他のインターフェース（NODE、ITEMなど）のプラグイン ) : ? , «» , .



, TREE TMGR — , , , , fsck ( reiser4 , , ), , , , , 100% ( 組織化されたインターフェイススキームが成功すれば、複数の機能を正常に実装できます）。



同様に、プラグインを使用して、ZFSまたはbtrfsの場合と同様に論理ボリュームを整理および管理できます。ただし、ここで警告する必要があります。これはいわゆるレベリング違反（階層化違反）になります。実際のところ、Linuxボリューム管理は別のサブシステム（lvm）によって実行され、ファイルシステムと混合しようとするとひどく終了する可能性があります。この機能を削除するように求められます。許可されるレベル（例：btrfs）、しかしreiser4ではこれは歓迎されません。いずれにせよ、階層化違反の問題に関するreiser4に対する告発の激しさを覚えていれば、私は努力の危険を冒さないでしょう。



モジュラーアーキテクチャの詳細および他の同様に興味深いアプリケーションは、私の記事で見つけることができます（まだ公開されていません。reiserfs-develメーリングリストで発表されます）。



したがって、ローカルファイルシステムの将来を、特にそのような「内部」インターフェイスの「ポリシング」として説明します。実際、よく見ると、それらは内部のものではないことがわかります。代数のようなものです。線形空間がある場合、Vは（inner部分空間の直接和なので、反対の方法で行くことができます：外部直接和の構築を使用して、Vに同型の空間を構築します。それらは内部ではないため、これはすべてのファイルシステムのプロパティです。ここでVFSに問題はありません（これについては記事で詳しく説明しています）。一般的に、ここでは、ソフトウェアシステム（これはデータストレージシステムに関連しています）と、モジュール、グレーディング、フィルタリングなどのホモロジー代数の概念との間の多くの類似点があります。



そして最後：「機能」について。 reiser4のプラグインの書き方についてよく聞かれます。さらに、質問への答え、および彼が私たちと一緒に実装するものは、しばしば質問者を行き止まりにします。モジュラーアーキテクチャファイルシステムの「機能」のストリーム制作を行うという考えは好きではありません。これは規律であり、大規模なエンターテイメント業界ではありません。誰も数学の定理の証明をストリームに載せませ



ん... 最初は、情報ストレージの分野（例えば、スナップショット）から有用なアイデアがあるはずだと思います。そのようなアイデアが多すぎるとは思わない。そのようなアイデアで-ようこそ。添付ファイルの言語で表現する方法を考え、必要に応じて、新しいスキームを一般的なスキームに追加し、適切なプラグインを作成します。



, «» : ( ) «» : - « » , .