Solaris ZFSの基本的な仕組みを知る：Solaris ZFS集中講座（1）（1/3 ページ）

　本連載では、Solaris ZFS (以下 ZFS) の基本的なコンセプトやアーキテクチャから、その機能や実用・応用例を解説するという流れでZFSをご紹介させていただきます。

　今回は、ZFSの基本的コンセプトとアーキテクチャの解説です。

Zの文字に込められた意味

　ソースコードの複雑化と、扱うデータ量の増大に伴い、既存のファイルシステムでは管理性、拡張性、安全性、完全性、機能、性能が問題となることが多くなってきました。このような中、サン・マイクロシステムズ（以下、サン）のエンジニアチームは、まったく新しい、まるでコンピュータのメインメモリのように扱えるファイルシステムの開発を始めました。

　目的は、既存のファイルシステムが抱える問題点をすべて解決し、管理が容易で、拡張性があり、安全でかつ完全性が保持され、便利な機能を持ち、高性能な、ある意味、究極のファイルシステムを作ることでした。

　ZFSの「Z」の文字は、アルファベットの最後の一文字で、「最後の」や「究極の」といった意味も持つことから、このファイルシステムは「ZFS」と名付けられました。

　開発の途中で、OpenSolarisプロジェクトに伴ってZFSもソースコードが公開され、コミュニティからのフィードバックを受けながら実装が進められました。

　Solaris 10 6/06でZFSは製品としてリリースされました。ZFSは現在、Solaris以外のUNIXや他のオープンソースプロジェクトへの移植も進みつつあるほどにまで、評価が高まっています。

ZFSの特長とアーキテクチャ

1. 拡張性

　ZFSはアドレッシングを128ビットで行います。すなわち、既存の64ビットファイルシステムの 2の64乗(≒ 16 x 10の18乗) 倍のデータを扱えることになります。ZFSのZは「Zetta-bytes(10 億テラバイト) のZ」といういわれ方をしていますが、実際には1000兆Zetta-bytes まで表現可能で、もはや想像さえできないほどの容量といえます。

　ZFSの具体的な各種制限値は以下のようになっています。

　ZFSでは物理ストレージを「ストレージプール」(以下プール) として管理します。普段はこのプールにストレージ容量を格納しておき、必要なときにその容量を使用します。

図1　ストレージプール

　プールにはRAIDレベルを設定します。従ってプールは、あるRAID特性（物理ストレージのレイアウトに基づく性能や冗長性）を持ったディスク容量のまとまりだと考えるとわかりやすいと思います。

　ZFSでは、「ファイルシステム」をプールから切り出します。個々のファイルシステムでは容量を設定する必要はなく (後述の「属性値」によって設定することも可能)、同じプールに属するファイルシステム全体で、そのプールの容量を共有します。すなわち、特に容量を指定しない限りは、ファイルシステムサイズの上限は、プールサイズとなります。

　ファイルシステムに格納するデータの量が増えても、プールから容量が自動で割り当てられます。これは、物理メモリをシステムに足しておけば、OS がそれを認識して、必要とするプロセスにメモリを割り当てられる仕組みと似ています。

　また、従来のRAIDボリュームとファイルシステムを合わせたものがプール、従来のディレクトリがZFSのファイルシステムと考えてもよいかもしれません。

　プールの容量が足りない場合は、システムから認識できる物理ストレージを追加し、プールに追加するだけで、プールに属するファイルシステムすべてがそのストレージの容量を使用できます。ある程度の容量でスモールスタートし、必要に応じて後から容量を追加するアプローチが簡単に行えます。

　ファイルシステム管理のメタデータは動的に割り当てられ、プールやファイルシステムの作成時に指定をする必要はありません。UFSであったような、格納可能iノード数がファイルシステム構築時点で決定されてしまうようなこともありません。