カーネル読書会宣言

最新開発カーネル

最新安定カーネル

開発作業はどのように進められるべきか

PCMCIA サブシステムの作者である David Hinds 氏は、 PCMCIA カードのような動的ハードウェアの より良いサポートに取り掛かっていました。 このサポートは、 来るべき「ホットプラグ PCI」や USB のような、 もう一つのより新しい「ホットプラグ」アーキテクチャに拡張されることを 目的としています。 David の作業は、 ハードウェアとそのハードウェアによって使用されるリソースと を別々に追跡することを容易にするために、 古いリソースマネージャに変更を加えることを必要としていました。 そして、その線での作業は良い方向に進み始めていました。

Linus の新しいリソースマネージャは、 そんな中、突然現れました。 前もっての議論（少なくとも公的には）は、ありませんでした。 Linus の行う変更は、 このような一種の「既成事実」モードで現れて来る傾向にあります。 David の変更は過去のものとなり、 彼のハードウェア追跡も今となっては動きません。

David は 彼の作業結果を再び動かすことができるようにするため 小さな変更をいくつか頼みましたが、 Linus は協力を渋っています。 開発作業がどのように進められるべきかについては、 かなり強い意見の相違があるようです。 そしてそれによって、 いくつかの必要とされている機能の開発に支障を来たすという結果にも なりうるのです。 近いうちに何らかの解決が見られることを望むばかりです。

「Linux ストレージ管理ワークショップ」

今週のパッチとアップデート

• 2.2、2.0 の両カーネル用最新 RAID パッチ が アナウンス （英語） されています。 おそらく、Linux 上で本格的な RAID を組むことを考えている方は 採用すべきだと思われます。 運が良ければ、 2.2.12 カーネルに含まれるかも知れません。

• IEEE 1394 (FireWire) パッチの新バージョン （英語） が Emanuel Pirker 氏により 発表されています。 競い合っていた 2つの FireWire のプロジェクトが 現時点ですべてマージされ、 開発はより高速に進んでいます。 けれども、実用に耐えるものになるまでには、 まだいくつかカバーされるべき局面があります。

  ※ FireWire (IEEE 1394) は、USB のような外部拡張バスの標準規格で、 USB が 12Mbps なのに対して、IEEE 1394 では 400Mbps にまで 高速化されます。ただし、まだ高価です。

• いつものように、H.J. Lu 氏により knfsd パッチ （英語） が公開されています。 2.2 カーネル上で本格的な NFS サーバを走らせる ためには、（特に異種混合環境の場合には） まだこれらのパッチが必要です。 これらは 2.2.11 には含まれ「ない」予定です。 （他のものが多く含まれ過ぎていて、パッチがすでに巨大なため。） けれども 2.2.12 には重要視され含まれる可能性が高いです。

• Richard Gooch 氏からの devfs パッチ （英語） なくして、 カーネル開発の 1週間は語れないでしょう！

• 論理ボリュームマネージャ（LVM） 0.7 （英語） が Heinz Mauelshagen 氏によって リリースされています。

• カーネル 2.2.10 と 2.3.10 両方のための TCP Vegas パッチ （英語） が Neal Cardwell 氏によって 発表されました。 Vegas は、多くのトラフィックがある インターネットのような場合において、 TCP をうまく作動（そして効率良く）させることを目的とした 渋滞回避アルゴリズムです。

最新カーネル

2.3.12 のための pre-patch が公開されています。 このパッチは大きいようですが、 これはほとんどパラレルポートドライバの場所を 移動したことによるものです。 USB の作業結果がいくらか、 ファイルシステム関連の変更がたくさん、 そして面白いことには、 Stephen Tweedie 氏の Raw I/O パッチが含まれています。

Raw I/O

Stephen のアプローチは、 他の Unix システムで見られるものと違っています。 例えば Solaris では、 ディスクパーティションには /dev/dsk/c0t0d1s0 みたいな名前が付いています。 そして、そのようなパーティションそれぞれに、 「raw」アクセスを提供するような /dev/rdsk/c0t0d1s0 が自動的に存在します。 Linux の仕組みでは、そうではなく、 デフォルトでは「raw」アクセスは存在しません。 特定のデバイスへの「raw」アクセスを許したいシステム管理者は、 それをセットアップするためにヘルパープログラムを走らせることになります。 これがどのように動くのかについての詳細は、 Stephen からのノート （英語） にあります。 良い感じです。

アイドル CPU 時間のスケジューリング

もし、CPU を必要とする他のプロセスが走っているときには、 そのようなプロセスを完全にプロセッサからブロックすることができるのであれば、 素敵だと思いませんか？ Rik van Riel 氏が、 新しいスケジューリングのクラスである SCHED_IDLE を実装するパッチを しばらく前から公開していたことが分かりました。 このクラスのプロセスは、 本当に他に何もすることがないときにだけ走り始めます。 このパッチはまだ主流カーネルには含まれていません。 含まれない方が良い理由が一つあるからです。 システムを完全にロックアップしてしまう可能性を残しているからです。

想像してみてください。 しばらく楽しくクランク（継続的に実行）していき、 何か重要なシステムリソースのようなもの （システムで入手可能なバーチャルメモリすべて、 あるいは、ある重要なファイルのロックのようなもの） を保持してしまう、 SCHED_IDLE タスク。 そしてそこに、 よりプライオリティが高く CPU にへばり付くようなクランカーがやってきます。 はい、SCHED_IDLE プロセスはこうして完全にロック（ハング）してしまいます -- （始めからいて重要なりソースを握り締めたまま スリープしてしまった）このプロセスは、 （よりプライオリティの高いクランカーがやってきたために、 CPU から閉め出されてしまうので） その握っていたリソースを開放するために走ることができないのです。 さらに明らかになったことは、 このプロセスを kill することもできないのです。 何故なら、プロセスが何かをするための CPU 時間を獲得しない限り、 シグナルさえも届けられないからです。 結果は、ロック（ハング）してしまったシステム。 自ら DoS 攻撃を呼び寄せているようなものです。

この種の問題には、 「プライオリティ・インバージョン（priority inversion）」という一般名称が付けられています。 この問題は多くの状況下で持ち上がります。 プライオリティ・インバージョンは、 プロセスが重要なリソースを獲得したときにそのプロセスのプライオリティを 上げることにより対処することができます。 けれども、 カーネルの中で一貫したプライオリティの調整を行うのは厄介な作業です。 おそらく実際に実装するために必要となる作業は、 この特定の機能を実装するためなら取り組んでも割に合うと思える作業よりも、 ずっと面倒な作業になるでしょう。

そこで最終的に Rikは、 この問題を現実的な方法で処理しようとするパッチを リリース （英語） しました。 SCHED_IDLE クラスは生成されますが、 デフォルトでは無効にされています。 プロセスがこれを利用できるようにするためには、 システム管理者が sysctl システムコールを用いてこのクラスを有効にしなければなりません。 このことと、他の 2つのスケジューラの変更によって、 多くの利用において SCHED_IDLE が「十分安全」になるはずです。

今週のパッチとアップデート

• Kernel Debugger 0.5 （英語） が SGI によりリリースされました。 このパッチにより開発者が走行中のシステムの中を調査することができます。 Linus がカーネルデバッガには反対なので、 これはおそらく永遠にパッチである運命なのでしょう、、、 けれども、多くの方々にとって非常に便利なパッチになるでしょう。

• 類似の項目として、 Linux トレースツールキット （英語） が Kerim Yaghmour 氏によって リリースされています。 このパッチは、 カーネルが行うすべての活動の詳細なログの生成を可能にします。

• Richard Gooch 氏から、 四季を通して続く :-) devfs パッチ （英語） がリリースされています。

• 多くのカーネル処理の中の待ち時間を削減する パッチ （英語） が Ingo Molnar 氏によって公開されています。 当面の目標は、 一部のユーザが経験している 音飛び問題を修正することです。 ですが、この作業は全体的により反応の良いシステムへと 導くことになるはずです。

• Framebuffer HOWTO バージョン 1.1 （英語） が Alex Buell 氏により公開されています。

• RAID パッチ 1999.07.24 が リリース （英語） されています。 これは主にバグ修正リリースです。

最新開発カーネルリリースは 2.3.12

2.3 フィーチャーフリーズ

2.4 を心待ちにして、 Joseph Pranevich 氏が 「素晴らしき Linux 2.4 の世界」 （英語） の最初のバージョンを公開しました。 2.4 リリースに現れる予定の変更についての説明があります。 （※ Joseph Pranevich 氏の御好意により現在翻訳を作成させていただいております。 どうぞお楽しみに。）

最新安定リリースは 2.2.10

Sparc で 2.3 ？

あなたのバックアップに危険！

Linux の VFAT ファイルシステムは、 ロングファイルネームだけをユーザに見せます。 これは、ユーザが見たいのは長いファイル名だけだという 合理的な仮定のもとに行われています。 通常、これは申し分なくうまくいきます。 ですが、ここで、このファイルシステムをバックアップし、 将来的にいつか復元するという状況を想像してみてください。 すべてのロングファイルネームは元通りになりますが、 Linux は、それらとともに 8文字プラス3文字のファイルネームを 生成しなければなりません。 これらの 8文字プラス3文字のファイルネームは、 通常は以前あったものと同じに戻りますが、 いつもそうなるとは限らないのです。

8文字プラス3文字のファイルネームの変更は、 実際にそれに依存する特定のプログラム（例えば Office）の場合でなければ、 必ずしも問題にはなりません。 ロングファイルネームとショートファイルネームはまた、 Windows レジストリ内でごちゃ混ぜになる傾向にあります。 その結果、ちゃんと対応させ続けなければ深刻な破壊に繋がります。 理性のある人なら、 Windows のソフトウェアを使ってないのに VFAT を使う理由はありません、、、 ですから、これはかなり問題です。

そして、この問題は簡単には解決しないでしょう。 Unix の世界観では、 同じファイルのための2つの奇妙にリンクした名前を 取り扱うための用意などされてはいないのです。 最も普通のアイデアとしては、 ロングファイルネームを 8文字プラス3文字のファイルネームに リンク（ハードでもソフトでも）し、 ディレクトリを表示するときには両方をリストするというものです。 VFAT はリンクをサポートしていないため、 この使い方には曖昧（あいまい）なところがなく、 簡単な解決法のように思えます。

けれども本当にこの問題を考えてみると、 そうではないのです。 ロングファイルネームとショートファイルネームは、 Unix のリンクよりも、ずっと密接に結び付けられています。 ファイルへのリンクの一方の名前を変更（リネーム）したときに、 もう一方も変わるなんて、誰が思います？ ディレクトリもまたロングファイルネームを持っているので、 ハードリンクを使うなんて、もってのほかです。 ディレクトリにハードリンクするのは、 ほとんどすべての Unix 系システムにおいて、 トラブルに直結しています。 シンボリックリンクででさえも、 すべてを本当に正しく動かそうと試みるのは、 そうですねえ、 蟻（アリ）塚に縛り付けられるのと比べて、 もう少しだけ楽しくない、といったところでしょうか。;-)

この問題が解決できるのかどうかは、はっきりとはしていません。 それでは、これは一体どれくらい重要な問題なのでしょうか。 どうやら Windows 上で走るほとんどすべてのバックアッププログラムが 同じ問題を抱えているようです。 結局、 VFAT は Windows の利用の場合においてでさえも、 並外れてイヤなものなのです。 これを正しく動かすためには、 ただただ、やらなければいけないことが多すぎるのです。

SCHED_IDLE についてのノート

• Rik van Riel 氏によると、彼のパッチのバージョンが 先週の LWN でお知らせしたものから上がっています。 最新バージョンは、 Rik のカーネルパッチのページ （英語） をご覧下さい。

• Artur Skawina 氏が、 （現在の解決法に） 匹敵する実装 （英語） を投稿しています。 彼によると、この方がうまく動き、 通常の（SCHED_IDLE でない）場合には、 まったくコストを強いない（まったく性能劣化がない）とのことです。

• Victor Yodaiken 氏は、 SCHED_IDLE が引き起こす可能性のある 数しれないデッドロックと性能問題を恐れて、 ノート （英語） を投稿しました。 このノートでは、この問題を処理するまた違った方法が議論されています。 これは、ユーモアに溢れていて、かつ、説得力があるので、 必見です。

  「僕達が解決しようとしている問題を考えてみてよ。 ばかげた問題だよ。

  問題：本質的でないバックグラウンドのタスクが CPU 時間使いすぎ。

  問題解決空間(1)

  解決法 1：そんなタスクは走らせない。

  解決法 2：他のタスクを走らせる必要のあるときには、それを kill する。

  解決法 3：システムがアイドルかどうかによって、 意味ないタスクを一時停止したり再開したりする 「意味なしタスク」デーモンを走らせる。

  解決法 4：もっと速いプロセッサを買う。あるいは、君んちの Beowulf クラスタの ノードを一つ増やす。

  解決法 5：NT を 1週間走らせる。それから Linux に戻る。 5％の CPU 時間の無駄なんて、気にならなくなる。」

  ※この下に問題解決空間(2)があって、真面目な議論が展開されています。

今週のパッチとアップデート

• Jens Axboe 氏が Linux の CD と DVD に関する開発のための ウェブページ （英語） を立ち上げました。 CD-RW と DVD 開発関連情報があります。 最新パッチのダウンロードも可能です。

• Yann Droneaud 氏が、 gas アセンブラ用に書き直しを行ったバージョンの ブートコードを投稿しています。 現在（今まで）このコードで使われている as86 アセンブラをそんなに好きな人はいませんが、 gas が大好きという方もあまりいません。 そこで、3つ目のアセンブラ（nasm）があります。 こちらはより魅力的のようです。 as86 がなくなるときには、nasm がその代役をつとめるかも知れません。 （こちらの 投稿 （英語） をご覧下さい。 またさらに興味のある方は 新しいブートコード （英語） もどうぞ。）

• Etienne Lorrain 氏が 新しいブートローダのアナウンスを 投稿 （英語） しています。 これは、LILO のようなプログラムに匹敵するものです。 それと違っている点は、しかし、 こちらは（まだ）動いていない、といったところです、、、

• Rolf Fokkens 氏が パッチ （英語） を投稿しています。 SCSI デバイスと、/dev にあるそれらの名前との対応を 多少コントロールできるようになります。 現在、SCSI チェーン上のあるデバイスを追加したり取り外したりすると、 SCSI チェーン上の他のデバイスすべての名前の変更を引き起こす可能性が あります。 これはシステム管理の方々を本当にイライラさせるものです。 このパッチは、 ハードウェアを変更するのが自分だと分かっている管理者の方に、 この問題に対する単純な解決法を与えるもののようです。

• 安定カーネルの新バージョン、2.2.11 のリリース間近（8/9追加）

関連 URL

LWN

カーネル（原文）(7/22)

LWN

カーネル（原文）(7/29)

LWN

カーネル（原文）(8/5)

LinuxHQ

他のカーネル関連リソース（英語）

Kernel traffic

他のカーネル関連リソース（英語）