2月版　OOM killerとの危険な関係に終止符は打てるか

上川純一
日本ヒューレット・パッカード株式会社
コンサルティング・インテグレーション統括本部
2008/2/29

起動時のfsckって時間かかり過ぎじゃない？

　1月のLKMLでは、fsckを高速化するための話題がいくつか出ていました。

　Linuxシステムを起動する際には、fsck（file system check）が実行されます。ext3システムであれば、ジャーナル機能があるので通常はほとんど時間はかかりません。しかし、一定期間ごとに1回、もしくは一定の起動回数ごとに1回は、ファイルシステムの整合性を確認するために長時間のfsckが掛かります。

関連記事：
	ジャーナリングファイルシステムが保護する「情報」 http://www.atmarkit.co.jp/flinux/rensai/fs03/fs03a.html

　例えば、fsckのタイミングを期間で決めている場合、久しぶりにサーバをリブートすると、問題があってもなくても、起動シーケンスの一部としてfsckが掛かります。このため、なかなかサービスがオンラインにならないという悩みがあります。ただ、ファイルシステムに不整合がある可能性もあるため、まったくfsckを掛けないのは不安です。ここは悩ましいところです。

　このジレンマを技術的に解決する方法として、Valerie Hensonがfsckを並列化することで処理を高速化する「Parallelize IO for e2fsck」という提案を行ったり、Abhishek Raiがメタクラスタリングの手法を使ってext3のfsckを高速化する「Make Ext3 fsck way faster」という提案をしていました。

　fsck自体の高速化は喜ばしいことですが、これらのパッチがマージされるにはしばらく時間がかかりそうです。また、システムの起動時にサービスのダウンタイムがあることに変わりはありません。

　一方、これを運用で回避する方法もあります。

　Ted Tsoは、「device mapper snapshotを利用してファイルシステムのスナップショットを作成し、そのスナップショットに対してe2fsckを実行してしまえばよい。もしe2fsckが成功すれば、ファイルシステムの整合性には問題がないことが分かる。そこでtune2fsで、スナップショット元ファイルシステムの『前回のfsckからマウントした回数』と『前回fsckを実施した日時』をリセットしてしまえばよい」と説明しました。

e2fsck -p /dev/XXX-snap tune2fs -C 0 -T now /dev/XXX"

　つまり、システム負荷に余裕のある時間帯に定期的に実行するようにしておけばよいというわけです。

　それを受けてKyle Moffettは「Poor man's background scrubbing」として、device mapperを直接操作するのではなく、LVMスナップショットを利用してfsckを実行する運用手法を紹介しました。

　つまり、LVMでスナップショットを作成し、それに対して整合性チェックの操作を行えばよいというアプローチです。具体的には、${VG}/${VOLUME}-snapに対してfsckを実行し、fsckが無事に成功したらtune2fsを実行するというものです。作業が終われば、スナップショットは削除してしまえばいいのです。

コマンド スナップショットの作成 lvcreate -s -n "${VOLUME}-snap" "${VG}/${VOLUME}" スナップショットの削除 lvremove "${VG}/${VOLUME}-snap" LVMでのスナップショットの取り扱い

　近年、利用可能なディスク容量の増大に伴い、fsckにかかる時間も延びてきました。こういう運用上の回避策を用意することも重要ですよね。

関連記事：
	Linux Tips：ファイルシステムチェックのタイミングを表示・変更するには http://www.atmarkit.co.jp/flinux/rensai/linuxtips/760ext3chk.html

-stableの進ちょく

　1月のGreg KHの-stableリリースでは、ローカルユーザーがファイルシステムを不整合な状態にできるバグを修正する緊急リリースと、ハードウェアが壊れるバグに対応するリリースがありました。深刻なバグにのみ対応したようですね。

　一方、1月の2.6.16系列を見ると、Adrian Bunkは合計3つの大きめのリリースをしています。セキュリティホールの対応もあれば通常の修正もあります。

■2.6.16.y: Adrian Bunkが管理しているツリー

• 2.6.16.58（1月16日）：Adrian Bunk
  ・tmpfs: restore missing clear_highpage（CVE-2007-6417）
  ・PPPOE: fix memory leak (local DoS)（CVE-2007-2525）
  ・Handle bogus %cs selector in single-step instruction decoding（CVE-2007-3731）
  ほか、17パッチ
  

• 2.6.16.59（1月19日）：Adrian Bunk
  ・wait_task_stopped: Check p->exit_state instead of TASK_TRACED（CVE-2007-5500）
  ・limit minixfs printks on corrupted dir i_size（CVE-2006-6058）
  ・Use access mode instead of open flags to determine needed permissions（CVE-2008-0001）
  ほか、15パッチ
  
  
• 2.6.16.60（1月28日）：Adrian Bunk
  ・vfs: coredumping fix（CVE-2007-6206）
  ・I4L: fix isdn_ioctl memory overrun vulnerability（CVE-2007-6151）
  ・isdn: avoid copying overly-long strings（CVE-2007-6063）
  ほか、15パッチ

■2.6.22.y: Greg K-Hたちが管理しているツリー

• 2.6.22.16（1月15日）：Greg K-H
  ・オープンの権限の確認のためにオープンフラグではなくアクセスモードを利用する（CVE-2008-0001）
  以上、1パッチ

■2.6.23.y:Greg K-Hたちが管理しているツリー

• 2.6.23.13（1月10日）：Greg K-H
  ・hwmon: (w83627ehf) VID入力レベルの変更をより慎重に行う（このパッチを適用しなかった場合、ハードウェアが壊れたかもしれません）
  以上、1パッチ
  

• 2.6.23.14（1月15日）：Greg K-H
  ・オープンの権限の確認のためにオープンフラグではなくアクセスモードを利用する（CVE-2008-0001）
  以上、1パッチ
  

（以上、敬称略）

2/2

Index Linux Kernel Watch　2月版 　2月版　OOM killerとの危険な関係に終止符は打てるか

Page 1 　リリースサイクルを気にしてる？ 　モジュールじゃなくなっちゃったセキュリティ「モジュール」 　ポート80で待ってるよ 　OOM killerとの危険な関係 Page 2 　起動時のfsckって時間かかり過ぎじゃない？ 　-stableの進ちょく

連載 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カーネルの開発体制などについて伺った
	more

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）