UFS ファイルシステム

UFS ファイルシステムの詳細は、次の節を参照してください。

「UFS ファイルシステムの機能」
「UFS ファイルシステムの計画」
「マルチテラバイトの UFS ファイルシステムのサポート」
「UFS ロギング」
「UFS スナップショット」
「UFS 直接入出力」

UFS ファイルシステムの機能

UFS は、Solaris オペレーティングシステム内のデフォルトのディスクベースファイルシステムです。ほとんどの場合、ディスクベースのファイルシステムを管理するときには、UFS ファイルシステムを管理していることになります。UFS が提供する機能は次のとおりです。

UFS の機能	説明
拡張基礎タイプ (EFT)	32 ビットのユーザーID (UID)、グループID (GID)、およびデバイス番号を提供します。
大規模ファイルシステム	最大 16T バイトまで増やせるファイルシステムに、およそ 1T バイトの大きさのファイルを指定できます。EFI ディスクラベルを使ってディスク上にマルチテラバイトの UFS ファイルシステムを作成できます。
ログ	UFS ロギングは、完全な UFS 操作による複数のメタデータ変更を、1 つのトランザクションにまとめます。一連のトランザクションは、ディスク上のログに記録されたあと、実際の UFS ファイルシステムのメタデータに適用されます。
マルチテラバイトファイルシステム	マルチテラバイトファイルシステムでは、およそ 16T バイトの最大使用可能空間からおよそ 1 パーセントのオーバーヘッドを引いたサイズの UFS ファイルシステムを作成できます。
状態フラグ	ファイルシステムの状態を、クリーン、安定、使用中、ロギング処理、または不明として表示します。これらのフラグによって、不要なファイルシステム検査を行うことがなくなります。ファイルシステムが「クリーン」状態、「安定」状態、または「ロギング処理」状態になっていると、ファイルシステムの検査は実行されません。

UFS ファイルシステム構造の詳細は、第 21 章UFS ファイルシステム (参照情報)を参照してください。

UFS ファイルシステムの計画

ファイルシステムの配置を決めるときには、要求が競合する可能性があることを考えなければなりません。次にいくつかの推奨事項を示します。

作業負荷を異なる入出力システムやディスクドライブ間でできるだけ均等に分散します。/export/home ファイルシステムやスワップ空間を異なるディスク間で均等に分散させます。
プロジェクトの個々の部分やグループのメンバーを同じファイルシステム内に入れます。
1 ディスク当たりのファイルシステム数をできるだけ少なくします。通常、システム (またはブート) ディスク上には、ルート (/)、/usr、スワップ空間の 3 つのファイルシステムがあります。その他のディスク上で、1 つまたは多くても 2 つのファイルシステムを作成し、追加のスワップ空間になるファイルシステムを 1 つ持たせます。多数の小規模なファイルシステムに分割しすぎるよりもファイルシステム数を少なくして余地を設ける方が、ファイルがフラグメントに分割される可能性が小さくなります。容量の大きいテープドライブを使用し、ufsdump コマンドで複数のボリュームを処理できるようにしておけば、大規模なファイルシステムでも簡単にバックアップをとることができます。
きわめて小さいファイルを絶えず作成するユーザーがいる場合は、i ノード数を増やして別のファイルシステムを作成することを検討します。ただし、ほとんどのサイトでは、類似するタイプのユーザーファイルを同じファイルシステム内で保管する必要はありません。

デフォルトのファイルシステムパラメータの情報と、新しい UFS ファイルシステムの作成手順については、第 17 章ファイルシステムの作成およびマウント (手順)を参照してください。

マルチテラバイトの UFS ファイルシステムのサポート

この Solaris リリースでは、マルチテラバイトの UFS ファイルシステムがサポートされます。

これまで、UFS ファイルシステムは約 1 テラバイトに制限されていました。今回、マルチテラバイト UFS ファイルシステムをサポートするため、すべての UFS ファイルシステムコマンドとユーティリティーが更新されました。

たとえば、ufsdump コマンドは大規模な UFS ファイルシステムをダンプできるようにブロックサイズが大きくなりました。

# ufsdump 0f /dev/md/rdsk/d97 /dev/md/rdsk/d98
    DUMP: Date of this level 0 dump: Mon Jul 12 10:51:10 2010
    DUMP: Date of last level 0 dump: the epoch
    DUMP: Dumping /dev/md/rdsk/d97 to /dev/md/rdsk/d98
    DUMP: Mapping (Pass I) [regular files]
    DUMP: Mapping (Pass II) [directories]
    DUMP: Writing 32 Kilobyte records
    DUMP: Estimated 17439410 blocks (8515.34MB).
    DUMP: Dumping (Pass III) [directories]
    DUMP: Dumping (Pass IV) [regular files]

1T バイト未満の UFS ファイルシステムは、以前と同じように管理されます。1T バイト未満の UFS ファイルシステムと 1T バイトを超えるファイルシステムとの間に管理面での違いはありません。

最初に newfs -T オプションを使用していれば、1T バイト未満の UFS ファイルシステムを作成し、最終的にマルチテラバイトのファイルシステムに拡張されるように指定できます。このオプションを使用すると、マルチテラバイトのファイルシステムに適した値に拡張が可能であるように i ノードとフラグメントの密度が設定されます。

1T バイト未満の UFS ファイルシステムを作成するときに、newfs -T オプションを使用すると、最終的にこのシステムを起動するときに、growfs コマンドを使ってこのファイルシステムを拡張できます。詳細は、newfs(1M) のマニュアルページを参照してください。

fstyp -v コマンドを使用し、magic 列で次の値を確認することにより、UFS ファイルシステムがマルチテラバイトをサポートしているかどうかを識別できます。

# /usr/sbin/fstyp -v /dev/md/rdsk/d3 | head -5
ufs
magic   decade  format  dynamic time    Mon Jul 12 11:12:36 2010

マルチテラバイトをサポートしてない UFS ファイルシステムでは、次の fstyp の出力が表示されます。

# /usr/sbin/fstyp -v /dev/md/rdsk/d0 | head -5
ufs
magic   11954   format  dynamic time    Mon Jul 12 12:41:29 2010

growfs コマンドを使用すると、サービスやデータを失わずに、UFS ファイルシステムをスライスまたはボリュームのサイズまで拡張できます。詳細については、growfs(1M) のマニュアルページを参照してください。

これに関連して、EFI ディスクラベルによるマルチテラバイトボリュームのサポートと、Solaris ボリュームマネージャーによるマルチテラバイトボリュームのサポートという新しい 2 つの機能が追加されました。詳細は、「EFI ディスクラベル」および『Solaris ボリュームマネージャの管理』を参照してください。

マルチテラバイトの UFS ファイルシステムの機能

マルチテラバイトの UFS ファイルシステムには、次の機能があります。

最大 16T バイトの UFS ファイルシステムを作成できます。
16T バイト未満のファイルシステムを作成し、あとで 16T バイトまでサイズを増やすことができます。
マルチテラバイトのファイルシステムを物理ディスク、Solaris ボリュームマネージャーの論理ボリューム、および Veritas の VxVM 論理ボリューム上に作成できます。
マルチテラバイトのファイルシステムでは、UFS ロギングが有効になっているとパフォーマンスが向上するという利点があります。また、マルチテラバイトのファイルシステムは、ロギングが有効なときは fsck コマンドを実行しなくてもよい場合があるというロギングの利点を利用することもできます。
マルチテラバイトの UFS ファイルシステム用のパーティションを作成すると、そのディスクには自動的に EFI ディスクラベルが付きます。EFI ディスクラベルの詳細は、「EFI ディスクラベル」を参照してください。
マルチテラバイトファイルシステムのスナップショットを作成できます (ファイルシステムのサイズが 512G バイトを超える場合、複数のバッキングストアファイルが作成される)。

マルチテラバイトの UFS ファイルシステムの制限事項

マルチテラバイトの UFS ファイルシステムには、次の制限事項があります。

32 ビットシステムではサポートされません。
32 ビットの Solaris カーネルを実行しているシステムでは、1T バイトを超えるファイルシステムをマウントすることはできません。
1T バイトを超える個々のファイルはサポートされていません。
UFS ファイルシステムの 1T バイトあたりの最大ファイル数は 100 万です。たとえば、4T バイトのファイルシステムには、400 万個のファイルを含めることができます。

100 万に制限されているのは、fsck コマンドでファイルシステムを検査するのに要する時間を減らすためです。
マルチテラバイトの UFS ファイルシステムに設定できる最大割り当て数は、2T バイトの 1024 バイトブロックです。

マルチテラバイトの UFS 作業についての参照先

マルチテラバイトの UFS ファイルシステムの操作手順については、次を参照してください。

マルチテラバイトの UFS 作業	参照先
マルチテラバイトの UFS ファイルシステムを作成します	「マルチテラバイトの UFS ファイルシステムを作成する方法」「マルチテラバイトの UFS ファイルシステムを拡張する方法」「UFS ファイルシステムをマルチテラバイトの UFS ファイルシステムに拡張する方法」
マルチテラバイトの UFS スナップショットを作成します	例 24-2
マルチテラバイトの UFS に関する問題の障害追跡を行います	「マルチテラバイトの UFS ファイルシステムに関する問題の障害追跡」

UFS ロギング

UFS ロギングは、1 つの完全な UFS 操作を構成する複数のメタデータ変更を、1 つのトランザクションにまとめます。ディスク上の単一のログファイルに、複数のトランザクションが記録されます。これらのトランザクションは、その後、実際の UFS ファイルシステムのメタデータに適用されます。

システムはリブート時に、不完全なトランザクションを廃棄しますが、完結している操作のトランザクションは適用します。完結しているトランザクションだけが適用されるために、ファイルシステムの整合性が保たれます。この整合性は、システムがクラッシュした場合も保持されます。システムのクラッシュは、システムコールを中断し、UFS ファイルシステムの不整合の原因となる可能性があります。

UFS ロギングには 2 つの長所があります。

トランザクションログによりファイルシステムの整合性がすでに保持されている場合、システムがクラッシュしたとき、またはクリーンでないシステム停止が発生したときに、fsck コマンドを実行する必要がないことがあります。クリーンでないシステム停止については、「fsck コマンドで検査して修復される内容」を参照してください。
UFS ロギングのパフォーマンスは、非ロギングファイルシステムのパフォーマンスレベルを上回るようになりました。ロギングが有効なファイルシステムでは、同じデータに対する複数の更新が 1 回の更新に変換されるため、これがパフォーマンスの向上につながっています。したがって、オーバーヘッドディスクの操作回数を減らす必要があります。

ロギングは、次の場合を除き、すべての UFS ファイルシステムでデフォルトで有効になります。

ロギングが明示的に無効とされた場合。
ログ用のファイルシステム容量が不足している場合。

以前の Solaris リリースでは、UFS ロギングは手動で有効にする必要がありました。

UFS ロギングを使用する際には、次の点に注意してください。

ユーザー、アプリケーション、UFS ロギングなどの一般的なシステム要求に対応できるだけのディスク容量が確保されているかどうかを確認してください。

ディスク容量が不足していてデータをロギングできない場合は、次のようなメッセージが表示されます。

# mount /dev/dsk/c0t4d0s0 /mnt
/mnt: No space left on device
Could not enable logging for /mnt on /dev/dsk/c0t4d0s0.
#

ただし、その場合でも、ファイルシステムはマウントされます。次に例を示します。

# df -h /mnt
Filesystem             size   used  avail capacity  Mounted on
/dev/dsk/c0t4d0s0      142M   142M     0K   100%    /mnt
#

ロギングが有効にされた UFS ファイルシステムでは、ほとんど空の状態であっても、いくらかのディスク容量がログ用として消費されます。
以前の Solaris リリースからこの Solaris リリースにアップグレードする場合、/etc/vfstab ファイル内で logging オプションが指定されていなかった場合でも、UFS ファイルシステムのロギングは有効になります。ロギングを無効にするには、/etc/vfstab ファイル内の UFS ファイルシステムのエントリに、nologging オプションを追加します。

UFS トランザクションログには、次の特徴があります。

ファイルシステム上の空きブロックから割り当てられる。
1G バイトのファイルシステム領域ごとに約 1M バイトのサイズ (合計で 256M バイトまで) になる。ファイルシステムに大量のシリンダグループが存在する場合、ログのサイズはこれより大きくなることがあります (最大で 512M バイトまで)。
これ以上書き込めない状態になるとフラッシュされる。
ファイルシステムがマウント解除されたときや、lockfs コマンドを実行したときにもフラッシュされる。

UFS ロギングを有効にする必要がある場合は、-/etc/vfstab ファイル内で mount コマンドに o logging オプションを指定するか、ファイルシステムを手動でマウントするときに mount コマンドに o logging オプションを指定します。ログは、ルート (/) ファイルシステムを含む、任意の UFS ファイルシステムで有効にできます。また、fsdb コマンドには、UFS ロギングをサポートするための新しいデバッグコマンドが用意されています。

一部のオペレーティングシステムでは、ロギングが有効になっているファイルシステムを「ジャーナル」ファイルシステムと呼びます。

UFS スナップショット

fssnap コマンドを使用して、ファイルシステムの読み取り専用のスナップショットを作成できます。「スナップショット」は、バックアップ操作のためのファイルシステムの一時イメージです。

詳細は、第 24 章UFS スナップショットの使用 (手順)を参照してください。

UFS 直接入出力

直接入出力の目的は、大容量入出力処理のスピードを速くすることです。大容量入出力処理では、大規模ファイル (256K バイトを超える) を転送するために、大容量のバッファーサイズを使用します。

UFS の直接入出力を使用すると、データベースエンジンなど、独自の内部バッファリングを行うアプリケーションにメリットがあります。UFS 直接入出力を使用すると、raw デバイスがアクセスされたときに起こる同様の入出力の並行処理が可能になります。現在では、パフォーマンスがわずかに低下するだけで、ファイルシステムのネーミングや柔軟性がもたらすメリットを受けることができます。データベースの製造元を調べて、その製品構成オプションで UFS の直接入出力を有効にできるかどうかを確認してください。

mount コマンドに forcedirectio オプションを使用しても、直接入出力をファイルシステムで有効にできます。直接入出力を有効にしてパフォーマンスが向上するのは、ファイルシステムが大量の連続するデータを転送するときだけです。

forcedirectio オプションでファイルシステムをマウントするとき、データはユーザーのアドレス空間とディスクの間で直接伝送されます。直接入出力がファイルシステムで無効な場合、ユーザーのアドレス空間とディスクの間で転送されるデータは、まず、カーネルアドレス空間にバッファーされます。

デフォルトでは、UFS ファイルシステムでは直接入出力は行われません。詳細については、mount_ufs(1M) のマニュアルページを参照してください。

ナビゲーションリンクをスキップ
印刷ビューの終了
	Solaris のシステム管理 (デバイスとファイルシステム) Oracle Solaris 10 8/11 Information Library (日本語)