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

ファイルシステムの分野で革新を続ける Linux® は、オペレーティング・システムを問わずに多種多様なファイルシステムをサポートしているだけでなく、最先端のファイルシステム技術を提供しています。そんな Linux に新たに登場してきた 2 つのファイルシステムが、NiLFS(2) というログ構造化ファイルシステムと exofs というオブジェクト・ベースのストレージ・システムです。この記事では、この 2 つの新しいファイルシステムが目指しているもの、そしてそれぞれのファイルシステムがもたらす利点を説明します。

M. Tim Jones (mtj@mtjones.com), Independent author, Emulex Corp.

Author photoM. Tim Jones は組み込みソフトウェアのエンジニアであり、『Artificial Intelligence: A Systems Approach』、『GNU/Linux Application Programming』(現在、第 2 版です) や『AI Application Programming』(こちらも現在、第 2 版です)、それに『BSD Sockets Programming from a Multilanguage Perspective』などの著者でもあります。技術的な経歴は静止軌道衛星用のカーネル開発から、組み込みシステム・アーキテクチャーやネットワーク・プロトコル開発まで、広範にわたっています。また、コロラド州ロングモン所在のEmulex Corp. の顧問エンジニアでもあります。


developerWorks 貢献著者レベル

2009年 10月 31日

Tim とつながりを持つには

Tim は developerWorks で人気の高いお馴染みの著者の 1 人です。Tim が書いたすべての developerWorks の記事を閲覧してみてください。また、My developerWorks では、Tim のプロフィールを調べることや、彼やその他の著者、そして他の読者とのつながりを持つことができます。

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

ファイルシステムの背景

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

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

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

ログ構造化ファイルシステムは、NAND フラッシュで構成された半導体ディスク (SSD) に理想的なフォーマットです。フラッシュの根本的な問題は、書き込み回数と消去回数が限られていることですが、ログの書き込みはデバイス全体に対して行われます。そのため、デバイスへの書き込みが均等になり、消去回数が最小限になるというわけです。このことから、ログ構造化ファイルシステムは SSD (特にシーケンシャル書き込み) で際立ったパフォーマンスを発揮するとともに、ウェアレベリングの点でも優れています。

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

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

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

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

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

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

オブジェクト・ストレージ・デバイスと標準

オブジェクト・ストレージ・システムには、T-10 OSD (Object Storage Devices) 標準が適用されます。この仕様が詳述しているのは、オブジェクト・レベルの管理をサポートすることを目的とした標準 SCSI コマンド・セットの拡張機能です。この仕様ではオブジェクト・レベルでのアクセス・メソッドを定義している他、セキュリティーおよびメタデータの管理も扱っています。

オブジェクト・ストレージ・システムは、マルチテナント性とセキュリティーを組み入れた極めてスケーラブルなストレージを実現するための独特な方法です。標準としてのオブジェクト・ストレージ・デバイス (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) は変更が行われるごとにチェックポイントを作成しますが、ユーザーが任意の時点でチェックポイントを作成することもできます。

スナップショットを使用するファイルシステム

NiLFS(2) はスナップショット機能を組み込んだ数多くのファイルシステムのうちの 1 つです。スナップショットを使用する他のファイルシステムには、ZFS、LFS、Ext3cow などがあります。

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

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

NiLFS(2) の課題

NiLFS(2) のバージョンとカーネル

この NiLFS(2) のデモを行ったカーネルは、2.6.27 Linux カーネルです。2.6.30-rc1 カーネルにはメインラインに NiLFS(2) が組み込まれていますが、このデモでは NILFS ファイルシステム・モジュールおよびツールをソースからインストールしました。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 バックストアを下位レベルのベースとして従来のファイルシステムと同じものを実現することです。この手法で提示されるファイルシステムは従来のファイルシステムと同じであるため、オブジェクト・レベルのストレージにマイグレーションしやすくなるというわけです。

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

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

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

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

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

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

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

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

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


今後の展開

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

参考文献

学ぶために

製品や技術を入手するために

  • developerWorks から直接ダウンロードできる IBM 試用版ソフトウェアを使用して、Linux で次の開発プロジェクトを構築してください。

議論するために

  • My developerWorks コミュニティーに加わってください。自分個人のプロファイルとカスタム・ホーム・ページを作成して、自分の興味に合わせて developerWorks をカスタマイズしたり、他の developerWorks ユーザーと対話したりすることができます。

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


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