Advanced File System (AdvFS) は HP Tru64 UNIX オペレーティング・システムの標準ファイル・システムです。 この章では,次のトピックについて説明します。
AdvFS と UFS の比較 (1.1 節)
ライセンス登録 (1.2 節)
AdvFS ファイル・システムの設計と構成要素 (1.3 節)
ファイル・システムの構成 (1.4 節)
AdvFS の各種ストレージ (1.5 節)
AdvFS ファイル・システムは,従来の UNIX ファイル・システム (UFS) とは異なります。
AdvFS では,システムをシャットダウンすることなく,いつでもシステム構成を変更できます。
AdvFS は,AdvFS Utilities とともに使用して,マルチボリューム・ファイル・システムをサポートするので,システム条件の変化に応じて,ストレージを柔軟に追加/削除することが可能です。
これに加えて, これに比べるとUFS モデルは柔軟性を欠きます。
各ディスク,あるいはディスク・パーティションに 1 つのファイル・システムがあります。
UFS のディレクトリ階層構造は,物理ストレージ層に密接に結び付いています。
このため,ファイル・システムの空き容量が足りなくなっても,ファイルの絶対パス名を変更しない限り他のディスクへファイルを移動することはできません。
論理ディレクトリをディレクトリ・サブツリーに分けてサブツリーを別のディスクにマッピングする作業は,慎重に考えなければなりません。
周到に計画しても,UFS モデルではディレクトリ構造の調整には限界があります。
ユーザ側の視点では,AdvFS は従来の UNIX のファイル・システムとほとんど変わりありません。
すなわち,各ユーザは
システム管理者は,AdvFS システムをオンライン状態に維持したまま,ファイル・システムのバックアップや再構成,およびチューニングを行うことができます。
各ユーザは,必要なファイルを誤って削除してしまった場合でも,定義済みのゴミ箱ディレクトリや AdvFS ファイルセット・クローンから,システム管理者の手を借りることなくファイルを復元できます。
AdvFS は Tru64 UNIX オペレーティング・システムの標準ファイル・システムですが,その機能を拡張する AdvFS Utilities は別ライセンスで提供されています。
したがって,AdvFS Utilities を使用するには,事前にライセンス PAK ( AdvFS ファイル・システムは,ディレクトリ階層レイヤと物理ストレージ・レイヤの 2 種類の階層で構成されます。
ディレクトリ階層レイヤは,ファイル・ネーミング・スキームや,ファイルの作成およびオープン,ファイルの読み書きなどの POSIX に準拠した機能を実現します。
物理ストレージ・レイヤは,先書きログ,キャッシュ機能,ファイル割り当て,物理ディスク入出力機能を実現します。
このように独立したファイル・システム構造により,ディレクトリ階層レイヤと物理ストレージ・レイヤを別々に管理することができます。
ファイルのパス名を変えずに,定義された複数のディスク・ボリューム間でファイルを移動できます。
パス名は変わらないため,物理レベルでのこの操作はエンド・ユーザには全く影響を与えません。
AdvFS は,クラスタ構成のファイル・システムです。
クラスタの動作もまた,エンド・ユーザには全く影響を与えません。
1 つのクラスタ上で動作する AdvFS は,エンド・ユーザにとってはほとんど例外なく,1 つのノード上で動作するのと全く変わらないように見えます。
AdvFS では,
AdvFS が使用できる各種ストレージについては,1.5 節
を参照してください。
ファイルセットとは,従来の UNIX ファイル・システムの論理構造に従ったディレクトリ名とファイル名の階層構造であり,これがシステムにマウントする対象になります。
AdvFS は従来のファイル・システムより優れており,ドメインと呼ばれる共通のストレージ・プールを共用する複数のファイルセットを作成することができます。
AdvFS ファイル・システムの構成についての詳細は,1.4.1 項
を参照してください。
ファイルセットの操作についての詳細は,2.4 節
を参照してください。
ドメインは物理ストレージ層を表し,ディレクトリ構造とは別に管理されます。
ドメインでは,ディレクトリ構造に影響を与えないでボリュームの追加/削除を行うことができます。
ドメイン管理についての詳細は,2.3 節を参照してください。
AdvFS ファイル・システムは, ドメインを作成すると,AdvFS によって対応するトランザクション・ログ・ファイルが 1 つ作成されます。
クラッシュから回復する際,AdvFS はトランザクション・ログ・ファイルを読み取り,ファイル・システム・トランザクションの状態を確認します。
完了しているトランザクションはすべてディスクに書き込まれ,完了していないトランザクションは実行が取り消されます。
回復速度を左右するのは,ファイル・システム内のデータ量ではなく,ディスクに書き込まれていないトランザクション・ログのレコードの数です。
回復は通常,数秒で終わります。
従来の UNIX ファイル・システムでは, 省略時の設定では,ファイル・システム構造のみがロギングされます。
ただし,ファイル・データをロギングするように選択し,システムがストレージに書き込みを行う方法を変更することもできます (5.5 節を参照)。
データ・ロギングを有効にしておくと,システム・クラッシュが発生しても内部的にファイルの整合性が維持されますが,システムの性能が低下する可能性があります。
ファイルは静的なものではなく,時間の経過とともに必要な容量が変化します。
スペースを過度に割り当てず,ディスク上で連続的にファイルを配置できるように,AdvFS は独自のファイル・ストレージ割り当てスキームを使用します。
ファイル・ストレージ割り当てに際しては,以下のような機能が使用されます。
エクステント
エクステントの数が少ないほどファイル I/O は効率的に行われます。
ファイルが多数の小さなエクステントから構成される場合は,同様のサイズで大きないくつかのエクステントからなるファイルよりも,ファイルの読み取りおよび書き込みのための I/O 処理に時間がかかることになります。
ファイル・システムには動的な性質があるため,ファイル・ストレージの割り当てが常に連続するページになり,大きなエクステントができるとは限りません。
次のような要因が,ストレージの割り当てに影響を与えます。
ディスク断片化 (ディスク・フラグメンテーション)
ディスクが過度に断片化すると,多数の小さな空きスペースが存在することになります。
この場合,AdvFS は連続するページを利用できないため,データを非連続の物理ページに書き込みます。
その結果,ファイルは多数のエクステントに細分化されることになります。
複数のユーザ
システム上に多くのユーザがいる場合は,必要なディスク容量が増加し,ファイルに対して連続領域を割り当てるのが難しくなります。
多数のエクステントから構成されるファイルがドメインに存在する場合には, プリアロケーション (事前割り当て)
ファイルが拡張されるたびに,AdvFS は,ファイル・サイズの 1/4 (最高 16 ページまで) を事前に割り当てて,ファイルにページを追加します。
余分に割り当てられた事前割り当てスペースは,ファイルのクローズ時に解放されます。
マルチボリューム・ドメインでは,新しいファイルは各ボリュームに順番に割り当てられます。
86% 以上使用された (割り当てられた) ボリュームは,すべてのボリュームが 86% 以上使用された状態にならない限り,新しいファイルへの割り当てには使用されません。
既存のファイルにデータが追加されたときには,ボリュームが一杯にならない限り,ストレージはファイルが最初に割り当てられたボリューム上に割り当てられます。
フラグメント
AdvFS は,ページ単位でファイルをディスクに書き込みます。
最後のページの未使用領域が,割り当て済みスペースの 5 % 以上を浪費することになるファイルでは, スパース・ファイル
スパース・ファイルは,
core ファイルはスパース・ファイルです。
core ファイルは,情報が含まれていない大きな領域を持ち,データが存在しない場所にはディスク・ブロックは割り当てられていません。
また,クォータ・ファイルは,ユーザ ID によってインデックスされるためスパース・ファイルです。
各ユーザの ID が連続していない場合,クォータ・ファイルにはデータが存在しない部分が含まれる可能性があります。
一方,データベース・アプリケーションでは通常,データが存在しない場合でもファイル全体のストレージが確保されます。
一般に,データベース・アプリケーションは,データが存在しないページにゼロを書き込みます。
データベース・アプリケーションでは,データを順番に書き込むことによって,連続する多数のページを含み,かつエクステント数が少ないデータベース・ファイルを作成します。
ディスク・ストレージを持たないページも含めたスパース・ファイルの大きさを調べるには, 構成の計画段階で, 従来の UFS 構成と同じように,ドメインごとにパーティション (ボリューム) が 1 つで,各ドメインにはファイルセットが 1 つあるという形式で AdvFS を設定できます。
オプションの AdvFS Utilities を利用できる場合は,スペースが必要になった時点でボリュームを追加して (ボリュームが 1 つに制限されているローカルのルート・ファイル・システムを除く),既存のドメインのサイズを大きくすることができます。
その際,既存の構成を変更する必要はありません。
複数のファイルセットからなる 1 つのドメインを作成することもできますし,それぞれのファイルセットについてドメインを作成することもできます。
また,これら 2 つ方法を取り混ぜてシステムを構築することもできます。
AdvFS Utilities を利用できる場合,ドメインを複数のボリュームに分散させることもできます。
十分な数のドライブを利用できる場合,1 つのドメインに1 つのディスクを使用してください。
ドメインには,同じディスク上のいくつかのパーティション (たとえば, パーティションを異なるドメインに分割しないでください。
たとえば,パーティション
同じタイプおよび同じ速度のディスクを複数使用する場合には,一般的にこれらの各ディスクにドメインを分散させた方が,効率化を図ることができます。
たとえば,独立した 3 つのディスク・ボリュームを持つドメインは,1 つのディスク上に 3 つのパーティションを持つドメインよりも効率的です。
これは,後者の構成では,I/O パスが 1 つしかないためです。
複数のドメインを作成すると,物理リソースをより自由に制御できるようになります。
ドメインを,組織内で意味のあるまとまり,たとえば,特定のプロジェクト,ユーザのグループ,部門,または事業所ごとに使用するように作成することができます。
たとえばドメインを,組織内のエンジニアリング,財務,人事などの部門ごとに作成することができます。
データ管理アプリケーション・プログラミング・インタフェース (DMAPI) を使用可能にしたドメイン (付録 D) では,1 つのファイルセットしか使用できません。
表 1-1
に,各種構成の長所と短所を示します。
どのファイル・システムを使用しているかは,次の方法で調べることができます。
第 5 章
に,ファイル・システムを最適化する方法について詳しく説明しています。
『システムの構成とチューニング』 に,ファイル・システムの計画と構成についての詳細なガイドラインがあります。
グラフィカル・ユーザ・インタフェースを使って,ドメインを構成する方法は,付録 E
を参照してください。
ボリュームは,ブロック特殊デバイスとなるエンティティです。
1 つのディスク・パーティション,ディスク全体,LSM により作成されたボリュームの集合体,ハードウェア RAID,または SAN などがこのエンティティに相当します。
ボリュームはそれぞれ,1 つのドメインにしか割り当てできません。
そのドメインには, AdvFS のドメインのそれぞれのボリュームには, 次の表には,AdvFS ボリューム上にドメインを構成するさまざまな方法の長所と短所を示します。
ドメインを作成すると,AdvFS はそのドメインに関連付けられたブロック特殊デバイス名を用いて,ストレージを識別できるようになります。
ストレージには,直接接続されたディスク,ソフトウェア RAID ボリューム,ハードウェア RAID,および ストレージ・エリア・ネットワークなどを使用できます。
LSM,ハードウェア RAID,および SAN のボリュームを使用すると,高度なバックアップや動的ボリューム拡張などの機能を利用することができます。
LSM の詳細は,『Logical Storage Manager』 を参照してください。
ハードウェア RAID と SAN の各種製品については,http://h30097.www3.hp.com/storage/index.html
を参照してください。
mkdir
コマンドでディレクトリを作成し,cd
コマンドでディレクトリ間を移動し,ls
コマンドでディレクトリの内容のリストを表示することができます。
また,AdvFS の論理構造とクォータ管理,およびバックアップ機能は,従来のファイル・システムの設計に基づいています。
ただし,AdvFS では
newfs
,dump
,restore
,fsck
など,いくつかの標準的なコマンドがサポートされていないか,あるいは他のコマンドで置き換えられています。
AdvFS のコマンドとユーティリティ,および UFS のコマンドとの比較についての詳細は,付録 B
を参照してください。
1.2 ライセンス登録
1.3 ファイル・システムの構造
図 1-1: AdvFS ファイル・システムの構造
1.3.1 ファイルセット,ドメイン,およびボリューム
1.3.2 トランザクション・ログ・ファイル
fsck
ユーティリティを使用してシステム障害から回復します。
fsck
ユーティリティでは,大容量のファイル・システムの検査と修復には数時間を要する場合があります。
1.3.3 ファイル・ストレージの割り当て
vfast
ユーティリティを使用してファイルの配置を最適化することができます (5.8 節を参照)。
ftruncate
(2)lseek
(2)write
(1)ls
コマンドを-lオプションを指定して使用します。
ls
コマンドを-sオプションを指定して使用すると,実際にファイルが使用しているストレージの総量が表示されます。
6.4.1 項に,ディスク使用状況を表示する,何通りかの方法を詳しく説明していますので,参照してください。
/
(ルート),/usr
,および
/var
ファイル・システムを AdvFS に設定することを検討してください。
ルートと
/usr
に AdvFS を使用すれば,構成の柔軟性が高まるとともに,システム障害時のダウン時間を大幅に短縮させることができます。
1.4.1 ドメインとファイルセットの構成
a
,b
,g
,h
など) を追加するよりも,1 つのパーティション (通常パーティション
c
) を追加することをお勧めします。
a
をあるドメインに追加し,パーティション
b
を別のドメインに追加しないでください。
表 1-1: ドメインとファイルセットの各種構成の比較
構成
長所
短所
ディスク全体を 1 つのドメインに使用。
小さなパーティションが複数の物理デバイスに分散していない。
効率がよい。
デバイスの I/O ストリームは共有されない。
大きなボリューム上に小さなドメインがある場合,スペースを無駄に使う。
ドメインが,1 つのボリュームにではなく複数のボリュームにわたって構成されている (Advanced Utilities が必要)。
I/O 負荷を分散。
スループットが向上。
ボリュームの 1 つに障害が発生すると,ドメイン全体にアクセスできなくなる。
同じ数のボリューム上に,1 つの大きなドメインではなく,小さなドメインが複数存在。
復旧が速い。
スループットが向上。
いくつかの管理作業を省略可能。
管理上のオーバヘッドが増える可能性がある。
ドメイン上に 1 つの大きなファイルセットではなく,多数のファイルセットが存在。
個々のファイルセットに対して限界値を設けることができ,資源をより細かに制御できる。
管理上のオーバヘッドが増える。
あるユーティリティを実行するのにすべてのファイルセットをマウントしなければならない場合がある。
高速ボリュームまたは輻輳のないボリューム上にトランザクション・ログがある。
ログにより I/O のボトルネックが発生しない。
ハードウェアのコストがかかる。
ルート・ファイルセットを AdvFS として構成。
システム・クラッシュの後の復旧が速い。
なし
showfsets
を使用して,ドメイン内のファイルセットの数とそれぞれのファイルセットの大きさを表示します。
showfile
コマンドを使用して,ファイルが存在するボリュームを調べます。
頻繁に使用する複数のファイルが,同じボリューム上に存在しないようにします。
1.4.2 ボリュームの構成
表 1-2: AdvFS ボリュームの各種構成の比較
構成
長所
短所
ボリュームがディスク・パーティションに相当する。
ディスクの小さい領域も使用できる。
サイズの制約。
他のパーティションとの I/O の競合が発生。
ボリュームが 1 つのディスクに相当する。
1 つのパーティションを使用するよりも効率的。
サイズの制約
ボリュームが 1 つの RAID ボリューム (LSM かハードウェア) または SAN に相当する。
性能と信頼性が向上する。
利用可能な容量が増える。
コストがかかる。
LSM ライセンスか,追加のハードウェアが必要。