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

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

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

• 「ファイルシステムの新機能」

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

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

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

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

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

• 「スワップ空間」

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

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

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

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

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

• 「ファイルシステム監視ツール (fsstat) 」

• 「Oracle Solaris ZFS ファイルシステム」

• 「UFS ファイルシステムユーティリティー (fsck、mkfs、および newfs) の拡張機能」

Solaris の新機能の一覧および Solaris リリースについての説明は、『Oracle Solaris 10 9/10 の新機能』を参照してください。

ファイルシステム監視ツール (fsstat)

Solaris 10 6/06: 新しいファイルシステム監視ツール fsstat を使用してファイルシステムの操作を報告できます。いくつかのオプションを使用して、マウントポイントごとまたはファイルシステムのタイプごとなどの活動を報告できます。

たとえば、次の fsstat コマンドは、ZFS モジュールがロードされてからのすべての ZFS ファイルシステムの操作を表示します。

$ fsstat zfs
 new  name   name  attr  attr lookup rddir  read read  write write
 file remov  chng   get   set    ops   ops   ops bytes   ops bytes
 268K  145K 93.6K 28.0M 71.1K   186M 2.74M 12.9M 56.2G 1.61M 9.46G zfs

たとえば、次の fsstat コマンドは、/export/ws ファイルシステムがマウントされてからのすべてのファイルシステムの操作を表示します。

$ fsstat /export/ws
new  name   name  attr  attr lookup rddir  read read  write write
file remov  chng   get   set    ops   ops   ops bytes   ops bytes
   0     0     0 18.1K     0  12.6M    52     0     0     0     0 /export/ws

デフォルトのフォームは、G バイト、K バイト、M バイトなど、理解しやすい値を使用して統計情報を報告します。

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

Oracle Solaris ZFS ファイルシステム

Solaris 10 6/06: 革新的な新しいファイルシステムである Oracle Solaris ZFS は、管理の簡素化、トランザクションのセマンティクス、エンドツーエンドのデータの整合性、および大きなスケーラビリティーを提供します。さらに、ZFS は次の管理機能を提供します。

• バックアップと復元の機能

• デバイス管理のサポート

• GUI 管理ツール

• 持続的なスナップショットの作成と複製の機能

• ファイルシステムの割り当て制限の設定機能

• RBAC ベースのアクセス制御機能

• ストレージプールによるファイルシステムの容量の予約機能

• ゾーンがインストールされた Solaris システムのサポート

ZFS の使用方法の詳細は、『Oracle Solaris ZFS 管理ガイド』を参照してください。

UFS ファイルシステムユーティリティー (fsck、mkfs、および newfs) の拡張機能

Solaris 10 6/06: ファイルシステム検査ユーティリティー fsck は、FreeBSD 4.9 バージョンの fsck プログラム内の機能やその他の拡張機能が含まれるように拡張されています。

Solaris リリースの fsck ユーティリティーには次の改善が加えられています。

• ファイルシステムをより詳しく検査して修復し、改善されたエラーメッセージを表示します。たとえばいくつかのシナリオにおいて、fsck は失われている構造を特定し、それらを適切に置き換えます。

• バックアップスーパーブロックを自動的に検索します。

• fsck を再実行する必要があるタイミングを報告します。

• ディレクトリが消去された場合は、fsck が直ちにディレクトリの内容の復元を試みるので、このユーティリティーの再実行時間が短縮されます。

• fsck が重複するブロックを検出し、重複するブロックを参照するすべてのファイルがクリアーされなかった場合、fsck は、fsck の実行の最後に i ノード番号を報告します。そのあとで、find コマンドを使用して破損した i ノードを確認できます。

• デバイスファイルや ACL エントリなどの拡張属性およびほかの特別なファイルのステータスに関連する改善されたエラーメッセージが含まれています。

• より詳細なメッセージを使用できるようにする -v オプションが用意されています。

さらに、newfs コマンドと mkfs コマンドが更新され、ファイルシステムのスーパーブロック情報をテキストで表示したり、スーパーブロック情報をバイナリ形式でダンプしたりするための新しいオプションが追加されました。

newfs [ -S or -B ] /dev/rdsk/...

-S

ファイルシステムのスーパーブロックをテキスト形式で表示します。

-B

ファイルシステムのスーパーブロックをバイナリ形式でダンプします。

mkfs [ -o calcsb or -o calcbinsb ] /dev/rdsk/... size

-o calcsb

ファイルシステムのスーパーブロックをテキスト形式で表示します。

-o calcbinsb

ファイルシステムのスーパーブロックをバイナリ形式でダンプします。

fsck ユーティリティーは、このスーパーブロック情報を使用して、バックアップスーパーブロックを検索します。

次の節では、具体的な fsck の機能拡張および対応するエラーメッセージについて説明します。fsck ユーティリティーを使用して破損したスーパーブロックを修復する手順については、「不正なスーパーブロックを復元する方法 (Solaris 10 6/06 リリース)」を参照してください。

バックアップスーパーブロックの自動検索

次の fsck エラーメッセージの例は、バックアップスーパーブロックの自動発見の失敗を示しています。

ファイルシステムに破損したスーパーブロックが含まれ、ntrack や nsect などの newfs または mkfs のカスタマイズされたパラメータを使用してファイルシステムが作成されている場合、修復処理のために自動的に発見されたスーパーブロックがファイルシステムを破損させる可能性があります。

カスタマイズされたパラメータを使用して作成されたファイルシステムで、ファイルシステムに不正なスーパーブロックが含まれている場合、fsck は、fsck セッションを取り消すための次のようなプロンプトを表示します。

CANCEL FILESYSTEM CHECK?

• ファイルシステムが newfs コマンドを使用して作成され、fsck がプライマリスーパーブロックのみが破損していることを報告する場合、fsck でスーパーブロックを復元することを検討してください。

  # fsck /dev/dsk/c1t2d0s0 ** /dev/rdsk/c1t2d0s0 BAD SUPERBLOCK AT BLOCK 16: BLOCK SIZE LARGER THAN MAXIMUM SUPPORTED LOOK FOR ALTERNATE SUPERBLOCKS WITH MKFS? no LOOK FOR ALTERNATE SUPERBLOCKS WITH NEWFS? yes FOUND ALTERNATE SUPERBLOCK 32 WITH NEWFS USE ALTERNATE SUPERBLOCK? yes FOUND ALTERNATE SUPERBLOCK AT 32 USING NEWFS If filesystem was created with manually-specified geometry, using auto-discovered superblock may result in irrecoverable damage to filesystem and user data. CANCEL FILESYSTEM CHECK? no ** Last Mounted on ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3a - Check Connectivity ** Phase 3b - Verify Shadows/ACLs ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cylinder Groups CORRECT GLOBAL SUMMARY SALVAGE? y UPDATE STANDARD SUPERBLOCK? y 81 files, 3609 used, 244678 free (6 frags, 30584 blocks, 0.0% fragmentation) ***** FILE SYSTEM WAS MODIFIED *****

• ファイルシステムが mkfs コマンドを使用して作成され、fsck がプライマリスーパーブロックのみが破損していることを報告する場合、fsck でスーパーブロックを復元することを検討してください。

  # fsck /dev/dsk/c1t2d0s0 ** /dev/rdsk/c1t2d0s0 BAD SUPERBLOCK AT BLOCK 16: BLOCK SIZE LARGER THAN MAXIMUM SUPPORTED LOOK FOR ALTERNATE SUPERBLOCKS WITH MKFS? yes FOUND ALTERNATE SUPERBLOCK 32 WITH MKFS USE ALTERNATE SUPERBLOCK? yes FOUND ALTERNATE SUPERBLOCK AT 32 USING MKFS If filesystem was created with manually-specified geometry, using auto-discovered superblock may result in irrecoverable damage to filesystem and user data. CANCEL FILESYSTEM CHECK? no ** Last Mounted on ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3a - Check Connectivity ** Phase 3b - Verify Shadows/ACLs ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cylinder Groups CORRECT GLOBAL SUMMARY SALVAGE? y UPDATE STANDARD SUPERBLOCK? y 81 files, 3609 used, 243605 free (117 frags, 30436 blocks, 0.0% fragmentation) ***** FILE SYSTEM WAS MODIFIED *****

次の例は、破損したスーパーブロックのシナリオで fsck の -y オプションを指定した場合に何が起こるかを示しています。fsck セッションが自動的に終了します。代替のスーパーブロックを使用してセッションを再実行するためのメッセージが表示されます。

# fsck -y /dev/dsk/c1t2d0s0
# 
** /dev/rdsk/c1t2d0s0
BAD SUPERBLOCK AT BLOCK 16: BLOCK SIZE LARGER THAN MAXIMUM SUPPORTED

LOOK FOR ALTERNATE SUPERBLOCKS WITH MKFS?  yes


LOOK FOR ALTERNATE SUPERBLOCKS WITH NEWFS?  yes

SEARCH FOR ALTERNATE SUPERBLOCKS FAILED.

USE GENERIC SUPERBLOCK FROM MKFS?  yes

CALCULATED GENERIC SUPERBLOCK WITH MKFS
If filesystem was created with manually-specified geometry, using
auto-discovered superblock may result in irrecoverable damage to
filesystem and user data.

CANCEL FILESYSTEM CHECK?  yes

Please verify that the indicated block contains a proper
superblock for the filesystem (see fsdb(1M)).

FSCK was running in YES mode.  If you wish to run in that mode using
the alternate superblock, run `fsck -y -o b=453920 /dev/rdsk/c1t2d0s0'.

次の fsck エラーメッセージのシナリオは、バックアップスーパーブロックの新しいプロンプトを示していますが、この例では、fsck の実行は取り消されていません。ファイルシステムがカスタマイズされたパラメータを使用して作成されている場合またはこのシステム上での fsck の実行に関する他の心配がある場合は、fsck セッションの取り消しが適切な応答です。

次のように、さまざまなスーパーブロックのエラー状況が斜体で表示されます。

# fsck /dev/rdsk/c0t1d0s0

** /dev/rdsk/c0t1d0s0

BAD SUPERBLOCK AT BLOCK 16: BLOCK SIZE LARGER THAN MAXIMUM SUPPORTED
BAD SUPERBLOCK AT BLOCK 16: NUMBER OF DATA BLOCKS OUT OF RANGE
BAD SUPERBLOCK AT BLOCK 16: INODES PER GROUP OUT OF RANGE
BAD SUPERBLOCK AT BLOCK 16: MAGIC NUMBER WRONG
BAD SUPERBLOCK AT BLOCK 16: BAD VALUES IN SUPER BLOCK
BAD SUPERBLOCK AT BLOCK 16: NCG OUT OF RANGE
BAD SUPERBLOCK AT BLOCK 16: CPG OUT OF RANGE
BAD SUPERBLOCK AT BLOCK 16: NCYL IS INCONSISTENT WITH NCG*CPG
BAD SUPERBLOCK AT BLOCK 16: SIZE OUT OF RANGE
BAD SUPERBLOCK AT BLOCK 16: NUMBER OF DIRECTORIES OUT OF RANGE
BAD SUPERBLOCK AT BLOCK 16: ROTATIONAL POSITION TABLE SIZE OUT OF RANGE
BAD SUPERBLOCK AT BLOCK 16: SIZE OF CYLINDER GROUP SUMMARY AREA WRONG
BAD SUPERBLOCK AT BLOCK 16: INOPB NONSENSICAL RELATIVE TO BSIZE

LOOK FOR ALTERNATE SUPERBLOCKS WITH MKFS? yes

FOUND ALTERNATE SUPERBLOCK 32 WITH MKFS

USE ALTERNATE SUPERBLOCK? yes

FOUND ALTERNATE SUPERBLOCK AT 32 USING MKFS
If filesystem was created with manually-specified geometry, using
auto-discovered superblock may result in irrecoverable damage to
filesystem and user data.

CANCEL FILESYSTEM CHECK? no

** Last Mounted on 
** Phase 1 - Check Blocks and Sizes
** Phase 2a - Check Duplicated Names
** Phase 2b - Check Pathnames
** Phase 3a - Check Connectivity
** Phase 3b - Verify Shadows/ACLs
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cylinder Groups

SALVAGE? yes


UPDATE STANDARD SUPERBLOCK? yes

82 files, 3649 used, 244894 free (6 frags, 30611 blocks, 0.0% 
fragmentation)

***** FILE SYSTEM WAS MODIFIED *****

fsck による再実行が必要なタイミングの報告

fsck によって再実行が必要なタイミングの報告が改善されるので、特に実行に時間がかかる大きなファイルシステムの場合などに、このコマンドを何度も実行するための時間が節約され、実行する必要性も少なくなります。

次の新しいメッセージは、エラーシナリオの最後に fsck ユーティリティーを再実行するように要求します。

***** PLEASE RERUN FSCK *****

または

Please rerun fsck(1M) to correct this.

これらの新しいプロンプトは、 fsck を再実行すべきかどうかの判断が難しいという以前の問題を解決します。

上のメッセージのように fsck の再実行を要求されない場合は、次のようなメッセージが表示されても fsck を再実行する必要はありません。

***** FILE SYSTEM WAS MODIFIED *****

ただし、このメッセージのあとに fsck を再実行してもファイルシステムは損傷しません。このメッセージは、fsck の修正処置に関する情報を示すだけのものです。

拡張属性に関連する新しい fsck メッセージ

拡張属性を含むファイルを報告および修復する新しい fsck メッセージが用意されています。次に例を示します。

BAD ATTRIBUTE REFERENCE TO I=1 FROM I=96

Attribute directory I=97 not attached to file I=96
  I=96  OWNER=root MODE=40755
SIZE=512 MTIME=Jul 12 10:55:10 2010
DIR= <xattr> 

FIX?  yes

ZERO LENGTH ATTR DIR I=12  OWNER=root MODE=160755
SIZE=0 MTIME=Jul 12 10:56:10 2010
CLEAR?  yes

File should BE marked as extended attribute
  I=22  OWNER=root MODE=100644
SIZE=0 MTIME=Jul 12 10:57:10 2010
FILE=  <xattr>

FIX?  yes

UNREF ATTR DIR  I=106  OWNER=root MODE=160755
SIZE=512 MTIME=Jul 12 10:58:10 2010
RECONNECT?  yes

File I=107 should NOT be marked as extended attribute
  I=107  OWNER=root MODE=100644
SIZE=0 MTIME=Jul 12 10:59:10 2010
FILE=?/attfsdir-7-att

FIX?  yes
DIR I=106 CONNECTED.

重複するブロックまたはフラグメントの処理の改善

fsck エラーメッセージは、ブロック、フラグメント、または LFN に関する情報を報告するようになりました。LFN は、ファイルの先頭からの論理フラグメント番号です。たとえば、次のような出力が表示されます。

** Phase 1 - Check Blocks and Sizes
FRAGMENT 784 DUP I=38 LFN 0
FRAGMENT 785 DUP I=38 LFN 1
FRAGMENT 786 DUP I=38 LFN 2
.
.
.

fsck はオブジェクトをフラグメントとして処理しますが、以前の Solaris リリースでは、オブジェクト情報をブロックとして報告するだけでした。現在は、フラグメントとして正しく報告します。

fsck が重複するブロックまたはフラグメントに関連するエラーを検出した場合、fsck は、fsck の出力の最後にクリアされないファイルを表示します。たとえば、次のような出力が表示されます。

LIST REMAINING DUPS?  yes

Some blocks that were found to be in multiple files are still
assigned to file(s).
Fragments sorted by inode and logical offsets:
Inode 38:
  Logical Offset  0x00000000               Physical Fragment  784
  Logical Offset  0x00000800               Physical Fragment  786
  Logical Offset  0x00001000               Physical Fragment  788
  Logical Offset  0x00001800               Physical Fragment  790

この例では、そのあとで、find -i inode-number コマンドを使用して i ノード 38 を識別します。

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

ファイルシステム管理の手順については、次を参照してください。

ファイルシステムの概要

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

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

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

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

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

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

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

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

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

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

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

• 仮想ファイルシステム

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

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

「ディスクベースのファイルシステム」は、ハードディスク、DVD、フロッピーディスクなどの物理メディアに格納されます。ディスクベースのファイルシステムは、さまざまな形式で作成できます。次の表で、作成できる形式について説明します。

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

• UFS とハードディスク

• HSFS と CD-ROM

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

• UDF と DVD

ただし、これらの対応関係は制限的なものではありません。たとえば、CD-ROM やフロッピーディスクにも、UFS ファイルシステムを格納できます。

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

リムーバブルメディア上で UDFS ファイルシステムを作成する方法については、「リムーバブルメディア上にファイルシステムを作成する方法」を参照してください。

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) へのディスクアットワンス (Disk At Once) 記録、およびインクリメンタル記録

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

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

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

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

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

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

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

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

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

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

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

仮想ファイルシステム

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

CacheFS ファイルシステム

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

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

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

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

NFS Version 4 と CacheFS の互換性の問題

CacheFS クライアントと CacheFS サーバーの両方で NFS version 4 が実行されている場合、ファイルはフロントファイルシステムにキャッシュされません。すべてのファイルアクセスは、バックファイルシステムから提供されます。また、ファイルはフロントファイルシステムにキャッシュされていないため、フロントファイルシステムに反映する CacheFS 固有のマウントオプションは無視されます。CacheFS 固有のマウントオプションはバックファイルシステムに適用しません。

初めてシステムを NFS version 4 に構成すると、キャッシュが動作しないことを示す警告がコンソールに表示されます。

以前の Solaris リリースのように CacheFS マウントを実装する場合は、CacheFS mount コマンドで NFS version 3 を指定してください。次に例を示します。

mount -F cachefs -o backfstype=nfs,cachedir=/local/mycache,vers=3 
starbug:/docs /docs

一時ファイルシステム

一時ファイルシステム (TMPFS) は、ファイルシステムの読み取りと書き込みにローカルメモリーを使用します。通常、ファイルシステムの読み取りと書き込みには、UFS ファイルシステムよりもメモリーを使用したほうが効率的です。TMPFS を使用すると、ローカルディスク上で、あるいはネットワーク経由で一時ファイルの読み書きを行う際のオーバヘッドを軽減でき、システムパフォーマンスを改善できます。一時ファイルは、たとえば、プログラムのコンパイル時に作成されます。OS は、一時ファイルを操作しているとき、多くのディスク処理またはネットワーク処理を行います。TMPFS を使ってこれらの一時ファイルを管理することで、それらの作成、操作、および削除の効率を大幅に向上できます。

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

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

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

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

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

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

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

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

LOFS ファイルシステムを作成する手順については、第 17 章ZFS、UFS、TMPFS、LOFS ファイルシステムの作成 (手順)を参照してください。

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

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

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

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

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

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

libc_hwcap

x86 システムでのマウント出力には、libc のハードウェア最適化の実装である、 libc_hwcap ライブラリのループバックマウントが含まれる場合があります。この libc の実装は、32 ビットアプリケーションのパフォーマンスを最適化するためのものです。

このループバックマウントは、管理の必要がなく、ディスク容量を消費しません。

拡張ファイル属性

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

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

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

$ runat filea cp /tmp/attrdata attr.1

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

$ runat filea ls -l

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

属性認識オプションの追加により、多くの Solaris ファイルシステムコマンドがファイルシステム属性をサポートするようになりました。属性認識オプションを使って、ファイル属性を照会したり、コピーしたり、検索したりできます。詳細は、各ファイルシステムコマンドのマニュアルページを参照してください。

スワップ空間

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

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

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

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

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

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

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

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

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

汎用ファイルシステムコマンドと専用ファイルシステムコマンドのマニュアルページ

汎用コマンドと専用コマンドについては、『SunOS リファレンスマニュアル 1M : システム管理コマンド』を参照してください。 ファイルシステムの汎用コマンドのマニュアルページには、汎用コマンドオプションに関する情報だけが記載されています 。専用コマンドのマニュアルページには、該当するファイルシステムのオプション情報が記載されています。特定のファイルシステムのマニュアルページを見つけるには、汎用コマンド名の末尾にアンダースコアとファイルシステムタイプの略称を追加してください。

たとえば、UFS ファイルシステムのマウントについてのマニュアルページを参照するには、次のように入力します。

$ man mount_ufs

たとえば、ZFS ファイルシステムのマウントについてのマニュアルページを参照するには、次のように入力します。

$ man zfs

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

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

Solaris のファイルシステムおよびディレクトリの内容については、filesystem(5) のマニュアルページを参照してください。

次の表で、デフォルトの Solaris ファイルシステムの概要について説明します。

システムを動作させるには、ルート (/) と /usr のファイルシステムが必要です。mount など、/usr ファイルシステム内のもっとも基本的なコマンドの一部は、ルート (/) ファイルシステムにも含まれています。したがって、これらのコマンドは、システムのブート時やシングルユーザーモードでの使用時のほか、/usr がマウントされていない場合でも使用可能です。ルート (/) および /usr ファイルシステムのデフォルトディレクトリについては、第 22 章UFS ファイルシステム (参照情報)を参照してください。

UFS ファイルシステム

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

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

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

• 「64 ビット: マルチテラバイトの UFS ファイルシステムのサポート」

• 「UFS ロギング」

• 「UFS スナップショット」

• 「UFS 直接入出力」

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

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

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

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

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

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

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

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

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

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

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

この 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: 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 ノードとフラグメントの密度が設定されます。

32 ビットのカーネルを実行しているシステムで 1T バイト未満の UFS ファイルシステムを作成するときに、newfs -T オプションを使用すると、最終的に 64 ビットのカーネルでこのシステムを起動するときに、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 ロギングは、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 コマンドを使用して、ファイルシステムの読み取り専用のスナップショットを作成できます。「スナップショット」は、バックアップ操作のためのファイルシステムの一時イメージです。

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

UFS 直接入出力

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

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

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

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

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

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

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

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

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

図 16–1 UFS ルート (/) ファイルシステムの例

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

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

• マウントポイントを作成したら、mount コマンドを使ってファイルシステムをマウントします。このコマンドを実行すると、/opt/unbundled 内のすべてのファイルおよびディレクトリが使用可能になります (次の図を参照)。

図 16–2 UFS ファイルシステムのマウント

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

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

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

$ more /etc/mnttab
rpool/ROOT/zfs509BE             /       zfs     dev=4010002     0
/devices        /devices        devfs   dev=5000000     1235087509
ctfs    /system/contract        ctfs    dev=5040001     1235087509
proc    /proc   proc    dev=5080000     1235087509
mnttab  /etc/mnttab     mntfs   dev=50c0001     1235087509
swap    /etc/svc/volatile       tmpfs   xattr,dev=5100001       1235087510
objfs   /system/object  objfs   dev=5140001     1235087510
sharefs /etc/dfs/sharetab       sharefs dev=5180001     1235087510
fd      /dev/fd fd      rw,dev=52c0001  1235087527
swap    /tmp    tmpfs   xattr,dev=5100002       1235087543
swap    /var/run        tmpfs   xattr,dev=5100003       1235087543
rpool/export    /export zfs     rw,devices,setuid,nonbmand,exec,xattr,...
rpool/export/home       /export/home    zfs     rw,devices,setuid,nonbmand,exec,...
rpool   /rpool  zfs     rw,devices,setuid,nonbmand,exec,xattr,atime,dev=4010005 1235087656

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

必要に応じて毎回ファイルシステムを手動でマウントしていては、非常に効率が悪く、エラーも発生しやすくなります。これらの問題を解決するために、virtual file system table (/etc/vfstab ファイル) にファイルシステムのリストとそのマウント方法を指定できます。

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

• システムブート時に自動的にマウントするファイルシステムを指定できます。ZFS ファイルシステムは、ブート時に SMF サービスにより自動的にマウントされます。vfstab ファイル内のエントリは使用されません。

• マウントポイント名だけを使って、ファイルシステムをマウントできます。/etc/vfstab ファイルには、マウントポイントと実際のデバイススライス名のマッピング情報が含まれています。

システムをインストールすると、インストール時の選択内容に基づいて、デフォルトの /etc/vfstab ファイルが作成されます。ただし、システムの /etc/vfstab ファイルはいつでも編集できます。エントリを追加するには、次のような情報を指定する必要があります。

• ファイルシステムが配置されるデバイス

• ファイルシステムのマウントポイント

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

• システムのブート時に、mountall コマンドを使ってファイルシステムを自動的にマウントするかどうか

• マウントオプション

次に、UFS ルートファイルシステムが動作するシステムの /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
#
fd                 -                  /dev/fd          fd      -       no      -
/proc              -                  /proc            proc    -       no      -
/dev/dsk/c0t0d0s1  -                  -                swap    -       no      -
/dev/dsk/c0t0d0s0  /dev/rdsk/c0t0d0s0 /                ufs     1       no      -
/dev/dsk/c0t0d0s6  /dev/rdsk/c0t0d0s6 /usr             ufs     1       no      -
/dev/dsk/c0t0d0s7  /dev/rdsk/c0t0d0s7 /export/home     ufs     2       yes     -
/dev/dsk/c0t0d0s5  /dev/rdsk/c0t0d0s5 /opt             ufs     2       yes     -
/devices           -                  /devices         devfs   -       no      -
sharefs            -                  /etc/dfs/sharetabsharefs -       no      -
ctfs               -                  /system/contract ctfs    -       no      -
objfs              -                  /system/object   objfs   -       no      -
swap               -                  /tmp             tmpfs   -       yes     -

この例では、ルート (/) や /usr の場合、mount at boot フィールドの値は no になります。これらのファイルシステムは、ブートシーケンスの一環として、mountall コマンドの実行前にカーネルによってマウントされます。

次に、ZFS ルートファイルシステムが動作するシステムの vfstab の例を示します。

# cat /etc/vfstab
#device         device          mount           FS      fsck    mount   mount
#to mount       to fsck         point           type    pass    at boot options
#
fd              -               /dev/fd         fd      -       no      -
/proc           -               /proc           proc    -       no      -
/dev/zvol/dsk/rpool/swap -      -               swap    -       no      -
/devices        -              /devices         devfs   -       no      -
sharefs         -              /etc/dfs/sharetabsharefs -       no      -
ctfs            -              /system/contract ctfs    -       no      -
objfs           -              /system/object   objfs   -       no      -
swap            -              /tmp             tmpfs   -       yes     -

ZFS ファイルシステムは、ブート時に SMF サービスにより自動的にマウントされます。レガシーのマウント機能を使用し、vfstab に従って ZFS ファイルシステムをマウントできます。詳細については、『Oracle Solaris ZFS 管理ガイド』を参照してください。

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

NFS 環境

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

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

詳細については、『Solaris のシステム管理 (ネットワークサービス)』の第 4 章「ネットワークファイルシステムの管理 (概要)」を参照してください。

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

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

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

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

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

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

NFS Version 4

Solaris リリースには、Sun の実装の NFS version 4 分散ファイルアクセスプロトコルが含まれています。

NFS version 4 では、ファイルアクセス、ファイルロック、およびマウントプロトコルが 1 つのプロトコルに統合されるので、ファイアウォールの通過が容易になり、セキュリティーが向上します。Solaris の NFS version 4 実装は、SEAM としても知られている Kerberos V5 と完全に統合されていますので、認証、整合性、およびプライバシの機能を備えています。NFS version 4 を使用して、クライアントとサーバーとの間で使用するセキュリティーの種類の交渉を行うこともできます。NFS version 4 を実装しているサーバーは、さまざまなセキュリティー種類とファイルシステムに対応できます。

NFS Version 4 の機能については、『Solaris のシステム管理 (ネットワークサービス)』の「NFS サービスの新機能」を参照してください。

自動マウント (autofs)

NFS ファイルシステムリソースをマウントするには、「自動マウント」(autofs) というクライアント側のサービスを使用します。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) のマニュアルページを参照してください。

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

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

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

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

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

次の例は、fstyp コマンドを使ってファイルシステムのタイプを確認しています。

# fstyp /dev/rdsk/c0t0d0s0
zfs