第15章 ファイルシステムの管理 (概要)

ファイルシステムの管理は、もっとも重要なシステム管理作業の 1 つです。

この章の内容は次のとおりです。

• 「Solaris 9 Update リリースの新しいファイルシステム機能」

• 「ファイルシステム管理作業についての参照先」

• 「ファイルシステムの概要」

• 「ファイルシステムのタイプ」

• 「ファイルシステム管理用のコマンド」

• 「デフォルトの Solaris ファイルシステム」

• 「スワップ空間」

• 「UFS ファイルシステム」

• 「ファイルシステムのマウントとマウント解除」

• 「ファイルシステムのタイプを調べる」

Solaris 9 Update リリースの新しいファイルシステム機能

この節では、この Solaris リリースの新しいファイルシステム機能について説明します。

デフォルトで有効な UFS ロギング

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

• ロギングが明示的に無効とされた場合

• ログ用のファイルシステム容量が不足している場合

以前の Solaris リリースでは、UFS ロギングは手動で有効にする必要がありました。UFS ロギングの詳細については、「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 ファイルシステムトランザクションが実行されても、それらの解放されたブロックがファイルシステムの解放リストに即座に追加されない可能性があります。この動作は、ロギングを有効にしてマウントされた UFS ファイルシステムシステム上で発生します。

このような動作は、ファイルシステムのパフォーマンスの向上につながりますが、次の標準に準拠した動作ではありません。

• POSIX, Single UNIX® Specification

• SPARC® Conformance Definition

• SPARC Conformance Definition System V Application Binary Interface

• System V Interface Definition

• X/Open® Portability Guide

これらの標準に準拠するには、解放された領域が即座に利用可能になる必要があります。

次のような場合は、UFS ロギングを無効にすることを検討してください。

• ファイルの削除に関して標準に準拠させたい場合

• 満杯状態に近いファイルシステム上で、ファイルを削除した直後にファイルを作成または拡張しようとすると問題が発生する場合

詳細については、mount_ufs(1M) のマニュアルページを参照してください。

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

Solaris 9 8/03 この Solaris リリースでは、64 ビットの Solaris カーネルを実行しているシステムで、マルチテラバイトの UFS ファイルシステムをサポートします。

以前は、64 ビットと 32 ビットのどちらのシステムでも、UFS ファイルシステムはおよそ 1T バイトに制限されていました。UFS ファイルシステムのコマンドとユーティリティはすべて、マルチテラバイトの UFS ファイルシステムに対応するように更新されました。

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

# ufsdump 0f /dev/md/rdsk/d97 /dev/md/rdsk/d98
  DUMP: Date of this level 0 dump: Tue Jan 07 14:23:36 2003
  DUMP: Date of last level 0 dump: the epoch
  DUMP: Dumping /dev/md/rdsk/d98 to /dev/md/rdsk/d97.
  DUMP: Mapping (Pass I) [regular files]
  DUMP: Mapping (Pass II) [directories]
  DUMP: Forcing larger tape block size (2048).
  DUMP: Writing 32 Kilobyte records
  DUMP: Estimated 4390629500 blocks (2143862.06MB).
  DUMP: Dumping (Pass III) [directories]
  DUMP: Dumping (Pass IV) [regular files]

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

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

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

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

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

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

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

• 最大 16T バイトの UFS ファイルシステムを作成できる

• 16T バイト未満のファイルシステムを作成し、後で 16T バイトまでサイズを増やすことができる

• マルチテラバイトのファイルシステムを物理ディスク、Solaris ボリュームマネージャの論理ボリューム、および Veritas の VxVM 論理ボリューム上に作成できる

• マルチテラバイトのファイルシステムでは、UFS ロギングが有効になっているとパフォーマンスが向上するというメリットがある。また、ロギングが有効なときは fsck コマンドを実行しなくてもよい場合があるというロギングのメリットもある

• マルチテラバイトの UFS ファイルシステム用のパーティションを作成すると、そのディスクには自動的に EFI ディスクラベルが付く。EFI ディスクラベルの詳細については、「SPARC: EFI ディスクラベルによるマルチテラバイトディスクのサポート」を参照

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

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

• Solaris x86 システムでは、この機能はサポートされていない

• 32 ビットの Solaris カーネルを実行しているシステムでは、1T バイトを超えるファイルシステムをマウントすることはできない

• 64 ビットの Solaris カーネルを実行しているシステムでは、1T バイトを超えるファイルシステムからブートすることはできない。つまり、マルチテラバイトのファイルシステムにルート (/) ファイルシステムを配置することはできない

• 1T バイトを超える個々のファイルはサポートされていない

• UFS ファイルシステムの 1T バイトあたりの最大ファイル数は 100 万である。たとえば、4T バイトのファイルシステムには、400 万個のファイルを含めることができる

  100 万に制限されているのは、fsck コマンドでファイルシステムを検査するのに要する時間を減らすためである。

• マルチテラバイトの UFS ファイルシステムに設定できる最大割り当て数は、2T バイトの 1024 バイトブロックである

• 現時点では、fssnap コマンドを使ってマルチテラバイトの UFS ファイルシステムのスナップショットを作成することはできない

マルチテラバイトの UFS ファイルシステムを作成する方法

マルチテラバイトの UFS ファイルシステムは、Solaris ボリュームマネージャまたは VxVM ボリューム、あるいは 1T バイトを超える物理ディスクとして提供されたマルチテラバイトの LUN が利用できることを前提にサポートされています。

マルチテラバイトの UFS ファイルシステムを作成する前に、次のいずれかを行う必要があります。

• format ユーティリティまたは Solaris インストールユーティリティを使ってマルチテラバイトのディスクパーティションを作成しておく

• Solaris ボリュームマネージャを使ってマルチテラバイトのボリュームを設定しておく

手順

1. スーパーユーザーになります。

2. 論理ボリューム上にマルチテラバイトの UFS ファイルシステムを作成します。

   たとえば、次のコマンドを実行すると、1.8T バイトボリュームの UFS ファイルシステムが作成されます。

   # newfs /dev/md/rdsk/d99 newfs: construct a new file system /dev/md/rdsk/d99: (y/n)? y /dev/md/rdsk/d99: 3859402752 sectors in 628158 cylinders of 48 tracks, 128 sectors 1884474.0MB in 4393 cyl groups (143 c/g, 429.00MB/g, 448 i/g) super-block backups (for fsck -F ufs -o b=#) at: 32, 878752, 1757472, 2636192, 3514912, 4393632, 5272352, 6151072, 702... Initializing cylinder groups: ........................................................................ super-block backups for last 10 cylinder groups at: 3850872736, 3851751456, 3852630176, 3853508896, 3854387616, 3855266336, 3856145056, 3857023776, 3857902496, 3858781216, #

3. 新しく作成したファイルシステムの整合性を検査します。

   次に例を示します。

   # fsck /dev/md/rdsk/d99 ** /dev/md/rdsk/d99 ** Last Mounted on ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 2 files, 2 used, 241173122 free (0 frags, 241173122 blocks, 0.0% fragmentation) #

4. 新しく作成したファイルシステムをマウントして検査します。

   次に例を示します。

   # mount /dev/md/dsk/d99 /bigdir # df -h /bigdir Filesystem size used avail capacity Mounted on /dev/md/dsk/d99 1.8T 64M 1.8T 1% /bigdir

マルチテラバイトの UFS ファイルシステムを拡張する方法

マルチテラバイトの UFS ファイルシステムを作成した後は、growfs コマンドを使ってファイルシステムを拡張できます。たとえば、前の手順でボリュームに作成したファイルシステムを使用すると、別のディスクをこのボリュームに追加できます。その後で、ファイルシステムを拡張します。

手順

1. スーパーユーザーになります。

2. 別のディスクをボリュームに追加します。

   次に例を示します。

   # metattach d99 c4t5d0s4 d99: component is attached # metastat d99: Concat/Stripe Size: 5145882624 blocks (2.4 TB) Stripe 0: Device Start Block Dbase Reloc c0t1d0s4 36864 Yes Yes Stripe 1: Device Start Block Dbase Reloc c3t7d0s4 0 No Yes Stripe 2: Device Start Block Dbase Reloc c1t1d0s4 0 No Yes Stripe 3: Device Start Block Dbase Reloc c4t5d0s4 0 No Yes

3. ファイルシステムを拡張します。

   次に例を示します。

   # growfs -v /dev/md/rdsk/d99 /usr/lib/fs/ufs/mkfs -G /dev/md/rdsk/d99 5145882624 /dev/md/rdsk/d99: 5145882624 sectors in 837546 cylinders of 48 tracks, 128 sectors 2512638.0MB in 5857 cyl groups (143 c/g, 429.00MB/g, 448 i/g) super-block backups (for fsck -F ufs -o b=#) at: 32, 878752, 1757472, 2636192, 3514912, 4393632, 5272352, 6151072, 702... Initializing cylinder groups: ......................................................................... super-block backups for last 10 cylinder groups at: 5137130400, 5138009120, 5138887840, 5139766560, 5140645280, 5141524000, 5142402720, 5143281440, 5144160160, 5145038880, #

4. 拡張したファイルシステムをマウントして検査します。

   次に例を示します。

   # mount /dev/md/dsk/d99 /bigdir # df -h /bigdir Filesystem size used avail capacity Mounted on /dev/md/dsk/d99 2.4T 64M 2.4T 1% /bigdir

UFS ファイルシステムをマルチテラバイトの UFS ファイルシステムに拡張する方法

UFS ファイルシステムを 1T バイトを超えるサイズに拡張するには、次の手順を実行します。この手順は、newfs -T オプションを使って UFS ファイルシステムを作成したことを前提としています。

手順

1. スーパーユーザーになります。

2. 現在のディスクまたはボリュームのサイズを特定します。

   たとえば、次のボリュームは 800G バイトです。

   # metastat d98 d98: Concat/Stripe Size: 1677754368 blocks (800 GB) Stripe 0: Device Start Block Dbase Reloc c0t1d0s4 0 No Yes Stripe 1: Device Start Block Dbase Reloc c3t7d0s4 0 No Yes

3. このボリュームを 1T バイトよりも大きくします。

   次に例を示します。

   # metattach d98 c1t1d0s4 d98: component is attached # metastat d98 d98: Concat/Stripe Size: 2516631552 blocks (1.2 TB) Stripe 0: Device Start Block Dbase Reloc c0t1d0s4 0 No Yes Stripe 1: Device Start Block Dbase Reloc c3t7d0s4 0 No Yes Stripe 2: Device Start Block Dbase Reloc c1t1d0s4 0 No Yes

4. ディスクまたはボリュームの UFS ファイルシステムを 1T バイトよりも大きくします。

   次に例を示します。

   growfs -v /dev/md/rdsk/d98 /usr/lib/fs/ufs/mkfs -G /dev/md/rdsk/d98 2516631552 /dev/md/rdsk/d98: 2516631552 sectors in 68268 cylinders of 144 tracks, 256 sectors 1228824.0MB in 2731 cyl groups (25 c/g, 450.00MB/g, 448 i/g) super-block backups (for fsck -F ufs -o b=#) at: 32, 921888, 1843744, 2765600, 3687456, 4609312, 5531168, 6453024, 737... 8296736, Initializing cylinder groups: ...................................................... super-block backups for last 10 cylinder groups at: 2507714848, 2508636704, 2509558560, 2510480416, 2511402272, 2512324128, 2513245984, 2514167840, 2515089696, 2516011552,

5. 拡張したファイルシステムをマウントして検査します。

   次に例を示します。

   # mount /dev/md/dsk/d98 /datadir # df -h /datadir Filesystem size used avail capacity Mounted on /dev/md/dsk/d98 1.2T 64M 1.2T 1% /datadir

マルチテラバイトの UFS ファイルシステムに関する問題の障害追跡

マルチテラバイトの UFS ファイルシステムに関する問題の障害追跡には、次のエラーメッセージと解決法を参考にしてください。

エラーメッセージ (次に例を示す)

mount: /dev/rdsk/c0t0d0s0 はこのファイルシステム形式ではありません。

原因

Solaris 9 8/03 リリースよりも以前のリリースが動作するシステムに 1T バイトを超える UFS ファイルシステムをマウントしようとしました。

解決法

1T バイトを超える UFS ファイルシステムは、Solaris 9 8/03 以降のリリースが動作するシステムにマウントしてください。

エラーメッセージ

"ファイルシステムがマルチテラバイト形式に設定されて いません。" "そのサイズは 1 テラバイト以上にできません。"

原因

newfs -T コマンドを使わずに作成したファイルシステムを拡張しようとしました。

解決法

1. 1T バイトより大きくするファイルシステムのデータをバックアップします。

2. newfs コマンドを使用して、ファイルシステムをマルチテラバイトファイルシステムに再作成します。

3. 新しく作成したファイルシステムにバックアップされていたデータを復元します。

ファイルシステム管理作業についての参照先

ファイルシステムの管理に関する手順を調べるには、次の参照先を使用します。

ファイルシステムの概要

ファイルシステムは、ファイルを編成して格納するためのディレクトリ構造です。「ファイルシステム」という用語は、次のような場合に使用されます。

• ディスクベース、ネットワークベース、または仮想ファイルシステムなど、特定のタイプのファイルシステムを指す場合

• ルートディレクトリから始まるファイルツリー全体を指す場合

• ディスクスライスや他の記憶メディアデバイスのデータ構造を指す場合

• ファイルツリー構造のうち、ファイルがアクセスできるように主なファイルツリー上のマウントポイントに接続されている部分を指す場合

通常、その意味は状況に応じて判断できます。

Solaris オペレーティング環境は、各種ファイルシステムへの標準インタフェースを提供する「仮想ファイルシステム」 (VFS) アーキテクチャを使用します。VFS アーキテクチャを使用すると、カーネルはファイルの読み取り、書き込み、一覧表示などの基本操作を処理でき、新しいファイルシステムの追加が簡単になります。

ファイルシステムのタイプ

Solaris システムソフトウェアでは、次の 3 種類のファイルシステムがサポートされます。

• ディスクベースのファイルシステム

• ネットワークベースのファイルシステム

• 仮想ファイルシステム

ファイルシステムのタイプを確認するには、「ファイルシステムのタイプを調べる」を参照してください。

ディスクベースのファイルシステム

ディスクベースのファイルシステムは、ハードディスク、CD-ROM、フロッピーディスクなどの物理メディアに格納されます。ディスクベースのファイルシステムは、さまざまな形式で作成できます。利用できる形式は次のとおりです。

ディスクベースの各種ファイルシステムは、次のように特定のメディアのタイプに対応しています。

• UFS とハードディスク

• HSFS と CD-ROM

• PCFS とフロッピーディスク

• UDF と DVD

ただし、上記以外の組み合わせも可能です。たとえば、CD-ROM やフロッピーディスクにも、UFS ファイルシステムを格納できます。

ネットワークベースのファイルシステム

ネットワークベースのファイルシステムは、ネットワークからアクセスされるファイルシステムです。一般に、ネットワークベースのファイルシステムは 1 つのシステム上 (通常はサーバー上) にあり、他のシステムからネットワーク経由でアクセスされます。

NFS で分散された「リソース」 (ファイルやディレクトリ) を管理するには、サーバーからそれらのリソースをエクスポートして個々のクライアントシステムでマウントします。 詳細については、「NFS 環境」を参照してください。

仮想ファイルシステム

仮想ファイルシステムは、特殊なカーネル情報と機能へのアクセスを提供するメモリーベースのファイルシステムです。ほとんどの仮想ファイルシステムは、ディスク領域を使用しません。ただし、CacheFS ファイルシステムは、ディスク上のファイルシステムを使用してキャッシュを保持します。また、一時ファイルシステム (TMPFS) などの一部の仮想ファイルシステムは、ディスク上のスワップ空間を使用します。

CacheFS ファイルシステム

CacheFS^TM ファイルシステムを使用すると、リモートファイルシステムや、CD-ROM ドライブのような低速デバイスのパフォーマンスを改善できます。ファイルシステムをキャッシュすると、リモートファイルシステムや CD-ROM から読み込まれたデータは、ローカルシステム上のキャッシュに格納されます。

NFS や CD-ROM ファイルシステムのパフォーマンスとスケーラビリティを向上させるには、CacheFS ファイルシステムを使用してください。CacheFS ソフトウェアは、サーバーとネットワークの負荷を軽減して NFS サーバーのパフォーマンスとスケーラビリティを改善する汎用ファイルシステムキャッシュメカニズムです。

CacheFS ソフトウェアは、階層化ファイルシステムとして設計されており、あるファイルシステムを別のファイルシステムのキャッシュに書き込む機能を持っています。NFS 環境では、CacheFS ソフトウェアはサーバーあたりのクライアント比率を高め、サーバーとネットワークの負荷を軽減し、ポイントツーポイントプロトコル (PPP) などの低速リンク上のクライアントのパフォーマンスを向上させます。また、CacheFS ファイルシステムと AutoFS サービスを組み合わせると、パフォーマンスとスケーラビリティをさらに向上させることができます。

CacheFS ファイルシステムの詳細については、第18章「CacheFS ファイルシステムの使用 (手順)」を参照してください。

UDF (Universal Disk Format) ファイルシステム

UDF ファイルシステムは、「DVD」 (Digital Versatile Disc または Digital Video Disc) 光学式メディアに情報を格納するための業界標準形式です。

UDF ファイルシステムは、SPARC と x86 の両方のプラットフォームにおいて、動的に読み込み可能な 32 ビットと 64 ビットのモジュールとして提供されます。また、ファイルシステムを作成、マウント、および検査するシステム管理ユーティリティも同時に提供されます。Solaris の UDF ファイルシステムは、サポートされている ATAPI と SCSI の DVD ドライブ、CD-ROM デバイス、ハードディスク、およびフロッピーディスクドライブで機能します。さらに、Solaris の UDF ファイルシステムは UDF 1.50 仕様に完全に準拠しています。

UDF ファイルシステムには次のような機能があります。

• UDF ファイルシステムが入っている業界標準の CD-ROM や DVD-ROM のメディアにアクセスできます。

• さまざまなプラットフォームやオペレーティングシステムで情報を交換できます。

• UDF 形式に基づく DVD ビデオ仕様を使用することで、相互対話性が豊富な放送品質並みの映像や高品質のサウンドを持つ新しいアプリケーションを実装できます。

次の機能は、UDF ファイルシステムにはありません。

• CD-RW (何度でも書き換えが可能な CD メディア) と DVD-RAM への順次ディスク同時記録方式と増分記録方式での書き込み

• UDF 1.50 仕様の一部ではないディスク割り当て、ACL、トランザクションのロギング、ファイルシステムのロック、およびファイルシステムのスレッドなど UFS 構成要素

次に、UDF ファイルシステムの要件を示します。

• Solaris 7 11/99 以降のリリースが動作していること

• SPARC または x86 プラットフォームがサポートされていること

• CD-ROM または DVD-ROM ドライブがサポートされていること

Solaris で実装された UDF ファイルシステムには、次のような互換性があります。

• 業界標準の読み取り / 書き込み UDF バージョン 1.50 のサポート

• 完全に国際化されたファイルシステムのユーティリティ

一時ファイルシステム

一時ファイルシステム (TMPFS) は、ファイルシステムの読み取りと書き込みにローカルメモリーを使用します。一般に、一時ファイルシステムは、UFS ファイルシステムに比べてアクセス速度が高速です。TMPFS を使用すると、ローカルディスク上で、あるいはネットワーク経由で一時ファイルの読み書きを行う際のオーバヘッドを軽減でき、システムパフォーマンスを改善できます。たとえば、プログラムをコンパイルすると一時ファイルが作成されます。オペレーティングシステムは、これらのファイルを処理する間に大量のディスク処理やネットワーク処理を行います。TMPFS を使用してこれらの一時ファイルを格納すると、その作成、処理、または削除が大幅に高速になります。

TMPFS ファイルシステムのファイルは、永続的に保存されるわけではありません。ファイルシステムのマウントが解除されるときと、システムがシャットダウンまたはリブートされるときに、一時ファイルシステムのファイルは削除されます。

TMPFS は、Solaris オペレーティングシステム内の /tmp ディレクトリのデフォルトのファイルシステムです。UFS ファイルシステムの場合と同様に、/tmp ディレクトリとの間でファイルをコピーまたは移動できます。

TMPFS ファイルシステムは、一時的な退避場所としてスワップ空間を使用します。TMPFS ファイルシステムがマウントされたシステムのスワップ空間が足りないと、次の 2 つの問題が発生する可能性があります。

• TMPFS ファイルシステムは、通常のファイルシステムと同様に容量不足になる可能性がある。

• TMPFS はスワップ空間を割り当ててファイルのデータを保存するので (必要な場合)、一部のプログラムがスワップ空間不足のために実行できなくなる可能性がある。

TMPFS ファイルシステムの作成方法については、第16章「UFS、TMPFS、LOFS ファイルシステムの作成 (手順)」を参照してください。スワップ空間を拡張する方法については、第19章「追加スワップ空間の構成 (手順)」を参照してください。

ループバックファイルシステム

ループバックファイルシステム (LOFS) を使用すると、代替パス名を使用してファイルにアクセスできるように、新しい仮想ファイルシステムを作成できます。たとえば、ルート (/) のループバックマウントを /tmp/newroot 上で作成できます。ファイルシステム階層全体が、NFS サーバーからマウントされるファイルシステムを含め、/tmp/newroot 上に複写されたように見えます。どのファイルにも、ルート (/) で始まるパス名または /tmp/newroot で始まるパス名を使用してアクセスできます。

LOFS ファイルシステムの作成方法については、第16章「UFS、TMPFS、LOFS ファイルシステムの作成 (手順)」を参照してください。

プロセスファイルシステム

プロセスファイルシステム (PROCFS) はメモリー内にあり、/proc ディレクトリには、アクティブなプロセスのプロセス番号別リストが入っています。/proc ディレクトリの内容は、ps などのコマンドで使用されます。デバッガや他の開発ツールも、ファイルシステムコールを使用して、プロセスのアドレス空間にアクセスできます。

/proc ディレクトリ内のファイルは削除しないでください。/proc ディレクトリからプロセスを削除しても、そのプロセスは強制終了されません。/proc ファイルはディスク容量を消費しないため、このディレクトリからファイルを削除してもあまり意味がありません。

/proc ディレクトリは、管理が不要です。

その他の仮想ファイルシステム

次のタイプの仮想ファイルシステムは、参考のために掲載してあります。管理は不要です。

拡張ファイル属性

UFS、NFS、および TMPFS ファイルシステムは、拡張ファイル属性を包含するように機能拡張されました。拡張ファイル属性によりアプリケーション開発者は、ファイルを特定の属性に関連付けることができます。たとえば、ウィンドウシステムファイル管理アプリケーションの開発者は、表示アイコンをファイルに関連付けることができます。拡張ファイル属性は、論理的には、ターゲットファイルに関連付けられている隠しディレクトリ内のファイルとして表されます。

runat コマンドを使用すると、属性を追加したり、拡張属性の名前空間に入っているシェルコマンドを実行したりできます。拡張属性の名前空間とは、指定のファイルに関連付けられている隠し属性ディレクトリのことです。

runat コマンドを使用して属性をファイルに追加するには、最初に属性ファイルを作成する必要があります。

$ runat filea cp /tmp/attrdata attr.1

次に、runat コマンドを使用して、ファイルの属性をリストに表示します。

$ runat filea ls -l

詳細については、runat(1) のマニュアルページを参照してください。

ファイル属性の照会、コピー、または検索に使用できる属性対応のオプションを提供することにより、Solaris ファイルシステムコマンドの多くは、ファイルシステム属性をサポートするよう変更されました。詳細については、各ファイルシステムコマンドのマニュアルページを参照してください。

ファイルシステム管理用のコマンド

ほとんどのファイルシステム管理コマンドには、汎用コマンドとファイルシステムに固有のコマンドの 2 種類があります。可能な場合には、常に汎用コマンドを使用してください。汎用コマンドは、ファイルシステム固有のコマンドを呼び出します。次の表に、ファイルシステム管理用の汎用コマンドを示します。これらのコマンドは、/usr/sbin ディレクトリに入っています。

ファイルシステムコマンドによるファイルシステムタイプの判断

汎用ファイルシステムコマンドは、次の順序でファイルシステムのタイプを判断します。

1. 指定されている場合は、-F オプションで指定されているファイルシステムのタイプから判断します。

2. 特殊デバイスを /etc/vfstab ファイルのエントリと突き合わせて判断します (special が指定されている場合)。 たとえば fsck は、まず fsck device フィールドと突き合わせて一致するエントリを検索します。一致するエントリが見つからなければ、特殊デバイスフィールドと突き合わせてチェックします。

3. ローカルファイルシステムの場合は /etc/default/fs ファイル内に指定されたデフォルトを使用し、リモートファイルシステムの場合は/etc/dfs/fstypes ファイル内に指定されたデフォルトを使用して判断します。

汎用コマンドと専用コマンドのマニュアルページ

汎用コマンドと専用コマンドについては、『man pages section 1M: System Administration Commands』を参照してください。ファイルシステムの汎用コマンドのマニュアルページには、汎用コマンドオプションに関する情報だけが記載されています 。専用コマンドのマニュアルページには、該当するファイルシステムに固有のオプション情報が記載されています。特定のマニュアルページを見つけるには、汎用コマンド名の末尾にアンダースコアとファイルシステムタイプの略称を追加してください。たとえば、UFS ファイルシステムのマウントについてのマニュアルページを参照するには、次のように入力します。

$ man mount_ufs

デフォルトの Solaris ファイルシステム

Solaris UFS ファイルシステムは階層構造になっており、ルートディレクトリ (/) から始まり、下位に多数のディレクトリが形成されています。Solaris のインストールプロセスは、デフォルトのディレクトリセットをインストールし、一連の規則を適用して類似するタイプのファイルをグループ化します。次の表に、デフォルトの Solaris ファイルシステムの概要を示します。

システムを動作させるには、ルート (/) と /usr のファイルシステムが必要です。/usr ファイルシステムに置かれているもっとも基本的なコマンドの一部 (mount など) は、システムのブート時や、システムがシングルユーザーモードで実行しており、/usr ファイルシステムがマウントされていない場合でも使用できるように、ルート (/) ファイルシステムにも置かれています。ルート (/) と /usr ファイルシステムのデフォルトディレクトリの詳細については、第21章「UFS ファイルシステム (参照情報)」を参照してください。

スワップ空間

Solaris オペレーティングシステムは、一部のディスクスライスをファイルシステムではなく一時記憶域として使用します。これらのスライスを「スワップスライス」または「スワップ空間」と呼びます。スワップスライスは、現在のプロセスを処理するだけの十分な物理メモリーがシステムにない場合に、仮想メモリー記憶域として使用されます。

多くのアプリケーションは十分なスワップ空間が使用できることを前提に作成されているため、スワップ空間を割り当て、その使われ方を監視して、必要に応じてスワップ空間を追加する方法を知っておく必要があります。スワップ空間の概要とスワップ空間を追加する手順については、第19章「追加スワップ空間の構成 (手順)」を参照してください。

UFS ファイルシステム

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

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

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

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

• 作業負荷を異なる入出力システムやディスクドライブ間でできるだけ均等に分散します。/export/home ファイルシステムやスワップ空間を異なるディスク間で均等に分散させます。

• プロジェクトの個々の部分やグループのメンバーを同じファイルシステム内に入れます。

• 1 ディスク当たりのファイルシステム数をできるだけ少なくします。通常、システム (またはブート) ディスク上には、 ルート (/)、/usr、スワップ空間の 3 つのファイルシステムがあります。他のディスクには、1 つまたは多くても 2 つのファイルシステム (1 つはなるべく追加スワップ空間) を作成します。多数の小規模なファイルシステムに分割しすぎるよりもファイルシステム数を少なくして余地を設ける方が、ファイルがフラグメントに分割される可能性が小さくなります。容量の大きいテープドライブを使用し、ufsdump コマンドで複数のボリュームを処理できるようにしておけば、大規模なファイルシステムでも簡単にバックアップをとることができます。

• 絶えずきわめて小さいファイルを作成するユーザーがいる場合は、i ノード数を増やして別のファイルシステムを作成することを検討します。ただし、ほとんどのサイトでは、類似するタイプのファイルを同じファイルシステム内で保管する必要はありません。

デフォルトのファイルシステムパラメータや、新しい UFS ファイルシステムを作成する手順については、第16章「UFS、TMPFS、LOFS ファイルシステムの作成 (手順)」を参照してください。

UFS ロギング

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

システムはリブート時に、不完全なトランザクションを廃棄しますが、完結している操作のトランザクションは適用します。完結しているトランザクションだけが適用されるために、ファイルシステムの整合性が保たれます。通常であればシステムコールの実行が中断され、UFS ファイルシステムの整合性が確保できないシステムクラッシュ時にも、ファイルシステムの整合性が保たれます。

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

• トランザクションログによりファイルシステムの整合性がすでに保持されている場合、システムがクラッシュしたとき、またはクリーンでないシステム停止が発生したときに、fsck コマンドを実行する必要がないことがあります。クリーンでない停止については、「fsck コマンドでチェックして修復される内容」を参照してください。

• Solaris 9 12/02 以降、UFS ロギングのパフォーマンスは、非ロギングファイルシステムのパフォーマンスレベルを上回るようになりました。このようにパフォーマンスが改善されるのは、ロギングを有効にしたファイルシステムでは、同じデータに対する複数回の更新が1 回の更新に変換されるため、オーバーヘッドの大きいディスク操作の実行回数が減るからです。

ログはファイルシステムの空きブロックから割り当てられ、1G バイトのファイルシステムごとに約 1M バイトのサイズ (合計で 64M バイトまで) が割り当てられます。ログは、いっぱいになるとフラッシュされます。また、ファイルシステムがマウント解除されたとき、あるいは lockfs コマンドを実行したときにも、ログがフラッシュされます。

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

UFS ロギングを無効にする必要がある場合は、/etc/vfstab ファイル内のファイルシステムのエントリに nologging オプションを追加するか、ファイルシステムを手動でマウントするときに nologging オプションを指定します。

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

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

UFS スナップショット

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

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

UFS 直接入出力

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

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

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

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

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

ファイルシステムのマウントとマウント解除

ファイルシステム上のファイルにアクセスするには、ファイルシステムをマウントする必要があります。ファイルシステムのマウントとは、ファイルシステムを特定のディレクトリ (マウントポイント) に接続し、システムで使用可能にすることです。 ルート (/) ファイルシステムは、常にマウントされています。他のファイルシステムは、ルート (/) ファイルシステムに接続したり切り離したりできます。

ファイルシステムをマウントすると、そのファイルシステムがマウントされている間は、マウントポイントのディレクトリ内に実際に存在しているファイルやディレクトリは使用できなくなります。これらのファイルはマウント処理の影響を永続的に受けるわけではなく、ファイルシステムをマウント解除すると再び使用できるようになります。通常は存在はするがアクセスできないファイルは混乱の原因になるので、マウントディレクトリを空にしておきます。

たとえば、次の図は、ルート (/) ファイルシステムと、その下の sbin、etc、opt の各サブディレクトリから始まるローカルファイルシステムを示しています。

図 151 ルート (/) ファイルシステムの例

別パッケージの製品が含まれている /opt ファイルシステムからローカルファイルシステムにアクセスするには、次の作業を行います。

• まず、ファイルシステムをマウントするためのマウントポイントとして使用するディレクトリを作成しなければなりません (たとえば、/opt/unbundled)。

• マウントポイントを作成すると、mount コマンドでファイルシステムをマウントでき、/opt/unbundled 内のすべてのファイルとディレクトリにアクセスできるようになります (次の図を参照)。

ファイルシステムのマウント方法については、第17章「ファイルシステムのマウントとマウント解除 (手順)」を参照してください。

図 152 ファイルシステムのマウント

マウントされたファイルシステムテーブル

ファイルシステムをマウントまたはマウント解除すると、現在マウントされているファイルシステムのリストを使用して、/etc/mnttab (マウントテーブル) ファイルが変更されます。このファイルの内容は cat または more コマンドを使用して表示できますが、編集することはできません。次にマウントテーブルファイル /etc/mnttab の例を示します。

$ more /etc/mnttab
/dev/dsk/c0t0d0s0  /  ufs rw,intr,largefiles,onerror=panic,suid,dev=2200000 938557523
/proc   /proc   proc    dev=3180000     938557522
fd      /dev/fd fd      rw,suid,dev=3240000     938557524
mnttab  /etc/mnttab     mntfs   dev=3340000     938557526
swap    /var/run        tmpfs   dev=1   938557526
swap    /tmp    tmpfs   dev=2   938557529
/dev/dsk/c0t0d0s7 /export/home ufs rw,intr,largefiles,onerror=panic,suid,dev=2200007 ...
$

仮想ファイルシステムテーブル

アクセスするたびにファイルシステムを手動でマウントするのは、時間がかり、またまちがいが起こりやすい作業です。この問題を解決するために、仮想ファイルシステムテーブル (/etc/vfstab ファイル) にファイルシステムのリストとそのマウント方法を指定できます。

/etc/vfstab ファイルは、2 つの重要な機能を持っています。

• 1 つは、システムブート時に自動的にマウントするファイルシステムを指定できることです。

• もう 1 つは、マウントポイント名だけでファイルシステムをマウントできることです。これは、/etc/vfstab ファイルにマウントポイントと実際のデバイススライス名とのマッピングを指定することができるためです。

デフォルトの /etc/vfstab ファイルは、システムをインストールするときに作成され、その内容はシステムソフトウェアをインストールするときに行なった選択によって異なります。ただし、システムの /etc/vfstab ファイルはいつでも編集できます。エントリを追加するときに指定する必要がある主な情報は、ファイルシステムが置かれているデバイス、マウントポイントの名前、ファイルシステムのタイプ、システムブート時に自動的にマウントするかどうか (mountall コマンドを使用する)、およびマウントオプションです。

次の例は、/etc/vfstab ファイルの内容を示しています。コメント行は # で始まります。この例は、2 つのディスク (c0t0d0 と c0t3d0) を持つシステムの /etc/vfstab ファイルを示しています。

$ more /etc/vfstab
#device         device          mount           FS      fsck   mount  mount
#to mount       to fsck         point           type    pass   at boot options
/dev/dsk/c0t0d0s0 /dev/rdsk/c0t0d0s0 /          ufs     1       no      -
/proc           -               /proc           proc    -       no      -
/dev/dsk/c0t0d0s1 -                -            swap    -       no      -
swap            -               /tmp            tmpfs   -       yes     -
/dev/dsk/c0t0d0s6 /dev/rdsk/c0t0d0s6 /usr       ufs     2       no      -
/dev/dsk/c0t3d0s7 /dev/rdsk/c0t3d0s7 /test      ufs     2       yes     -
$

上の例の最後のエントリは、システムブート時に /dev/dsk/c0t3d0s7 スライス上の UFS ファイルシステムが自動的にマウントポイント /test にマウントされることを示しています。ルート (/) と /usr では、mount at boot フィールドの値が no に指定されていることに注意してください。これはこの 2 つのファイルシステムが、mountall コマンドを実行する前にブートシーケンスの一部としてカーネルによってマウントされるからです。

/etc/vfstab の各フィールドの説明、およびこのファイルの編集/使用方法については、第17章「ファイルシステムのマウントとマウント解除 (手順)」を参照してください。

NFS 環境

NFS は、1 つのシステム (通常はサーバー) の「リソース」 (ファイルやディレクトリ) をネットワーク上の他のシステムと共有するための分散型ファイルシステムサービスです。 たとえば、Sun 以外のアプリケーションやソースファイルを他のシステム上のユーザーと共有できます。

NFS は、リソースの実際の物理的な位置をユーザーが意識しなくてすむようにします。よく使用されるファイルのコピーをシステムごとに配置しなくても、あるシステムのディスク上にコピーを 1 つ配置することによって NFS は、他のすべてのシステムがそのコピーにネットワークからアクセスできるようにします。NFS の環境では、リモートファイルシステムは、実際にはローカルシステムと区別がつきません。

システムは、ネットワーク上で共有するリソースがあるときに、NFS サーバーになります。サーバーは、現在共有されているリソースとそのアクセス制限 (読み取り / 書き込み、読み取り専用アクセスなど) のリストを管理します。

リソースを共有する場合は、リモートシステムにマウントできるように、そのリソースを使用可能な状態にします。

リソースを共有するには、次の方法があります。

• share コマンドまたは shareall コマンドを使用する。

• /etc/dfs/dfstab (分散ファイルシステムテーブル) ファイルにエントリを追加し、システムをリブートする。

リソースを共有する方法については、第17章「ファイルシステムのマウントとマウント解除 (手順)」を参照してください。NFS の詳細については、『Solaris のシステム管理 (資源管理とネットワークサービス)』の第 13 章「ネットワークファイルシステムの管理 (概要)」を参照してください。

自動マウントまたは AutoFS

NFS ファイルシステムリソースをマウントするには、自動マウント (または AutoFS) というクライアント側のサービスを使用します。このサービスによってシステムは、ユーザーがアクセスしたときに自動的に NFS リソースをマウントまたはマウント解除できます。ユーザーがファイルシステム内のファイルを使用している間、ファイルシステムリソースはマウントされたままになります。リソースが一定の時間アクセスされなかった場合、リソースは自動的にマウント解除されます。

次に、AutoFS の特徴を示します。

• システムブート時に NFS リソースをマウントする必要がないために、ブート時間が短くなります。

• NFS リソースをマウントまたはマウント解除するために、スーパーユーザーのパスワードを知っている必要はありません。

• NFS リソースは使用されるときにだけマウントされるために、ネットワークトラフィックが軽減されます。

AutoFS サービスは automount ユーティリティによって初期化されます。このコマンドは、システムのブート時に自動的に実行されます。automountd デーモンは永続的に動作し、必要に応じて NFS ファイルシステムをマウントまたはマウント解除します。デフォルトでは、/home ファイルシステムは automount デーモンによってマウントされます。

AutoFS では、同じファイルシステムを提供するサーバーを複数指定できます。このような方法では、1 つのサーバーがダウンしても、AutoFS が他のマシンからファイルシステムをマウントすることができます。

AutoFS の設定と管理方法については、『Solaris のシステム管理 (IP サービス)』を参照してください。

ファイルシステムのタイプを調べる

ファイルシステムのタイプは、次のいずれかを使用して判断できます。

• 仮想ファイルシステムテーブル (/etc/vfstab ファイル) 内の FS type フィールド

• ローカルファイルシステムの /etc/default/fs ファイル

• NFS ファイルシステムの /etc/dfs/fstypes ファイル

ファイルシステムのタイプを調べる方法

この手順は、ファイルシステムがマウントされているかどうかにかかわらず、使用できます。

grep コマンドを使用して、ファイルシステムのタイプを調べます。

$ grep mount-point fs-table

mount-point

ファイルシステムタイプを調べるファイルシステムのマウントポイント名を指定する。たとえば、/var ディレクトリ

fs-table

ファイルシステムのタイプを調べるファイルシステムテーブルへの絶対パスを示す。ファイルシステムがマウントされている場合、fs-table は /etc/mnttab。マウントされていない場合、fs-table は /etc/vfstab

マウントポイントの情報が表示されます。

ディスクスライスの raw デバイス名がわかる場合、fstyp コマンドで、ファイルシステムのタイプを調べることができます (そのディスクスライスにファイルシステムが含まれている場合)。詳細については、fstyp(1M) のマニュアルページを参照し てください。

例 ファイルシステムのタイプを調べる

次の例では、/etc/vfstab を使用して、/export ファイルシステムのタイプを調べます。

$ grep /export /etc/vfstab
/dev/dsk/c0t3d0s6   /dev/rdsk/c0t3d0s6  /export ufs   2       yes    -
$ 

次の例では、/etc/mnttab ファイルを使用して、現在マウントされているフロッピーディスク (vold でマウントされたもの) のファイルシステムのタイプを調べます。

$ grep /floppy /etc/mnttab
/vol/dev/diskette0/unnamed_floppy   /floppy/unnamed_floppy  pcfs rw,
nohidden,nofoldcase,dev=16c0009      89103376
$