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

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

• 「ZFS のディスク領域の計上」

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

• 「従来のボリューム管理」

• 「NFSv4 に基づく Solaris ACL モデル」

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 を使用してディスクへの変更をコミットしても、ディスク領域の使用状況の情報がすぐに更新されることが保証されているわけではありません。

UFS ファイルシステムでは、du コマンドが、ファイル内のデータブロックのサイズを報告します。ZFS ファイルシステムでは、du コマンドが、ディスクに格納されているときのファイルの実際のサイズを報告します。このサイズにはメタデータと圧縮データも含まれます。実際、この報告は「このファイルを削除した場合、どれだけの容量を得られるか」という質問に回答するときに役立ちます。したがって、圧縮がオフになっている場合でも、ZFS と UFS では異なる結果が表示されます。

df コマンドで報告される使用容量を zfs list コマンドの結果と比べる場合、df で報告される容量がファイルシステムそのもののサイズではなく、プールサイズであることを考慮してください。さらに df は、子孫のファイルシステムを認識せず、スナップショットが存在するかどうかも認識しません。圧縮や割り当て制限などの ZFS プロパティーがファイルシステムで設定されている場合は、df によって報告された使用容量を調整しようとしても困難になる可能性があります。

報告される使用容量に影響する可能性もある次の状況を考慮してください。

• recordsize より大きなファイルの場合、ファイルの最後のブロックは通常、約 1/2 になります。デフォルトの recordsize が 128K バイトに設定されている場合、ファイルあたり約 64K バイトが無駄になり、大きな影響になることがあります。RFE 6812608 の統合がこの状況を解決します。圧縮を有効にすることにより、これを回避できます。データがすでに圧縮されている場合でも、最後のブロックの未使用部分は 0 で埋められ、圧縮率が高くなります。

• RAIDZ-2 プールでは、すべてのブロックは、パリティー情報に少なくとも 2 つのセクター (512 バイトのチャンク) を使用します。 パリティー情報に使用される容量は報告されません。この容量は変動し、小さなブロックの場合は非常に大きな割合を占める可能性があるので、容量の報告への影響が見られる場合があります。この影響は recordsize を 512 バイトに設定したときに非常に極端になります。この場合、512 バイトの論理ブロックごとに 1.5K バイト (領域の 3 倍) が消費されます。格納されるデータには関係なく、領域効率に主な関心がある場合は、recordsize をデフォルト (128K バイト) のままにして、圧縮を有効にしてください (デフォルトの lzjb に設定)。

• df コマンドは、複製解除したファイルデータを認識しません。

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

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

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

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

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

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

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

従来のボリューム管理

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

NFSv4 に基づく Solaris ACL モデル

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

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

• このモデルは NFSv4 仕様に基づいており、NT 形式の ACL に似ています。

• このモデルは、より詳細なアクセス権を提供します。

• ACL は、setfacl や getfacl コマンドではなく、chmod および ls コマンドを使用して設定および表示します。

• ディレクトリのアクセス特権をどのようにサブディレクトリに適用するかを指定するために、より多くの継承セマンティクスを利用できます。

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