第 3 章 ZFS ファイルシステムと従来のファイルシステムの相違点

この章では、ZFS ファイルシステムと従来のファイルシステムの重要な相違点についていくつか説明します。これらの重要な相違点を理解していれば、従来のツールを使用して ZFS を操作するときの混乱を少なくすることができます。

この章は、次の節で構成されます。

ZFS ファイルシステムの構造

従来のファイルシステムでは、利用可能なデバイスは 1 つだけだったので、ファイルシステムのサイズがデバイスのサイズに制限されていました。サイズの制限があるために、従来のファイルシステムの作成および再作成には時間がかかり、場合によっては難しい作業になります。従来のボリューム管理製品は、この作業の管理を支援するためのものでした。

ZFS ファイルシステムは特定のデバイスに制限されないため、ディレクトリを作成する場合と同じようにすばやく簡単に作成できます。ZFS ファイルシステムは、ストレージプールに割り当てられた領域の範囲で自動的に拡張します。

1 つのファイルシステム (/export/home など) を作成して多数のユーザーサブディレクトリを管理する代わりに、ユーザーごとに 1 つのファイルシステムを作成できます。また、ZFS ファイルシステムの階層にプロパティーを適用すれば、階層に含まれるファイルシステムにそれらのプロパティーを継承させることができるので、ファイルシステムの数が多くても設定と管理を簡単に行うことができます。

ファイルシステム階層の作成例については、「ZFS ファイルシステム階層を作成する」を参照してください。

ZFS の領域の計上

ZFS は、プールストレージの概念に基づいて構成されます。標準的なファイルシステムでは物理ストレージにマッピングされますが、ZFS ファイルシステムはすべてがプールの中にあって、プール内で使用可能なストレージを共有しています。このため、df などのユーティリティーから報告される使用可能な領域は、ファイルシステムがアクティブでないときでも変化する可能性があります。これは、プール内のほかのファイルシステムが領域を消費したり解放したりするためです。ファイルシステムの最大サイズは、割り当て制限を使用して制限できます。割り当て制限の詳細については、「ZFS ファイルシステムに割り当て制限を設定する」を参照してください。ファイルシステムに割り当てられる領域は、予約を使用して保証することができます。予約については、「ZFS ファイルシステムに予約を設定する」を参照してください。このモデルは、NFS モデルによく似ています。つまり、複数のディレクトリが 1 つのファイルシステム (/home など) からマウントされます。

ZFS では、すべてのメタデータが動的に割り当てられます。ZFS 以外のほとんどのファイルシステムでは、多くのメタデータが事前に割り当てられます。つまり、ファイルシステムを作成するときには、これらのメタデータに直接割り当てる領域が必要になります。これは、ファイルシステムでサポートされる合計ファイル数も、事前に決定されていることを意味します。ZFS では必要に応じてメタデータが割り当てられるので、初期領域を割り当てる必要がなく、ファイル数も使用可能な領域に応じて制限されるだけです。df -g コマンドの出力は、ZFS と ZFS 以外のファイルシステムで解釈を変える必要があります。報告される total files は、プール内で使用できるストレージ容量に基づいて見積もった数値に過ぎません。

ZFS は、トランザクションファイルシステムです。ファイルシステムの変更のほとんどは、トランザクショングループに関連付けられ、ディスクに非同期にコミットされます。ディスクにコミットされる前の変更は、「保留状態の変更」と呼ばれます。ファイルまたはファイルシステムが使用する領域、使用できる領域、および参照する領域の総計に、保留状態の変更は考慮されません。保留状態の変更は通常、数秒以内に計上されます。fsync(3c) や O_SYNC を使用してディスクへの変更をコミットしても、領域の使用状況の情報がすぐに更新されることが保証されているわけではありません。

du コマンドおよび df コマンドによって報告される ZFS 領域の消費量については、次のリンクを参照してください。

http://opensolaris.org/os/community/zfs/faq/#whydusize

領域が不足した場合の動作

ZFS では、ファイルシステムのスナップショットを負荷をかけずに簡単に作成できます。スナップショットは、多くの ZFS 環境で使用されているようです。ZFS スナップショットについては、第 7 章ZFS のスナップショットとクローンの操作を参照してください。

スナップショットが存在していると、領域を解放しようとするときに、予期しない動作が発生することがあります。適切なアクセス権が付与されている場合には、通常はファイルシステム全体からファイルを削除することで、ファイルシステムで利用できる領域を増やすことができます。ただし、削除しようとするファイルがファイルシステムのスナップショットとして存在する場合には、そのファイルを削除しても領域は解放されません。このファイルの使用するブロックは、スナップショットから引き続き参照されます。

つまり、ファイルを削除しているのに、さらに多くのディスク領域が消費されることがあります。新しい状態の名前空間を反映するために、新しいディレクトリの作成が必要になるためです。このため、ファイルを削除しようとすると、予期しない ENOSPC または EDQUOT が返される可能性があります。

ZFS ファイルシステムをマウントする

ZFS は、複雑な管理を減らし管理が簡素化されるように、設計されています。たとえば、従来のファイルシステムでは、新しいファイルシステムを追加するたびに /etc/vfstab ファイルを編集する必要があります。ZFS では、データセットのプロパティーに基づいてファイルシステムのマウントとマウント解除を自動的に行うことで、この作業を不要にしました。/etc/vfstab ファイルの ZFS エントリを管理する必要はありません。

ZFS ファイルシステムのマウントおよび共有の詳細については、「ZFS ファイルシステムをマウントおよび共有する」を参照してください。

従来のボリューム管理

「プールされた ZFS ストレージ」で説明したように、ZFS ではボリュームマネージャーを個別に操作する必要はありません。ZFS は raw デバイス上で動作するため、論理ボリューム (ソフトウェアまたはハードウェア) で構成されるストレージプールを作成することもできます。ただし、この構成は推奨していません。ZFS は、raw 物理デバイスを使用するときに最適に動作するようになっているためです。論理ボリュームを使用すると、パフォーマンスまたは信頼性、あるいはその両方が損なわれることがあるため、使用するべきではありません。

新しい Solaris ACL モデル

以前のバージョンの Solaris OS では、主に POSIX ACL ドラフト仕様に基づく ACL 実装がサポートされていました。POSIX ドラフトベースの ACL は、UFS ファイルを保護するために使用されます。NFSv4 仕様に基づく新しい ACL モデルは、ZFS ファイルを保護するために使用されます。

新しい Solaris ACL モデルは、主に次の点が異なっています。

NFSv4 仕様に基づいており、NT 方式の ACL に似ています。
アクセス特権をより詳細に設定できます。
setfacl や getfacl コマンドではなく、chmod および ls コマンドを使用して設定および表示します。
ディレクトリのアクセス特権をどのようにサブディレクトリに適用するかを指定するために、より多くの継承セマンティクスを利用できます。

ZFS ファイルで ACL を使用するときの詳細については、第 8 章ACL による ZFS ファイルの保護を参照してください。