test

Oracle Solaris ZFS 管理ガイド

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

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

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

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

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

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

1 つのファイルシステム (/export/home など) を作成して多数のユーザーサブディレクトリを管理する代わりに、ユーザーごとに 1 つのファイルシステムを作成できます。階層内に含まれる子孫ファイルシステムに継承可能なプロパティーを適用することで、多数のファイルシステムの設定や管理を容易に行えます。

ファイルシステム階層の作成方法を示す例については、「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://hub.opensolaris.org/bin/view/Community+Group+zfs/faq/#whydusize

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

ZFS では、ファイルシステムのスナップショットを負荷をかけずに簡単に作成できます。スナップショットは、ほとんどの ZFS 環境でよく使用されます。ZFS スナップショットについては、第 7 章Oracle Solaris 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 仕様に基づく新しい Solaris ACL モデルは、ZFS ファイルを保護するために使用されます。

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

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