目次


次世代 Linux ファイルシステム: NiLFS(2) と exofs

Comments

新しい Linux ファイルシステムの発表には、何やら興奮と恐ろしさが入り混じったものを感じました。興奮を感じたのは、ファイルシステムは進化が注目される新しい領域を象徴するからです。恐ろしさを感じたのは、初期段階にあるファイルシステムは実験的な傾向があり、実用には至っていないことが多いからです。けれどもこの類の発表が、今後の Linux における投資を示唆していることがあります。実際、最近の 2.6.30-rc1 の発表は、非常に興味深い Linux の将来を示しています。この 1 年あまりの間、Linux は 3 つの主要なファイルシステムを発表しました。それは 2008年後半に導入された B-Tree File System (Btrfs)、そして最近紹介された 2 つの特異なファイルシステム、NiLFS(2) と exofs です。

ファイルシステムの背景

まず始めに、従来のファイルシステムとは異なる NiLFS(2) と exofs の手法について簡単に紹介し、それからこの 2 つのファイルシステムそれぞれの詳細について探っていくことにします。

ログ構造化ファイルシステム

現代のコンピューティング・システムにおいて、ログ構造化ファイルシステムには豊かな歴史があります。John Ousterhout と Fred Douglis によって最初のログ構造化ファイルシステムが提案されたのは 1988年のことでした。その後、1992年には Sprite オペレーティング・システムに実装されました。ログ構造化ファイルシステムはその名前が示すように、ファイルシステムを循環ログとして捉え、新しいデータとファイルシステムのメタデータをログの先頭に書き込み、ログの末尾の部分を再び空き領域として利用します (図 1 を参照)。つまり、ログ内に同じデータが何度か現れることがあっても、ログは時間に沿って順番に記録されていくため、最も新しいデータがアクティブ・データとしてみなされるということです。ログ内にデータの複数のコピーを保持するということには、興味深い利点があります。これらの利点については、これから詳しく説明します。

図 1. ログ構造化ファイルシステムの概要
ログ構造化ファイルシステムの概要
ログ構造化ファイルシステムの概要

ログ構造化方式という言葉は、単なるセールス・ポイントというよりは、ファイルシステムのアーキテクチャーの詳細な方式を表わすものですが、それでもやはりこの方式には明らかな利点がいくつかあります。1 つの決定的な利点は、システム・クラッシュからのリカバリーです。ログ構造化方式を用いることで、システム・クラッシュからのリカバリーが容易になります。

また、ストレージ・システムを利用してパフォーマンスを十分に引き出せるという利点もあります。ご存知のとおり、ランダム入出力よりもディスクにシーケンシャルに書き込むほうが、処理時間は遥かに短縮されます。すべての書き込みがシーケンシャルに行われるとなれば、シークの負荷が軽減され、それによってディスク入出力の高速化、さらにはファイルシステムの高速化という結果がもたらされます。

オブジェクト・ベースのストレージ・システム

従来のストレージ・システムは、ディスク・ドライブとその固有のインターフェースに依存してデータの永続的な保管を行います。これらのインターフェースが依存するのは、ブロック・ストレージというストレージ方式です。ブロック・ストレージでは、データは固定サイズの小さなブロックに分けられ、データのブロックがそのマッピング (ファイルシステムのメタデータ) とともに受け渡されます。オブジェクト・ストレージ・システムで用いている手法は、これとはかなり異なります。オブジェクト・ストレージ・システムが管理するのは固定サイズのブロックではなく、可変サイズのオブジェクトとそのオブジェクトに関連付けられたメタデータです (メタデータが、そのオブジェクトに関するシステム・レベルの情報を提供します)。

オブジェクト・ストレージ・システムは、マルチテナント性とセキュリティーを組み入れた極めてスケーラブルなストレージを実現するための独特な方法です。標準としてのオブジェクト・ストレージ・デバイス (OSD: Object Storage Devices)(囲み記事を参照) を作成する方法はさまざまにあり、例えばOSD 準拠のコンポーネント (OSD ドライブおよび OSD イニシエーター) を使うことも、それより上位レベルのコンポーネント (従来のドライブを下位レベルのベースとして使用して OSD の振る舞いを作成するターゲット・システム) を使うこともできます。しかし、ブロック・ベースのストレージ・システムとオブジェクト・ベースのストレージ・システムとの根本的な違いは、ブロック・ベースの場合にはブロックと通信するプロトコルを使用して、データとメタデータの両方が含まれるブロックのコレクションからオブジェクトを作成する一方、オブジェクト・ベースの場合は、オブジェクトやそのオブジェクトに関連付けられたメタデータと直接通信するという点です (図 2 を参照)。そのためオブジェクト・ストレージ・デバイスには、オブジェクトからなる複数の名前空間がフラットに構成されるようになり、その名前空間のなかでストレージ・システム・スタックに階層が (必要に応じて) 積み重ねられます。

図 2. ブロック・ベースとオブジェクト・ベースのストレージ・システムの違い
ブロック・ベースとオブジェクト・ベースのストレージ・システムの違い
ブロック・ベースとオブジェクト・ベースのストレージ・システムの違い

この記事では、オブジェクト・ベースのストレージ・システムを下位レベルのベースとして使用した 1 つのファイルシステムの実装について詳しく探ります。

ログ構造化ファイルシステムの新たな実装: NiLFS(2)

NiLFS(2) は、日本で日本電信電話株式会社 (NTT) によって開発されたログ構造化ファイルシステムの 2 番目のバージョンです。このファイルシステムの開発は非常に活発に進められており、NetBSD カーネルへの統合に加え、最近では Linux カーネルのメインラインにも統合されています。NILFS の最初のバージョンが登場したのは 2005年です。このバージョン 1 にはガーベッジ・コレクションの機能がまったく備わっていませんでしたが、2007年の中頃にリリースされたバージョン 2 には、ガーベッジ・コレクターとともに複数のスナップショットを作成および維持する機能が組み込まれました。今年 (2009年)、NiLFS(2) ファイルシステムがカーネルのメインラインに統合されたことから、ローダブル・モジュールをインストールするだけで、このファイルシステムを使用できるようになっています。

NiLFS(2) で興味深い点は、スナップショットを連続的に取得するという手法です。NILFS はログ構造化ファイルシステムであるため、新しいデータはログの先頭に書き込まれる一方、古いデータは (ガーベッジ・コレクションが必要になるまで) そのまま維持されます。古いデータがあるということは、過去に遡ってその時点でのファイルシステムの状態を調べられるということです。これらの過去の時点は、NiLFS(2) ではチェックポイントと呼ばれており、このファイルシステムには不可欠の部分となっています。NiLFS(2) は変更が行われるごとにチェックポイントを作成しますが、ユーザーが任意の時点でチェックポイントを作成することもできます。

この後記載するように、チェックポイント (リカバリー・ポイント) は表示できるだけでなく、スナップショットに変換することもできます。他のファイルシステムと同じく、Linux ファイルシステムの領域にもスナップショットをマウントできますが、マウントできるスナップショットは現在、読み取り専用に限られます。スナップショットをマウントすると、前に削除したファイルを復旧したり、ファイルの以前のバージョンをチェックしたりできるため、非常に便利です。

連続スナップショットに加え、NiLFS(2) には他にも数々の利点があります。可用性の観点から最も重要な利点は、その再起動の速さです。現行のチェックポイントが無効だったとしても、ファイルシステムは有効なファイルシステムとして使用できる最後のチェックポイントに戻ればよいだけなので、fsck プロセスに勝ることは確実です。

NiLFS(2) の課題

連続スナップショットは素晴らしい機能ですが、これにはコストが伴います。このファイルシステムの利点は前述のとおり、ログ構造化方式であることです。つまり基本的に書き込みはシーケンシャルに行われ、それによって物理ディスクのシーク動作が最小限となるため、非常に高速に動作します。欠点は、同じくログ構造化ファイルシステムであることに起因します。それは、古いデータとメタデータをクリーンアップするためにガーベッジ・コレクションが必要になることです。通常の状態では、このファイルシステムは非常に高速に動作しますが、ガーベッジ・コレクションが必要になると、動作が遅くなります。

NiLFS(2) を詳しく探る

ここからは、実際の NiLFS(2) の動作を見ていきます。このデモでは、ループ・デバイス (ファイルシステムをテストするための単純な方法) で NiLFS(2) ファイルシステムを作成する方法を説明してから、NiLFS(2) の機能をいくつか取り上げて詳しく見ていきます。まずは、以下のコードで NiLFS(2) カーネル・モジュールをインストールすることから始めます。

$ sudo modprobe nilfs2
$

次に、ファイルシステムを含めるファイル (ホスト・オペレーティング・システム上で、ループ・デバイスによって単独のファイルシステムとしてマウントする領域) を作成し、このファイルのなかに、mkfs を使って NiLFS(2) ファイルシステムを作成します (リスト 1 を参照)。

リスト 1. NiLFS(2) ファイルシステムを作成する
$ dd if=/dev/zero of=/tmp/disk.img bs=384M count=1
1+0 records in
1+0 records out
402653184 bytes (403 MB) copied, 60.7253 s, 6.6 MB/s
$ mkfs.nilfs2 /tmp/disk.img
mkfs.nilfs2 ver 2.0
Start writing file system initial data to the device
       Blocksize:4096  Device:/tmp/disk.img  Device Size:402653184
File system initialization succeeded !!
$

これで、ディスク・イメージが NiLFS(2) ファイルシステム・フォーマットで初期化されました。今度はループ・デバイスを使ってファイルシステムをマウント・ポイントにマウントします (リスト 2 を参照)。ファイルシステムをマウントすると、ガーベッジ・コレクション・サービスを提供する nilfs_cleanerd というユーザー空間プログラムも起動されることに注意してください。

リスト 2. ループ・デバイスを使用して NiLFS(2) をマウントする
$ sudo losetup /dev/loop0 /tmp/disk.img
$ sudo mkdir /mnt/nilfs
$ sudo mount -t nilfs2 /dev/loop0 /mnt/nilfs/
mount.nilfs2: WARNING! - The NILFS on-disk format may change at any time.
mount.nilfs2: WARNING! - Do not place critical data on a NILFS filesystem.
$ ls /mnt/nilfs
$

続いてファイルシステムにいくつかのファイルを追加し、それから lscp コマンドを使用して現在使用できるチェックポイントを一覧表示します (リスト 3 を参照)。mkcp コマンドを使用してスナップショットを定義した後、もう一度チェックポイントを確認してください。2 番目の lscp では、新しく作成されたスナップショットを確認できるはずです (すべてのチェックポイントおよびスナップショットには CNO、つまりチェックポイント番号が付けられています)。

リスト 3. チェックポイントを一覧表示した後、スナップショットを作成する
$ cd /mnt/nilfs
$ sudo touch file1.txt file2.txt
$ lscp
                 CNO        DATE     TIME  MODE  FLG   NBLKINC       ICNT
                   1  2009-08-21 22:29:31   cp    -         11          3
                   2  2009-08-21 22:36:44   cp    -         11          5
$ sudo mkcp -s
$ lscp
                 CNO        DATE     TIME  MODE  FLG   NBLKINC       ICNT
                   1  2009-08-21 22:29:31   cp    -         11          3
                   2  2009-08-21 22:36:44   ss    -         11          5
                   3  2009-08-21 22:39:47   cp    i          7          5
$

スナップショットが用意できたところで、もう一度 touch コマンドを使って、現行のファイルシステムにさらにファイルを追加します (リスト 4 を参照)。

リスト 4. NiLFS(2) ファイルシステムにさらにファイルを追加する
$ sudo touch file3.txt file4.txt
$ ls
file1.txt  file2.txt  file3.txt  file4.txt
$

ここで、スナップショットを読み取り専用ファイルシステムとしてマウントします。それには前のマウントと同様の方法を使いますが、今回はマウントするスナップショットを指定しなければなりません。スナップショットを指定するために使用するのは、cp オプションです。前の lscp では、スナップショットの CNO2 でした。mount コマンドにこの CNO を指定して、読み取り専用ファイルシステムをマウントします。マウントした後、最初の ls でマウント済みの読み取り/書き込みファイルシステムを一覧表示すると、すべてのファイルが表示されます。読み取り専用のスナップショットでは、スナップショットの作成時に存在していた 2 つのファイルだけが表示されます (リスト 5 を参照)。

リスト 5. 読み取り専用 NiLFS(2) スナップショットをマウントする
$ sudo mkdir /mnt/nilfs-ss2
$ sudo mount.nilfs2 -r /dev/loop0 /mnt/nilfs-ss2/ -o cp=2
$ ls /mnt/nilfs
file1.txt  file2.txt  file3.txt  file4.txt
$ ls /mnt/nilfs-ss2/
file1.txt  file2.txt
$

チェックポイントから変換されたスナップショットはそのままずっと維持されることに注意してください。スペースが必要になった場合、チェックポイントはファイルシステムから回収できますが、スナップショットは永続的に残されます。

このデモでは、NiLFS(2) のコマンドライン・ユーティリティーのうち、lscp (チェックポイントおよびスナップショットを一覧表示) とmkcp (チェックポイントまたはスナップショットを作成) の 2 つを使用しました。この他のユーティリティーには、チェックポイントをスナップショットに、またはその逆に変換する chcp や、チェックポイントまたはスナップショットを無効にする rmcp もあります。

このファイルシステムには時間的な要素を組み入れられる性質があるため、NTT ではこの他にも、例えば tls (時間要素を含んだ ls)、tdiff (時間要素を含んだ diff)、tgrep (時間要素を含んだ grep) などの非常に革新的なツールを検討しています。このような時間をベースとした機能を導入することが、当然、このファイルシステムで踏むべき次のステップとなると思います。

exofs (Extended Object File System)

exofs (Extended Object File System) は、オブジェクト・ストレージ・システムを下位レベルのベースとして使用して作成された従来型の Linux ファイルシステムです。exofs は IBM の Avnishay Traeger によって開発された当時、OSD ファイルシステム (osdfs) と呼ばれていました。その後、このプロジェクトを引き継いだ Panasas (オブジェクト・ストレージ・システムを作成している企業) が、このファイルシステムの起源である ext2 ファイルシステムにちなんで、現在の exofs という名前に変更しました。

オブジェクト・ストレージ・システムを下位レベルのベースとして使用したファイルシステム

概念的には、オブジェクト・ストレージ・システムはオブジェクトとその関連メタデータのフラットな名前空間としてみなすことができます。このオブジェクト・ストレージ・システムを、ブロックをベースとした従来のストレージ・システムと比較してみてください。この従来のストレージ・システムではセマンティックな結び付きを提供するために一部のブロックをメタデータが占めています。システムの概略図では exofs は図 3 に示すように位置付けられます。VFS (Virtual File System Switch) が exofs へのパスを提供し、exofs はローカル OSD イニシエーターを介してオブジェクト・ストレージ・システムと通信します。OSD イニシエーターは、OSD T-10 標準 SCSI コマンド・セットを実装します。

図 3. exofs/OSD エコシステムの概略図
exofs/OSD エコシステムの概略図
exofs/OSD エコシステムの概略図

exofs の背後にある概念は、OSD バックストアを下位レベルのベースとして従来のファイルシステムと同じものを実現することです。この手法で提示されるファイルシステムは従来のファイルシステムと同じであるため、オブジェクト・レベルのストレージにマイグレーションしやすくなるというわけです。

ファイルシステムのマッピング

OSD 内の各オブジェクトは、フラットな名前空間のなかでは 64 ビットの ID によって表されます。そのため標準 POSIX インターフェースをオブジェクト・ストレージ・システムに重ね合わせるには、マッピングが必要です。exofs が提供するマッピングは、単純であるだけでなく、スケーラブルであり、拡張することもできます。

ファイルシステム内のファイルは、i ノードとして一意に表現されます。exofs は i ノードをオブジェクト・システム内でオブジェクト ID (OID) にマッピングします。そこからは、オブジェクトがファイルシステムのすべての要素を表現するために使用されます。ファイルはオブジェクトに直接マッピングされます。そしてディレクトリーは、 (ファイル名および i ノードと OID のペアとして) そのディレクトリーに含まれるファイルを参照するファイルでしかありません。この仕組みを図 4 の単純な形式で示します。この図に示されているオブジェクトの他にも、i ノードのビットマップ (i ノード割り当て用) などをサポートするためのオブジェクトがあります。

図 4. OSD 表現の概略図
OSD 表現の概略図
OSD 表現の概略図

オブジェクト・スペース内のオブジェクトを表すために使用される OID のサイズは 64 ビットです。これによって、大きなスペースのオブジェクトをサポートしています。

オブジェクト・ストレージが必要な理由とは

オブジェクト・ストレージは興味深い概念で、極めてスケーラブルなシステムを可能にします。それは、ファイルシステムを部分的にホストから取り除き、その取り除いた部分をストレージ・サブシステムに組み込むからです。そこにはトレードオフもありますが、ファイルシステムの構成部分を複数のエンドポイントに分散することで作業負荷を分散し、オブジェクト・ベースの方式を簡易化することでストレージ・システムの規模を大幅に拡大します。そしてホスト・オペレーティング・システムにブロックとファイルのマッピングを考慮させることなく、ストレージ・デバイス自体がこのマッピングを提供し、ホストがファイル・レベルで操作できるようにします。

オブジェクト・ストレージ・システムは、使用可能なメタデータを照会できる機能も提供します。これにより、検索機能をエンドポイントのオブジェクト・システムに分散できるという利点も加わります。

オブジェクト・ストレージは、最近クラウド・ストレージの分野で勢いを取り戻しています。クラウド・ストレージ・プロバイダー (ストレージをサービスとして販売するプロバイダー) は、そのストレージを従来のブロック API ではなくオブジェクトとして表現し、オブジェクトの転送、管理、そしてメタデータの管理を行うための API を提供しています。

今後の展開

Linux ファイルシステムのインベントリーに追加されることになる、興味深く有益なファイルシステムは NiLFS(2) と exofs だけではありません。最近紹介された (Oracl の) Btrfs は、Sun Microsystems ZFS (Zettabyte File System) の Linux バージョンです。また、最近のファイルシステムには Ceph もあります。Ceph は単一障害点が 1 つもない信頼性の高い POSIX ベースの分散ファイルシステムです。今や、新しいログ構造化ファイルシステムが登場し、オブジェクト・ストアを下位レベルのベースとしたファイルシステムも導入されようとしています。Linux は今後も、選り抜きのリサーチ・プラットフォームであるとともに、エンタープライズ級のオペレーティング・システムであることを証明し続けるはずです。


ダウンロード可能なリソース


関連トピック

  • NiLFS(2) ファイルシステム・プロジェクトの Web サイトにアクセスして、最新情報を入手してください。このサイトには、FAQ、リンク、そしてチェックポイントとスナップショットをはじめとするファイルシステムのサンプル・デモが用意されています。
  • 当初 IBM によって開発された exofs は、現在 Panasas で開発が進められています。詳細については、open-osd.org の Exofs プロジェクト Web サイトにアクセスしてください。
  • Btrfs についての詳細は、ウィキペディアの Btrfs および「進歩する Linux カーネル」(developerWorks、2009年3月) を読んでください。
  • The Design and Implementation of a Log-Structured File System」(PDF) を読んでください。Sprite LFS の著者らによるこの影響力の大きな論文では、歴史的観点からわかりやすくログ構造化ファイルシステムを捉え、ログ構造化ファイルシステムの背後にある概念とその課題を説明しています。
  • ログ構造化ファイルシステムオブジェクト・ストレージ・デバイスについて、ウィキペディアの紹介記事を読んでください。記事では、これらの技術の現状と併せ、歴史的観点を説明しています。
  • NILFS の Web サイトで、NiLFS(2) およびユーザー・スペースのツールを 2.6.30 以前のカーネルにインストール方法を調べてください。ここには、各種 Linux ディストリビューションについての説明も記載されています。
  • Linux カーネル・ツリーの Documentation/filesystems サブディレクトリーに、NiLFS(2) および exofs に関する情報が記載されています。ここでは特定のカーネル・バージョンについて詳しい情報を入手できます。
  • Samsung Electronics によるプレゼンテーション「About SSD」(PDF) では、NILFS をはじめとするさまざまなファイルシステムを対象に、SSD ドライブを使用した SSD のパフォーマンスについて興味深い検討を行っています。また、Phoronix による最近のファイルシステム・パフォーマンス分析でも、EXT4、Btrfs、EXT3、XFS、および NiLFS(2) を比較しています。
  • Seagate によるホワイト・ペーパー「The Advantages of Object-Based Storage—Secure, Scalable, Dynamic Storage Devices」では、オブジェクト・ストレージ・デバイスについてわかりやすく紹介しています。オブジェクト・ストレージについて詳しく学ぶには、SNIA (Storage Networking Industry Association) による 2 つのプレゼンテーション「Object Storage and Applications」(PDF) と「OSD Architecture and Systems」(PDF) も参考になります。
  • Seagate では、OSD コマンド・セットを実装する光ファイバー・チャネル・ドライブのプロトタイプを開発しました。このドライブのオブジェクト・ストレージ・システムに関するデモには、IBM および Emulex が参加しています。IBM がメタデータ・サーバーを提供し、Seagate が OSD 対応ドライブ、そして Emulex がOSD をサポートする FC ホスト・バス・アダプターを提供しました。
  • developerWorks Linux ゾーンに豊富に揃った Linux 開発者向けの資料を調べてください。記事とチュートリアルの人気ランキングも要チェックです。
  • developerWorks に掲載されているすべての「Linux のヒント」シリーズの記事と Linux チュートリアルを参照してください。
  • developerWorks から直接ダウンロードできる IBM 試用版ソフトウェアを使用して、Linux で次の開発プロジェクトを構築してください。

コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Linux
ArticleID=449841
ArticleTitle=次世代 Linux ファイルシステム: NiLFS(2) と exofs
publish-date=10312009