最新開発版カーネル 2.3.28

このリリースで壊れたままになっているものの一つに、 RAM ディスクについてのことがあります。 現在の RAM ディスクの実装は、 2.3 カーネルの新しいメモリ管理と収まりが良くありません。 誰かがこの問題を修正するまで、RAM ディスクは使用できません。

※ Linux カーネルにおける RAM ディスクは、Initial RAM disk として、Red Hat 等の Linux システムの起動時にも使われていますから、この影響は大きいと思われます。

最新安定版カーネル 2.2.13

※ 翻訳時点 (11/19) で 2.2.14pre7 が出ています。 Sparc と PowerPC に関するアップデートや、 その他の修正がなされているようです。

※ カーネルリリースの最新情報はこちら（日本語）をご確認下さい。

なぜ ext2 のデフラグツールを誰も保守してないの？

※ フラグメント化 (fragmentation) - 一つのファイルの最初から最後までが、ディスク上で物理的に連続した場所に保存されるとは限りません。（ユーザはもちろん、それを意識する必要はありませんが。） ファイルシステムの中に、ファイル中のデータがあちこちにバラバラに格納されている状態のことをフラグメント化と言います。ハードディスクの特性上、一つのファイルのデータは一箇所に固まって格納されているほうが、アクセス性能が向上します。

※ Windows や MS-DOS で使用されている FAT ファイルシステムはフラグメントに弱く、専用のユティリティを使って定期的に「デフラグ」する必要があります。このため Windows から移行して来た方の中には Linux にデフラグツールが見当たらないので心配になる方もいらっしゃるようです。

※ FAT ファイルシステムがフラグメントに弱い理由は FAT の設計（原理的なやむを得ない理由）だけではなく、Windows 上の実際の実装、つまりディスク領域の割り当て方法が良くないせいもあります。その証拠に OS/2 は FAT を使用していながら、ある程度フラグメント化を防ぐことができるそうです。

より大きなファイルについては、 一つの例外だと言えるでしょう。 ファイルが ext2 の "block group" の大きさを越えると、 システムには選択の余地はなく、ある程度フラグメントしてしまいます。 この「マジックサイズ」は、 ファイルシステムを作成する際に使われたブロックサイズに依存します。 古い ext2 ファイルシステム --- そこら中でたくさん使われています --- は 1K バイトのブロックサイズを使っています。 そして 8 M バイトよりも大きなファイルはフラグメントを起こしてしまいます。

※ 古いといってもつい最近の e2fsprogs-1.14 まで、mke2fs コマンドのデフォルトは 1K バイトでした。これはオプション -b で変更できます。

※ e2fsprogs-1.15 以降に含まれる mke2fs コマンドでは 512M バイトを越えるファイルシステムにデフォルトで 4K バイトのブロックサイズを使用します。ちなみに、使用中の ext2 ファイルシステムのブロックサイズは以下のコマンドで調べることができます。

# /sbin/tune2fs -l /dev/????

これは、もちろん、次の質問を誘導します： 1K バイトのファイルシステムは、使用中のまま 4K バイトに変換できるでしょうか？ 残念ながら答はノーです。現在そのようなユティリティは存在しません。 ファイルシステムをバックアップして、作成し直し、ファイルを復元することが必要です。 ほとんどのアプリケーションにとっては、この手間に報いる程のメリットはありません。

※ つまり、ファイルが 8M バイト単位でフラグメント化されたからといって、ほとんどのアプリケーションには性能上の問題は無いということでしょう。そして 4K バイトのブロックサイズを採用すると、小さなファイルが多いとディスクの使用効率が落ちることにも注意して下さい。以下は Linux カーネルのソースを展開した場合の結果です。

○ 1K バイト／ブロックの場合
総容量 (KB)	使用容量 (KB)	空容量 (KB)	使用率
497667	65446	406519	14%
○ 4K バイト／ブロックの場合
総容量 (KB)	使用容量 (KB)	空容量 (KB)	使用率
497928	74784	397444	16%

総容量は 4K バイトのほうが多くなります (このため個々のファイルのサイズが大きく、その数が少ない場合はむしろ効率が良い) が、使用容量がそれ以上に増えており、結果として、ディスク使用効率が下がっています。

暗号化 HOWTO

次期カーネル開発ソースコード管理システム BitKeeper まもなく登場

※ BitVapor - なかなかリリースされない BitKeeper に対する、もしかして Vaporware（宣伝ばかりが派手になされ実物がなかなか出てこない製品） ? という皮肉です。

※ リポジトリ - ソースコード管理システムでは、ソースコードのすべてを含んだアーカイブ (というか一種のデータベース) のことをこう呼びます。

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

• x86 パフォーマンスカウンタパッチの Version 0.8 が Mikael Pettersson 氏からリリースされました (英語) 。

• SGI の Matt Robinson 氏が、Linux クラッシュダンプパッケージ のバージョン 1.0.3 を リリースしました (英語)。

• 上記とは異るアプローチのクラッシュダンプが David Winchell 氏から公開されました (英語)。 (※ SGI のクラッシュダンプがスワップ領域に退避するのに対して) この版は、システムの状態をディスクにダンプするのではなく、 メモリに保存し、直後のブート時にセーブします。 これにより、システムが良くない状態だと分かっているときに ディスクに書き込みを行うことを避けることができます。

• Chris Wing 氏が、32 ビット UID パッチの新しい版を リリースしました (英語) 。

• Ulrich Windl 氏が、ナノ秒単位での時刻管理を可能とする PPSkit 0.9 (英語) をリリースしました。

• Richard Gooch 氏の devfs パッチがバージョン 143 (英語) になっています。 devfs の 2.2 への移植版はバージョン 99.9 (英語) になっています。

関連 URL

LWN

カーネル（原文）

Kernelnotes

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

Kernel traffic

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

Kernel Newsflash

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