6月版 君は知っているか？ 2.6.30の変更内容を
小崎資広
2009/7/1
今年の「セキュリティ＆プログラミングキャンプ」（注1）の講師をすることになってしまい、講義準備とこの原稿の締め切りがバッティングして大忙しの筆者です。皆さま、いかがお過ごしでしょうか。
今月は、6月10日にリリースされた2.6.30を中心に見ていきたいと思います。それではどうぞっ。
| 注1：http://www.jipdec.or.jp/camp/。この記事が公開されるころには締め切り間近だと思うのですが、これはすごいよ。有料のカンファレンスでも、この面子が一堂に集まるなんてあり得ない講師陣です。Linux以外のコースも注目です。……お盆の時期に時間が取れる学生限定ですが。 |
| 関連記事： | |
 |
2つの日本発プロジェクトがマージ、Linuxカーネル2.6.30（＠IT News） |
ファイルシステム周りの追加
■日本発のログ構造化ファイルシステム「NILFS」
NILFS（New Implementation of a Log-Structured File System）は、Ryusuke Konishiさん（NTT）らによって開発された、Linux初（注2）の実用的なログ構造化ファイルシステム（Log-Structured Filesystem：LFS）です。
NILFSは以下の特徴を持っています。
- すべての書き込みがアペンドライト（追加書き込み）となるので、どんなタイミングでクラッシュしてもデータは消えない（ほとんどのファイルシステムはメタデータは壊れないが、実データは壊れます）
- 同じくアペンドライトなので、書き込みはシーケンシャルアクセスばかりになり、ワークロードによっては性能が劇的に向上する
- メタデータだけでなく、実データもチェックサムで守られているので、データ化けも強力に検知する（ただし現在は、マウント時のリカバリ処理にのみ使用）
- 定期的、かつ自動的にチェックポイントが作られるので、いつでも過去のデータを取り出せる。うっかりデータ削除してしまって泣くことはもうありません
- ファイルシステム・ネイティブのスナップショットをサポート。LVMスナップショットと異なり、スナップショット作成時にダーティーページの書き出しが不要のため、業務を「まったく」止めずにバックアップ処理が可能
日本では、まだいまひとつマイナーなNILFSですが、海外ではすごく有名です。the Linux Storage & File System Workshop 2008（LSF08）で、サムスンが「SSD上でのファイルシステム性能を測定したらNILFSの圧勝だった」と報告（注3）したことをきっかけに一気にブレイク、本家slashdotやLWN.netではSSDの話題が上がると必ず言及されるファイルシステムの1つとなっています。
作者に取材したところ、現在の評価は本意でもない部分もあるそうで、性能的にまだ納得いっていない部分も多々あるとのこと。今後しばらくは性能チューニングが開発のメインになるのではないか、と見通しを語ってくれました。今後が楽しみですね。
| 注2：以前からJFFS、JFFS2がLFSベースのファイルシステムとして存在しましたが、フラッシュメモリ専用ファイルシステムという位置付けであり、一般のHDDに使えるものではありませんでした。 注3：http://www.usenix.org/event/lsf08/tech/shin_SSD.pdf |
■EXOFS
最近のSCSIにはOSD（Object Storage Device）というオブジェクトベースなコマンドセットが定義されています。
従来のSCSIコマンドでは、ディスクを巨大な配列として抽象化し、「何番目のブロックにアクセスするか」という形でコマンドを送っていました。OSDではObjectという概念が加わり「あるObjectのある特定のオフセットにアクセスする」という形でコマンドを送ります。ここで、オブジェクトをファイルと同一視すれば、要するにファイルへの読み書きと同じことです。
ファイルシステムの役割の1つに、「ファイル」という抽象概念をデバイスのブロック番号に変換することがあります。これをストレージ側の責任に移すことにより、ファイルシステムのコードを非常に簡素なものにすることができます。EXOFSはそのようなリッチなストレージを前提とした、非常に薄いラッパーファイルシステムです。
もちろん、現時点ではOSDプロトコルを理解するHDDは存在しません。実際には、ストレージケーブルの先には生のHDDではなく、高度な分散処理をする高性能なストレージサーバをつなげる必要があります。Panasas（EXOFSの開発元）は、そのようなOSDベースのストレージクラスタ製品を販売しています。
また、OSDはpNFSの構成パーツの1つであることから、Linux版pNFSの開発が加速されることも期待されています。
■POHMELFS
POHMELFS（Parallel Optimized Host Message Exchange Layered File System）はクラスタ向け高速分散ファイルシステムであり、以下の特徴を持ちます。
- MO（E）SIライクなキャッシュコヒーレンシ・メカニズムにより、たとえ複数のノードが同時に同じファイルに書き込みを行っても内容が失われることはありません
- 一貫性のためのロック（システムコールのロックとは別に、普通のread／write時に暗黙に取られるロック）はバイト単位で行われ、キャッシュラインサイズやページサイズなどのハードウェア特性の影響を受けません。例えば、アプリケーションをMPIで並列化し、ファイルサイズ4000のファイルに対して4つのプロセスで書き込みをするとします。普通に考えると、各プロセスが1000バイトずつ書き込めばいいのですが、ファイルシステムの実装の都合でロックがページ単位だったりするとこれらの書き込みは競合してしまい、並列化してもまったく性能が向上しないことも起こり得ます。このようなことが起きると、並列アプリケーションなんか作っていられないので、バイト単位の処理はHPC業界ではとても重要視される性質です。
- あらゆるイベントを非同期処理します。read／write以外の処理、例えばファイル作成などは排他の関係もあり、サーバの応答を待つ同期処理で実装したいという誘惑に駆られますが、そういうことをすると、tarファイルの展開などがローカルファイルシステムに比べて有意に遅くなり（ネットワークのRTT×ファイル数で効きますからね）、カーネルソースのような大量のファイルを含むアーカイブを展開しようとしたハッカーが怒り出すことになります。実際、tarの伸長速度は分散ファイルシステムの性能指標の中でも性能を出すのが難しいので、POHMELFSの議論でもしばしばキーワードとして登場しました（ちなみに、POHMELFSはカーネルソースのtar伸長がNFSの40倍速いそうです）。
- あらゆるベンチマークでNFSより（圧倒的に）高性能
- マルチサーバおよびトランザクションのサポート。あるオペレーション中にサーバがクラッシュした場合は、タイムアウト後に別サーバに処理を再送することにより自動継続
- クライアントのread要求が自動的に複数のサーバに分散されて発行されることにより、ネットワーク帯域を極限まで有効活用
カタログスペック的にはとても魅力的なPOHMELFSですが、唯一の欠点は、使用実績の少なさです。採用している企業やディストリビューションもないようですし、LKMLでも誰にもレビューしてもらえず、（ドライバでもないのに）stagingツリーから強引にマージすることになってしまいました。
Andrew Mortonなど何人かは、POHMELFSを次世代ネットワークファイルシステムとして期待している向きもあるのですが、人柱が現れないことには普及への道のりは険しそうです。
なお名前の由来ですが、公式な情報は見つけられなかったのですが、slashdotで「pohmele」はロシア語で「二日酔い」という意味なので、そこから取ったのではないかという説が取り上げられていました。
■FS-Cache
Solarisなどでは「CacheFS」という名前で提供されている機能であり、NFS、isofsなどの遅いファイルシステムに対してHDDへのキャッシュを提供する機能です。
■relatimeがデフォルトでONに
いくつかのディストリビューションですでに長い実績がある「relatime」が、メインラインでもデフォルトになりました。
POSIX標準に従っているファイルシステムでは、ファイルにatime（access time）という最終アクセス時刻を記録するフィールドがあります。が、これがまったく使えない機能で、すでにキャッシュされているファイルをreadするだけでも、i-nodeのatimeが変わってしまい、ディスクIOが発生してしまうのです。さらに、これはメタデータの変更であり、ext3などではジャーナリングされるので、べらぼうに遅くなります。かつ、実際のアプリケーションではほぼ使われていないという状況でした。Linuxの初級チューニングTipsとして、さまざまな場所でnoatimeマウントオプションが推奨されてきました。
しかし、noatimeでは、以下のアプリケーションが動作しなくなるという有名な既知の問題がありました。
- mutt
muttは、atimeとmtimeを比較することで新着メールの確認を実施しています。atimeが更新されなくなると、この比較が意味を成さなくなってしまいます。 - tmpwatch
tmpwatchは現在時刻とファイルのatimeとを比較し、あまりにも古いファイルを削除するソフトです。主に/tmpに消し忘れファイルがたまらないようにする目的で使われます。しかし、noatimeを指定すると、頻繁に使っているファイルもどんどん消されてしまうため、tmpwatchの使用をあきらめるしかありません。
この問題に対処するため、relatimeは以下の動きをします。
A. atimeがmtime、ctimeよりも古いときは更新する（これでmuttは救われる）
B. そうでない場合も、現在時刻とatimeの差が24時間以上ある場合は更新する（これでtmpwatchは救われる）
C. それ以外の場合はatimeを更新しない
これにより、noatimeの同等の性能が悪い副作用なしで実現できます。なお、マウントオプション「strictatime」で従来の挙動に戻すこともできます。
| 5月版へ |
1/2 |
 |
|
||||
|
||||
 |
連載 Linux Kernel Watch |
| Linux Squareフォーラム Linuxカーネル関連記事 |
 |
連載：Linux Kernel Watch（連載中） Linuxカーネル開発の現場ではさまざまな提案や議論が交わされています。その中からいくつかのトピックをピックアップしてお伝えします |
|
連載：Linuxファイルシステム技術解説 ファイルシステムにはそれぞれ特性がある。本連載では、基礎技術から各ファイルシステムの特徴、パフォーマンスを検証する |
|
特集：全貌を現したLinuxカーネル2.6［第1章］ エンタープライズ向けに刷新されたカーネル・コア ついに全貌が明らかになったカーネル2.6。6月に正式リリースされる予定の次期安定版カーネルの改良点や新機能を詳しく解説する |
|
特集：/procによるLinuxチューニング［前編］ /procで理解するOSの状態 Linuxの状態確認や挙動の変更で重要なのが/procファイルシステムである。/procの概念や/procを利用したOSの状態確認方法を解説する |
|
特集：仮想OS「User
Mode Linux」活用法 Linux上で仮想的なLinuxを動かすUMLの仕組みからインストール／管理方法やIPv6などに対応させるカーネル構築までを徹底解説 |
|
Linuxのカーネルメンテナは柔軟なシステム カーネルメンテナが語るコミュニティとIA-64 Linux IA-64 LinuxのカーネルメンテナであるBjorn Helgaas氏。同氏にLinuxカーネルの開発体制などについて伺った |
|
- 【 pidof 】コマンド――コマンド名からプロセスIDを探す （2017/7/27）
本連載は、Linuxのコマンドについて、基本書式からオプション、具体的な実行例までを紹介していきます。今回は、コマンド名からプロセスIDを探す「pidof」コマンドです。 - Linuxの「ジョブコントロール」をマスターしよう （2017/7/21）
今回は、コマンドライン環境でのジョブコントロールを試してみましょう。X環境を持たないサーバ管理やリモート接続時に役立つ操作です - 【 pidstat 】コマンド――プロセスのリソース使用量を表示する （2017/7/21）
本連載は、Linuxのコマンドについて、基本書式からオプション、具体的な実行例までを紹介していきます。今回は、プロセスごとのCPUの使用率やI/Oデバイスの使用状況を表示する「pidstat」コマンドです。 - 【 iostat 】コマンド――I/Oデバイスの使用状況を表示する （2017/7/20）
本連載は、Linuxのコマンドについて、基本書式からオプション、具体的な実行例までを紹介していきます。今回は、I/Oデバイスの使用状況を表示する「iostat」コマンドです。
 |
|
|
|
|
