8月版 ブート時間の短縮にかけるカーネルアスリートたち
小崎資広
2008/9/1
SSDドライブの耐用年数を増やすセクタ破棄リクエスト
先月、誌面を華やかにするのに貢献してくれたDavid Woodhouseがまたまたやってくれました。といっても今度はフレームウォーではなく、SSD(注4)向けの耐久年数向上パッチ「Discard requests」シリーズをポストし、LKMLをにぎわせています。
最近、EeePCやMacBook Airのように、HDDの代わりにSSDを採用したノートPCが増えてきています。SSDは通常のHDDと比較して、シーク時間が不要なためランダムアクセスが速いほか、小さい、低消費電力・低発熱であるといったモバイル向けの利点があります。一方で、書き込み回数に制限があり、一定回数の書き込み(一説には10万回が目安ともいわれますが、製品によって大きく異なるようです)により、使用不能になってしまうという欠点があります。
加えて、一般に使われているHDD向けのファイルシステム(ext2など)には、通常データ保存位置よりもメタデータ保存位置が非常に頻繁に更新されるという特性があります。この結果、昔は、安いフラッシュメモリ上にファイルシステムを作るとよく壊れるといわれていました。
これに対して、
(a)フラッシュメモリに適した特殊なファイルシステムを使う
(b)フラッシュメモリコントローラ側で細工を行い、書き込み位置を分散させる
という解決方法があるのですが、デスクトップ・サーバ分野では(b)のアプローチが好まれています。
ところが、(b)には1つ問題がありました。一般に、ファイルシステムからファイルを消す処理では、ディレクトリからのファイルデータ参照ポインタが消えたことをもって消去と見なしています。つまりファイル消去時にファイルデータは一切変更されません。
これは出荷後、ただの一度も使われていないブロックを除けば、どのブロックが現在消去済みブロックなのか、ローレベルのコントローラからは分からないということを意味します。ファイルシステムによっては、消去時に「0クリア」(=HDD内のデータをすべて0で上書き)するものもありますが、使用中ファイルに0クリアされたデータが収まっていることもあるので、0クリアをもって未使用と判断することはできず、解決になりません。
つまり、製品購入当初は、一度も書き込みされていない書き込み分散用に使える未使用ブロックが大量にあるが、年月を経るにつれどんどんその未使用ブロックが減っていき、書き込みがあまり分散されなくなってしまうということです。
実は、ATAプロトコルにはdiscardリクエストというプロトコル拡張があり、これによりブロックを未使用に戻すことができます。しかし、メーカが提供する専用フォーマットソフト以外ではほとんど使われていませんでした。
ここに目を付けて、ファイルシステムのファイル消去とともに、フラッシュメモリコントローラに「当該ファイルのデータが存在するブロックを未使用ブロックとして扱っても構わない」と教えてあげることができれば、フラッシュメモリの耐久年数が大幅に上がるのではないか……というのが今回のパッチのミソです。
ただ、実装上は、
1)ジャーナルファイルシステムにおいては、ジャーナルログがコミットされるまではファイル消去動作自体がロールバックされる可能性があるので破棄できず、通知タイミングが難しいこともあり、一番使われているext3に対応できていない
2)I/Oスケジューラのリクエスト順序入れ替えを考慮していないので、書き込みとdiscardが入れ替わるとデータがロストする
などの問題もあります。まだ「思い付きパッチ」感全開なので、メインラインへのマージはしばらくかかりそうです。
しかし、Andrew Mortonなどもそのアイデアと基本方針は認めています。SSDが本格的に普及するまでには完全なものが出来上がってくると期待したいところです。
注4:SSD=Solid State Driveの略。OSからはストレージのように見えるフラッシュメモリのこと。 |
-stableの進ちょく
2.6.26から新しいステーブルツリーがブランチされ、大量のパッチが送られています。また、ほとんどのパッチが2.25.yツリーにそのまま適用可能だったため、2.25.yツリーにも大量のパッチが流入しています。
パッチ一覧を見るだけでも大変なぐらいです。Greg K-Hには尊敬の念を禁じえません。
■2.6.25.y:
- 2.6.25.14(8月2日):Greg K-H
・VFS:pseudo-filesystem(/procなどの仮想的なfs)のblock sizeをPAGE_SIZE(x86なら4k)まで拡大
・hugepage:huge_ptep_set_wrprotect()において正しくハッシュをフラッシュするようにした
・__attribute__((__cold__))とマークされた関数の配置場所を.textセクションに戻した
・markers:marker定義を変更してカーネルを再コンパイルしたときに、以前の定義が消えずエントリが二重になってしまう問題を修正
・markers:複数のプローブを差し込んだときの処理にメモリバリアが抜けていた問題を修正
ほか、30パッチ
- 2.6.25.15(8月5日):Greg K-H
・ro bind mount実装の副作用でmkdirのエラー時の戻り値が変わってしまっていたのを元の動作に修正
・64bit kernel上で32bitデバッガを正しく動作させるために、PTRACE_GETSIGINFOのcompat handlerを実装
・fat:不正なパーティションテーブルを持ったメディアを検知できるようにした
・x86:32bit kernel上で64bitリソースに対するioremapが正しくハンドリングできていなかった問題を修正
・vfs:削除済みマークの付いたディレクトリ配下のファイルにlookupをすることで、新しい子dentryを作ってしまうことがあったのを修正
・jbd:free bufferとcommit transactionのレースを修正
ほか、35パッチ
- 2.6.25.16(8月20日):Greg K-H
・x86:spin_is_contended()の競合判定条件が間違っていたのを修正
・x86:古い486マシンがブートしなくなっていた問題を修正
・不正アドレスを与えたときのmlock()の戻り値が変わってしまっていたのを元に戻した
・posix-timers:posix_timer_event()とdequeue_signal()のレースを修正
・posix-timers:タイマ遅れが発生したときのオーバーラン時間の計算が間違っていたのを修正
・random32:シードの改善
ほか、50パッチ
■2.6.25.y:
- 2.6.26.1(8月1日):Greg K-H
・VFS:pseudo-filesystem(/procなどの仮想的なfs)のblock sizeをPAGE_SIZE(x86なら4k)まで拡大
・proc:/proc/*/pagemapのアクセス時にstatic変数を使っている個所があり、複数のプロセスが同時にアクセスするとメモリ破壊が可能であった問題を修正
・tmpfs:ファイル削除時にカーネルアサーションでパニックする問題を修正
・__attribute__((__cold__))とマークされた関数の配置場所を.textセクションに戻した
・markers:marker定義を変更してカーネルを再コンパイルしたときに、以前の定義が消えずエントリが二重になってしまう問題を修正
・markers:複数のプローブを差し込んだときの処理にメモリバリアが抜けていた問題を修正
・rcu:dynticksと組み合わせた場合においてgrace-periodが終わらなくなる問題を修正
ほか、63パッチ
- 2.6.26.2(8月6日):Greg K-H
・64bit kernel上で32bitデバッガを正しく動作させるために、PTRACE_GETSIGINFOのcompat handlerを実装
・x86:アイドルプロセスにNULLチェックを追加 ・x86:IO delay処理にNULLチェックを追加
・vfs:削除済みマークの付いたディレクトリ配下のファイルにlookupをすることで、新しい子dentryを作ってしまうことがあったのを修正
・jbd: free bufferとcommit transactionのレースを修正
ほか、27パッチ
- 2.6.26.3(8月20日):Greg K-H
・syncookies: 変数の初期化漏れによりECNがセットできなかった問題を修正
・x86:spin_is_contended() の競合判定条件が間違っていたのを修正
・x86:486マシンでブートできない問題を修正
・不正アドレスを与えたときのmlock()の戻り値が変わってしまっていたのを元に戻した
・posix-timers:posix_timer_event() と dequeue_signal() のレースを修正
・posix-timers:タイマ遅れが発生したときのオーバーラン時間の計算が間違っていたのを修正
・random32:シードの改善
・x86:AMD Opteronで(MTRRの)TOM2 maskが間違っていたのを修正
ほか、61パッチ
(以上、敬称略)
2/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」コマンドです。
|
|