4月版 遅れの原因はどこ? LatencyTOPで解析可能に


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


フラッシュデバイス向け? UBIベースのファイルシステム登場

 フラッシュデバイスは、組み込みデバイスなどで広く利用されている記憶装置です。一般に目にすることの多いSDカードやコンパクトフラッシュ(CF)カード、USBメモリなどでは、デバイス側でさまざまな処理をしてくれています。

 しかし、直接erase blockの管理などを行う必要がある場合には、Linux Kernelでその処理を行うことになります。このため、ブロックデバイスレベルでフラッシュデバイスを取り扱ってくれる仕組みとしてUBI(Unsorted Block Images)というものを実装しています。その上に実装されたのがUBIFS(UBI File-System)です。

 Artem Bityutskiyは、「NANDフラッシュの中には3000回までしか書き込めないものもある。また、データを書き込む前にデータを削除するのには時間がかかるため、別の場所に書き込む必要がある。そのような特性を持つデバイスには、それ相応の記憶の仕組みが必要だ」と説明しました。

 既存のJFFS2は、そうした目的のためにはよくできたファイルシステムです。しかし、マウント時にメディア全体をスキャンしてメタデータを計算するという特徴があり、このため、ストレージのサイズが大きいとマウントに時間がかかってしまうなどの課題があったようです。

 UBIはLinux Kernelにマージされていますが、UBIFSはまだ、これから議論を始めるステージにあるようです。フラッシュデバイスを利用するシステムでの開発にいかがですか?

アイコン いよいよ登場か、LVM3開発宣言

 Daniel Phillipsは「古い斧を直すにはどうするかい?」と始まるメールを出し、「LVM(Logical Volume Manager)3の開発を始める」と宣言しました。そして、それにつながるであろう一連のパッチについてレビューを依頼しました。LVM3の仕組みの基礎となるddlinkstacking bio supportです。

 Device Mapperの新しい仕組みであるddlinkは、とても挑戦的な提案です。論理/物理デバイス間のマッピング機構であるDevice Mapperは、活用すれば便利なはずの仕組みなのに、使いにく過ぎるのでアプリケーションが少ない。その課題を解決するため、使いやすいインターフェイスを設計したというのです。

 これまでioctlで実装されていましたが、問題を解決するために、ddlinkのインターフェイス用のファイルシステムを新しく導入しています。そして、read/write/ioctlを用いて、Device Mapperの仕組みを簡素に活用できるようにしています。

 とはいうものの、現在のところはまだ、利用可能なLVMの再実装がなされているというわけではないようです。でも彼は、LVM3に向けて開発する意気込みを表明しているので、もしかするとより便利なツールが多数登場するかもしれませんね。

関連記事:
リンク lvm3関連パッチ置き場
http://zumastor.org/lvm3/
リンク 全貌を現したLinuxカーネル2.6[第3章]
http://www.atmarkit.co.jp/flinux/special/kernel26/kernel26_03b.html
リンク LVMによる自動バックアップ・システムの構築
http://www.atmarkit.co.jp/flinux/rensai/root06/root06a.html

1Gbytes単位のページでメモリ管理

 仮想メモリ管理関連も活発に開発が進められています。その1つであるgbpagesを紹介しましょう。

編集部注:5月に、これまでのkernel watchで取り上げられてこなかったメモリ関係のパッチについての解説記事を掲載する予定です。

 x86 CPUでLinux Kernelを利用していると、メモリは通常、4kbytesのページ単位で管理されます。しかしそれだと、4kbytesごとに管理情報を持つことになるため、リソースを消費することになります。特に、TLB(translation lookaside buffer:仮想メモリと物理メモリのアドレスの対応をキャッシュする)がページ単位で必要になってしまうのです。

 そこで、ページを大きくすれば、TLBキャッシュミスが減り、アドレス変換の負荷が下がり、パフォーマンスが上がるはずです。そのためLinux Kernelには、以前からhugetlbfsという仕組みがあり、x86でも2Mbytesという比較的大きなページ単位でメモリを利用することが可能になっていました。

 最近のx86_64アーキテクチャのCPUでは、さらに大きく、1Gbytes単位でのページ管理が可能になったようです。

 Andi Kleenは3月17日に「GB pages hugetlb support」というタイトルで、hugetlbfsで1Gbytes単位のページを利用できるようにするパッチを投げました。ただし、利用に当たってはいろいろと注意事項があります。例えば、大きな連続メモリ領域を確保するため、起動時に領域を確保しておくような実装になっています。

 従って、動的で柔軟にメモリを確保しなければならないような用途には難しいかもしれません。しかし、特定用途の計算専用機やDMBS、あるいは仮想マシンの実行などの用途に利用できそうですね。これからマージに向けてどのように改善されていくのか、気になるところです。

-stableの進ちょく

 3月の-stableリリースは、いつもに比べて静かでした。並行してメンテナンスされていた各バージョンがリリースされておらず、新しいリリースもまだ出ていない状態です。大きなセキュリティホールを修正するリリースが多数出ていた2月から一転して、平和だったようですね。

■2.6.24.y: Greg K-Hたちが管理しているツリー
  • 2.6.24.4(3月24日):Chris Wright
    ・TCP:IPV4のacceptedハッシュ関数を改善する
    ・fuse:default_permissionsが無視されていたのを修正
    ・NET:dev_close()の競合を修正(Bug 9750)
    ほか、78パッチ

(以上、敬称略)

2/2

Index
Linux Kernel Watch 4月版
 遅れの原因はどこ? LatencyTOPで解析可能に
  Page 1
 2.6.25リリース、timerfdも有効に
 linux-nextの成果は?
 遅れの原因はどこ? LatencyTOPで解析可能に
Page 2
 フラッシュデバイス向け? UBIベースのファイルシステム登場
 いよいよ登場か、LVM3開発宣言
 1Gbytes単位のページでメモリ管理
 -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カーネルの開発体制などについて伺った

MONOist組み込み開発フォーラムの中から、Linux関連記事を紹介します


Linux & OSS フォーラム 新着記事
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

注目のテーマ

Linux & OSS 記事ランキング

本日 月間