Why Reiser4 is not in the Linux Kernel
なぜ Reiser4は Linux カーネルに含まれていないのか

---
訳注

・原文では、Linus Torvalds 氏が開発・保守しているオリジナルの Linux カー
  ネルの事を様々 (Vanilla, baseline, mainline, main tree 等) な表現で
  記述しています。本訳では、初心者にも理解し易いよう、これらを全て
  「Linux カーネル」と表記します。
  一方、「パッチされたカーネル」「ディストリビューションのカーネル」は
  このオリジナルの Linux カーネルを意味しません。

・Reiser4 とは Reiser Filesystem version 4 を意味します。
  Linux カーネルバージョン 2.4.1 より標準で含まれる Reiser Filesystem
  version 3 の後継で、改良されたファイル管理機構と、プラグインによる機
  能拡張を特徴としていますが、未だ Linux カーネルに含まれていません。
  Reiser Filesystem の作者は Hans Reiser 氏、彼の所属する会社が 
  Namesys 社です。

---

Contents
目次

 1. Why Reiser4 is not in the Linux Kernel
    なぜ Reiser4は Linux カーネルに含まれていないのか

 2. Contents
    目次

 3. Introduction
    導入

 4. FAQ and Frequently Given Answers
    しばしばされた問いと答え

    1. Q1."But just include it as experimental code regardless of
           everything, Namesys programmers will fix all the problems
           eventually!"
           
       Q1.「でも、何でもいいからただ Reiser4 を実験コードとして (Linux 
	    カーネルに) 含めてください。Namesys 社のプログラマーが結局
	    全ての問題を片付けます」

    2. Q2. "But by not including Reiser4, you aren't allowing Reiser4
	    to be tested and it will never get into a decent shape!"

       Q2.「でも、Reiser4 が (Linux カーネルに) 含まれないことによって、
	    あなたは Reiser4 がテストされるのを許可していませんし、そ
	    れでは決して Reiser4 があるべき姿になりません！」

    3. Q3. "Kernel developers hate Hans Reiser, that's why they
	    haven't merged Reiser 4"
       Q3.「カーネル開発者は Hans Reiser 氏が嫌いで、それが Reiser4 
	    のマージされない理由です」

    4. Q4. "I've been using it for years and it rocks, how can't it be ready?"
       Q4.「私は長い間 Reiser4 を使っており、Reiser4 は堅牢です。
            Reiser4 は準備ができているとは言えませんか？

Introduction
はじめに

"Why Reiser4 Is Not Merged" is a widespread question around forums,
Slashdot, OSNews and wherever else Linux-related new appears on the
web. The flame-wars on this topic have gotten to the "mine is bigger
than yours" level. Hence, it's not easy to see where the real problem
lies. This document tries to make clear the "official" point of view
of Linux developers on this matter.

「なぜ Reiser4 が (Linuxカーネルに) マージされないのか」とは、各種フォー
ラム、Slashdot、OSNews やその他 Linux 関連の新しい物が Web に掲載され
る所など、至る所で行われる質問です。
この話題の論争は「お前のより俺の方がデカい」レベル (訳注1) にたどり着
きます。
それゆえ、本当の問題はどこにあるかを理解するのが容易ではありません。
この文書は、本問題における Linux 開発者達の「公式な」視点を明らかにし
ようとするものです。

訳注1：ガキのケンカ程の低レベルという事。

It's shocking to read some people who believe that the main reason why
Reiser4 is not in the Vanilla Kernel are "political disputes instead
of technical merits". The circular reasoning behind this seems to
"Reiser4 is fast/it has plugins so it can/should/must be included
NOW. If you don't agree with me, then you must have an irrational
hatred against Reiser4, because I'm so obviously right".

Reiser4 が Linux カーネルに含まれていない主な理由が「技術的利点ではな
く政治的論争」であると信じている一部の人々を見るのはショックです。
この後の循環論法 (訳注2) は「Reiser4 は高速／プラグイン機構があるので、
Reiser4 は即刻 (Linux カーネルに) 含まれた方が良い／含まれるべきである／
含まれなければならない。
もし私に同意しないなら、あなたは Reiser4 に対して不合理な嫌悪を抱いて
いるに違いない。なぜなら私は明らかに正しいからだ。」です。

訳注2：証明する内容自体が根拠に含まれている論法。
      (但し、ここの文章が循環論法には見えませんが…)

As usual, the world is not black or white, but grey. There is no
"opposition force" stopping Reiser4 from making it into the main Linux
tree. Reiser4 needs to attain a quality level high enough to be
included. It's disturbing to listen to people saying that Linux
Maintiners did not want to include a filesystems for political
reasons. Linux is the kernel that supports many filesystems from its
own sources. Linux even includes (being fair) a lot filesystems people
consider worthless. Linux supports filesystems that are rarely
used. e.g. 9p, BeFS, BFS, minixfs, ADFS, AFFS, EFS, HPFS, UFS, VXFS,
qnx4fs, sysvfs, ncpfs, codafs. There are several relevant filesystem
choices as well: ext3, XFS, JFS, JFFS and reiser3. Many people have
chosen these and are happy with them. Does that really sounds like a
group who would not merge a filesystem for political reasons? If
anything, Linux Developers look more like filesystem bitches.

普通、世界は白か黒かではなく灰色です。
Reiser4 が Linux カーネルに含まれるのを阻止する「抵抗勢力」はありませ
ん。
Reiser4 は (Linux カーネルに) 含まれるのに充分な高い品質レベルに到達す
る必要があります。
政治的な理由で Linux メンテナー達がファイルシステムを含みたくないと人々
が話すのは穏やかな事ではありません。
Linux は自身のソースコードにて多くのファイルシステムをサポートするカー
ネルです。
また、Linux は人々が役に立たないと考えているたくさんのファイルシステム
でさえ (公平に) 含んでいます。
Linux はほとんど使われないファイルシステム (例：9p、BeFS、BFS、minixfs、
ADFS、AFFS、EFS、 HPFS、UFS、VXFS、qnx4fs、sysvfs、ncpfs、codafs) をサ
ポートします。
同様に、いくつかの有用なファイルシステム (ext3、XFS、JFS、JFFS、
reiser3) の選択肢があります。
多くの人々はこれらを選び、満足しています。
本当に、(Linux 開発陣は) 政治的な理由でファイルシステムをマージしない
グループのように見えますか？
何かあるなら、Linux 開発者達はもっとファイルシステムのクソッタレのよう
に見えるでしょう。

Since the initial request to get Reiser4 merged, it hasn't been
declared ready by people who know. "It works for me on my PC" isn't
exactly the way engineers should make decisions. Of course, nobody
expects Reiser4 to be bug-free before getting merged. It must meet
with the design tenets and quality specifications laid out by the
existing maintainers. Writing a filesystem from scratch is not
easy. Reiser4 in particular is attempting to break a lot of new
ground. The Reiser4 authors chose that approach and it is expected
that it takes a lot of time and effort: they have consistently moved
forward since the first discussions of merging years ago. As for
today, thanks to all the work done by the Namesys people, Reiser4 is
growing near to inclusion in the main tree. It could possibly be ready
as soon as 2.6.19. Reiser4 have been working on this question for
two-plus years, so you can imagine what the state of readiness was
when it was initially submitted. Reiser 4 is a complex filesystem, and
it's taking Namesys some years to finish it. This is a good sign. In
every way this points to the future success of Reiser4. You can bet
that ZFS has been working for a long time before being included in
OpenSolaris.

最初に Reiser4 をマージするよう要求されて以来、有識者によってそれが完
成していると宣言された事はありません。
「私の PC で Reiser4 は動いています」は、技術者が決定を下すべき正しい
方法ではありません。
もちろん、Reiser4 がマージされる前にバグが一掃されるとは誰も思っていま
せん。
Reiser4 は既存のメンテナーによってレイアウトされた設計方針と品質基準に
合致しなければなりません。
0 からファイルシステムを記述するのは簡単な事ではありません。
特に Reiser4 は多くの新しい分野を打ち出そうとしています。
Reiser4 の作者達はそのアプローチを選び、そしてそれは多くの時間と努力を
要すると予想されています：
マージに関する何年前の最初の議論以来、彼らは一貫して前進してきました。
今日では、Namesys 社の方々によるあらゆる作業のおかげ (訳注3) で、
Reiser4 は Linux カーネルへのマージに近付いています。
それは、おそらく (Linux) 2.6.19 と同時ぐらいに完成するかもしれません。
Reiser4 は 2年以上 (基準をクリアするための) 作業が行われているので、
Reiser4 が最初に提出 (訳注4) された際の完成度がどうだったか想像できる
でしょう。
Reiser4 は複雑なファイルシステムであり、それを完成させるために Namesys 
社は何年もかけています。
これは良い兆候です。
いずれにせよ、これは Reiser4 の将来の成功を示しています。
ZFS が OpenSolaris に含まれる前に長い期間開発されていた事は間違いない
でしょう。

訳注3：暗に「Hans Reiser 氏の努力ではない」と言いたいのだと思われる。
訳注4：Linux へのマージ要求。通常は細分パッチの形で Linux Kernel ML に
       投稿される。

So that's it: Things need to have a decent shape before being
included, and Reiser4 is not there yet. Many people in this process
have taken FUD against Linux to religious zealotry. This is not the
first time for difficult issues surrounding developers, maintainers
and the Kernel. Egos this large sometimes have disputes. Disputes like
Reiser4, and XFS before it, and the IDE layer in the 2.4.x days, don't
always create this situation. For instance, take OCFS2 and GFS. These
are clustering filesystems, OCFS2 made by Oracle and GFS comes from
RedHat. Both companies/groups have submitted their filesystems for
inclusion, but only OCFS2 is in today. GFS still needs some more work,
but once all the issues are settled down it will be included, just
like Reiser4 will.

つまり、そう言う事です。
ものが (Linux カーネルに) 含まれるためには適切な形になる必要があり、
Reiser4 はまだそうなっていません。
このプロセスにある多くの人々は、宗教的な熱狂のために Linux に対して 
FUD (訳注5) をしてきました。
これは、開発者、メンテナー、カーネルを取り巻く難しい問題の初めてのケー
スではありません。
これぐらい大きなエゴには時々論争があります。
Reiser4 (それ以前には XFS、2.4.x の頃の IDE レイヤー) のような論争は常
にこの状況をつくり出す訳ではありません。
例として OCFS2 と GFS を取り上げましょう。
これらはクラスタリングファイルシステム (訳注6) で、OCFS2 はオラクル社
製、GFS は Red Hat 社提供 (訳注7) です。
(Linux カーネルに) 取り込ませる為に、両方の会社／グループは自身のファ
イルシステムを提出しましたが、今日時点では OCFS2 だけ取り込まれていま
す。
GFS はまだもう少し開発作業を必要としますが、Reiser4 同様、一旦全ての問
題が片付いたら GFS は (Linux カーネルに) 取り込まれるでしょう。

訳注5：Fear，Uncertainty，Doubt (怖れ、不明確、不信)の略語。デマあるい
       はデマに近いものを流して競合の信用性を下げる一種のマーケティン
       グ手法。
訳注6：複数台のマシンから同時かつ直接マウント可能な、特殊なファイルシ
       ステム。主にクラスタシステムで使用される。
訳注7：元は Red Hat 社が買収した英 Sistina Software 社の製品。

Finally, before it can be merged Reiser4 code needs a review and
sign-off by some kernel developer who knows how a file system must
behave. This is an evolving standard and practice. It heavily affected
XFS, bringing tears and whining from a number of people. Many of the
same arguments for inclusion used on behalf Reiser4 were previously
used for XFS. Linux Devs and Maintainers wanted to see certain
qualities and changes in the XFS code. The XFS team at SGI plodded
along, and after much ado, Christoph Hellwig consented to perform a
final review. Some developers grew offended, some people got angry and
caustic. There are not a of these people who are trusted to do this
work. There are even less who are willing to do it. By the time that
Christoph took up the work, it was make or break. None of the other
Linux Devs were willing. Some even indicated that the job was all but
impossible.

最終的に、Reiser4 がマージ可能になる前に、Reiser4 コードはファイルシス
テムのあるべき振る舞いを知っている一部のカーネル開発者達によるレビュー
と署名を行われる必要があります。
このプロセスは、発展中の標準と慣例です。
それは XFS に重大な影響を及ぼし、一部の人々の涙と泣き言を誘いました。
Reiser4 のマージに対する同じ議論の多くが、以前 XFS でも行われました。
Linux 開発者達とメンテナー達は、XFS コードにおける一定の品質と変更点を
知りたかったのです。
SGI 社の XFS チームはこつこつと実行し、そして多くの騒動の後、Christoph
Hellwig は最終レビューをすることに同意しました。
一部の開発者は段々不満が溜り、一部の人は怒りや皮肉を覚えました。
これらの人々の中には、この作業を信用する人がいませんでした。
また、この作業を進んで行う人もほとんどいませんでした。
Christoph がやり始めてから、この作業は進展しました。
他の Linux 開発者は進んで行おうとはしませんでした。
一部の人は、この作業が不可能以外の何でもないとまでも表明しました。

By the same token, there were Linux Devs and maintainers who did early
reviews of Reiser4 and were verbally abused by Namesys. Lots of people
have weighed-in for those messes. Some Maintainers are unwilling to
work with Reiser4 anymore. They don't oppose the filesystem. However,
someone else must review and sign off on it. Egos aside, this just
makes the process slow.

同じ理由で、Reiser4 の早期のレビューを行い、Namesys 社によって罵られた 
Linux 開発者達とメンテナー達がいました。
多くの人達がこれらの騒動に乱入しました。
メンテナーの一部は、もう Reiser4 の作業を行うつもりがありません。
彼らは、Reiser4 に反対しませんが、他の誰かが Reiser4 のレビューを行い、
署名しなければなりません。
このように、エゴはマージ作業をこんなに遅くします。

FAQ and Frequently Given Answers
しばしばされた問いと答え

Q1. "But just include it as experimental code regardless of
everything, Namesys programmers will fix all the problems eventually!"

Q1.「でも、何でもいいからただ Reiser4 を実験コードとして (Linux カーネ
ルに) 含めてください。Namesys 社のプログラマーが結局全ての問題を片付け
ます」

Well, no and yes. As said, nobody expects Reiser4 to be bug-free, but
there are some important issues that need to be fixed. The problem is
that the Namesys developer team is still working on the important
ones. Some of the issues fixed in the past included severe design
issues, BTW. Others are about being well integrated with Linux:
duplication of kernel's own functionality for no good reason,
etc. Every piece of code submitted needs to meet quality standards -
requesting developers to fix severe issues before getting it into the
main tree helps to have better code. If you ask people to fix those
issues "in the future", they may be lazy and so there may be critical
issues around all the time - this has happened with Linux in the
past. Quality is important, especially in a stable development
phase. Linux is already being criticized a lot for merging new
features during this stable phase - that criticism happens with the
current quality control. Imagine what would happen if Linux started to
merge things without caring a bit about what gets merged. Also,
consider how important Reiser4 is. It's a filesystem, once it gets
included in the kernel many people will use it and will depend on it
(your disk format is Reiser4): Linux needs to ensure that things don't
blow up everything.

えー、No と Yes。
言った通り、Reiser4 にバグがないと考えている人はいませんが、解決すべき
幾つかの重要な問題があります。
問題なのは、Namesys 社の開発チームがこれらの重要な問題に今も取り組んで
いるということです。
ところで、深刻なデザイン問題を含む (Reiser4 の) 幾つかの問題は過去に修
正されました。
残りの問題 (充分な理由のない Linux カーネル自体との機能重複など) につ
いては、(Linux に) マージする作業が進行中です。
提出されたコードの全ての部分が品質基準に適合する必要があります…Linux 
カーネルソースツリーに取り込まれる前に、深刻な問題を修正するよう開発者
に要求する事は、より良いコードを得る為に必要です。
もしあなたが「将来」これらの深刻な問題を修正する事を要求するならば、そ
の時には開発者は怠惰かも知れませんし、問題は致命的になっているかも知れ
ません…これは、過去 Linux で起こった事です。
特に安定版の開発段階では、品質は重要です。
Linux は常に、この安定版の段階で新機能をマージした事で大変批判されてい
ます…その批判は、現在の品質管理でも起こります。
マージされるものについて少々の考慮なしに Linux がそれをマージし始める
ならば、何が起こるか想像してください。
また、Reiser4 がどれくらい重要かについて考えてみてください。
Reiser4 はファイルシステムであり、一度それがカーネルに取り込まれたなら
ば、多くの人がそれを用いて、それに依存する事になります (ディスクフォー
マットは Reiser4)：Linux はその機能が全てを吹きとばさない事を保証する
必要があります。

Q2. "But by not including Reiser4, you aren't allowing Reiser4 to be
tested and it will never get into a decent shape!"

Q2.「でも、Reiser4 が (Linux カーネルに) 含まれないことによって、あな
たは Reiser4 がテストされるのを許可していませんし、それでは決して 
Reiser4 があるべき姿になりません！」

Wrong. Read question #1 above. And we live in a Open Source
land. Nobody stops people from testing Reiser4 now, or including it in
the next Ubuntu/Fedora/whatever release. In fact, when Reiser4 is
included it will be merged as "experimental" code, and there's no real
difference between that and patching and compiling their own kernels,
it's just a psychological thing: people will think it's more stable
when it's included even if marked as experimental, for no real reason.

違います。
上の Q1 を読んでください。
そして私達はオープンソースの世界に住んでいます。
今 Reiser4 をテストしたり、それを Ubuntu/Fedora/その他の次期リリースに
含む人を止める人はいません。
実際、Reiser4 が含まれる時、それは「実験的」コードとしてマージされます
し、その状態とディストリビューション自身のパッチ適用＋コンパイル版カー
ネルとの間に実際の違いはなく、単に気持ちの問題という事になります：
本当の理由がなくても、実験的とマークされていてもそれが含まれた時に人は
より安定していると思うでしょう。

BTW, in the kernel world it's a quite common practice to get a feature
into one or two distros before merging it into the baseline
kernel. Being included in distros is valued a lot by Linux
maintainers, because it gets a lot of real-world testing and bug
fixing. And that's something that doesn't really depend on kernel
developers - if a feature gets included in several distros, that means
that people want it and that you can check its quality in the
distributor's bug tracking systems. In the particular case of Reiser4,
Andrew Morton has even said that Uptake by a vendor or two would be
good. If you want to help Reiser4 to get developed faster, bug your
particular Linux distribution and ask them to include
it. Distributions can allow to merge unstable code (and they do that
with several drivers that are not in mainline, like ndiswrapper), but
it's not so easy for the kernel.

ところで、カーネル界では、Linux カーネルにマージされる前の機能を 1、2
のディストリビューションに採用する事はごく普通に行われている行為です。
それで多くの実テストとバグ修正を得るので、ディストリビューションに新機
能が含まれる事は Linux メンテナーによって高く評価されています。
そして、それはカーネル開発者に本当に依存しないものです…機能がいくつか
のディストリビューションに含まれるならば、人々がそれを望み、ディストリ
ビューションのバグ追跡システムでその品質をチェックできる事を意味します。
特に Reiser4 では、Andrew Morton (訳注8) は 1、2 のベンダによる 
Reiser4 の取り込みは良い事だとさえ言いました。
Reiser4 の迅速な開発を支援したいならば、あなたの特定の Linux ディスト
リビューションコミュニティに参加して、彼らに Reiser4 を含めるよう頼ん
でください。
ディストリビューションは不安定コードをマージするのを許可できますが (彼
らは ndiswrapper (訳注9) のような Linux ソースコードに含まれない一部の
のドライバでそうしています)、Linux カーネルではそう簡単ではありません。

訳注8：Linux 2.6 のメインメンテナー。
訳注9：Windows 用のネットワークインターフェースドライバを Linux 上で動
       かす為の特殊なドライバ。

Q3. "Kernel developers hate Hans Reiser, that's why they haven't
merged Reiser 4"
Q3.「カーネル開発者は Hans Reiser 氏が嫌いで、それが Reiser4 のマージ
されない理由です」

Well, no and yes. As said, there are the technical issues that are
stopping it, not anything else. Now, it is true that Hans Reiser has
not helped a lot to solve those issues. Telling Linux developers that
Reiser4 is stable enough and that it should get merged because they
would fix all the issues later does not help a lot (see question #1
above, Hans Reiser has been claiming that Reiser4 is ready for
years). It doesn't help either to mention how much VFS maintainers
hate you and how much smarter your coders are compared to them. It
doesn't help to say how closed-minded they are because they're asking
Reiser4 to disable some advanced Reiser4 features (features that
happen to clash with the VFS and that Reiser4 has ended up disabling
anyway). It doesn't help to mention repeatedly how Linux is doomed
against winfs because they're not allowing Reiser4 to be merged today
- despite that other people are free to disagree with Hans's
predictions - and how evil people are for asking him to fix bugs
instead of helping him to do "The Right Thing". It doesn't really help
to suggest to kernel developers that they should replace the Linux's
VFS with Reiser4's plugin layer just because Reiser4 is faster than
ext3.

えー、No と Yes。
言った通り、マージ作業が止まっているのは技術的問題以外の何物でもありま
せん。
ただ、Hans Reiser がこれらの問題の解決に大して協力しなかった事は本当で
す。
Reiser4 が充分安定しており、後で問題は全て修正するからマージすべきだと 
Linux 開発者に言う事は、大した助けにはなりません (上記の Q1 参照。Hans
Reiser は何年もの間、Reiser4 が完成していると主張してきました)。
あなたを嫌う VFS メンテナーがどれだけ多いか、彼らと比較されたあなたの
コード作成者 (訳注：Reiser4 開発者達) がどれだけ賢いかのどちらを考慮す
る助けにはなりません。
彼らが一部の Reiser4 の先進的な機能を無効化するよう要求したからと言っ
て、それが Linux メンテナー達がどれだけ思慮が浅いかを述べる助けにはな
りません (これらの機能は VFS の不和を招き、Reiser4 は結局これらを無効
化しました)。
彼らが Reiser4 が今日マージされるのを許可していないからと言って、いか
に Linux が WinFS と同じ悲しい運命をたどるか、そして (他人が Hans の予
測に同意しないのは自由であるにもかかわらず) Hans が「正しいこと」を行
うのを助ける代わりに彼にバグ修正を要求するのがどれだけ凶悪かを再三言及
する助けにはなりません。
それは単に Reiser4 が ext3 より高速だからという理由で、Linux VFS を 
Reiser4 のプラグイン層に置き換えるべきであるとカーネル開発者に提案する
為の助けにもなりません。

Attacking people when they disagree with you is not the right way of
talking within a Open Source community (or any community for that
matter), neither is it helpful to try to convince kernel developers to
merge Reiser4 talking to them with marketing speak. That however will
not stop Reiser4 from getting into the kernel, but it certainly makes
things more difficult. Some people have said that Hans is not the
right person to deal with the rest of the kernel community. I think
that almost everyone agrees. Reiser4 programmers are certainly more
friendly, and like most of normal programmers they focus on technical
discussions and they know to say "OK, you're Linux developers, so you
probably know better than me how a Linux filesystem must be written".

人があなたに同意しない場合にその人を攻撃する事は、オープンソースコミュ
ニティ (あるいはこの種のどんなコミュニティでも) における話し合いの正し
い方法ではありませんし、また商売口調で Reiser4 を語る事が Reiser4 のマー
ジをカーネル開発者に納得させる助けにもなりません。
それは Reiser4 がカーネルに取り込まれるのを止めはしませんが、物事をよ
り複雑にはするでしょう。
一部の人々は、Hans が他のカーネルコミュニティと接するのに適切な人間で
はないと言いました。
私は、ほとんど全ての人がその意見に同意すると思います。
Reiser4 のプログラマー達は確かに Hans よりはフレンドリーであり、通常の
プログラマー達の大部分のように彼らは技術的議論に集中し、彼らは「OK、あ
なたは Linux 開発者だから、多分私よりも Linux のファイルシステムがどう
書かれているべきかを知っているはずだ」と言う事を知っています。

Q4. "I've been using it for years and it rocks, how can't it be
ready?"

Q4.「私は長い間 Reiser4 を使っており、Reiser4 は堅牢です。Reiser4 は準
備ができているとは言えませんか？

You are not a kernel programmer, aren't you?
あなたは、カーネルプログラマーではありませんね？

最終更新日：2006/7/19 6:50:59 by TobiasKlauser

Licensed under a Creative Commons Attribution 2.5 License
Creative Commons Attribution 2.5 License の下にライセンスされています。
