この章では,起こり得る問題からの回復手順と,問題の修復または回避手順について説明します。 この章で取り上げるトピックは次のとおりです。
ユーザ・ファイルの復旧について,あらかじめ計画を立てておかない限り,削除されたファイルを復旧する簡便な手段はありません。 次の 3 つの方法のいずれかで,削除されたファイルにアクセスできます。
ディレクトリのバックアップ (vdump
コマンド) とファイルのリストア (vrestore
コマンド)。
バックアップ・データが保存されているディレクトリへの書き込み許可が必要です。
詳細については,第 4 章を参照してください。
ファイルセット・クローンの設定。 その日に変更のあったファイルにアクセスするためには,ファイルセット・クローンをその日のうちに作成します。 クローンを作成するには,ルート特権が必要です。 詳細については,2.4.10 項を参照してください。
ディレクトリのゴミ箱の設定。 この機能はユーザが自由に設定できます。 ルート特権は必要ありません。 詳細については,2.6 節を参照してください。
ファイルが削除されたときに,バックアップもゴミ箱もクローンもない場合,ファイルを復旧する手段はありません。
しかし,ファイルが壊れている場合,/sbin/advfs/salvage
コマンドを実行することで内容を部分的に復旧できる場合があります。
手順については,6.2.6 項を参照してください。
6.2 一般的な復旧手順
次の復旧手順は,すべてのドメイン・パニックと多くのシステム・クラッシュに適用できます。 クラッシュが 1 つのドメインによって発生しているならば,次に示す手順によって,そのドメインのファイルセットに再びアクセスできるようになります。 必要なステップまでを行なってください。 すべてのステップを行なう必要は必ずしもありません。 ルート・ドメインを復旧する場合は,6.3.4 項を参照してください。
sys_check
ユーティリティに
-escalate
オプションを指定して実行し,技術サポート担当者に報告するエスカレーション・ファイルを作成します。
このユーティリティは,収集したデータを/TMPDIR/escalate.tar
ファイルとして出力します。
sys_check
コマンドは,SysMan Menuの「サポートとサービス -- エスカレーション・レポートの作成」ユーティリティ (付録 Aを参照)を使用をして実行するか,コマンド行から実行します。
sys_check
ユーティリティを実行するには,root ユーザまたは適切な特権が必要です。
詳細については,
sys_check
(8)6.2.2 システム・メタデータのコピーの保存
ドメインが,破損しているか,何らかの問題の原因になっていると思われる場合は,/sbin/advfs/savemeta
コマンドを実行します。
これにより,サポート担当者が調査するための,ドメインのメタデータのコピーが保存されます。
savemeta
コマンドに
-f
オプションを指定して実行すると,それぞれのファイルセットのフラグ・ファイルから構造情報を保存します。
このユーティリティは,ログ・ファイル,ビットファイル・メタデータ・テーブル,各ボリュームのストレージ・ビットマップ,ドメインのルート・タグ・ファイル,およびファイルセット・タグ・ファイルを保存します。
たとえば,domain_1
のメタデータを/tmp/saved_domain_1
に保存するには,次のコマンドを入力します。
# /sbin/advfs/savemeta domain_1 /tmp/saved_domain_1
ファイルセット
fsetN
のフラグ・ファイルから,メタデータを
/tmp/saved_fsetN
に保存するには,次のコマンドを入力します。
# /sbin/advfs/savemeta domain_1 -f fsetN /tmp/saved_fsetN
このコマンドを実行するには,root ユーザの特権が必要です。
詳細については,
savemeta
(8)6.2.3 ダメージを受けていないファイルの保存
影響のあるドメインのできるだけ多くのファイルセットをバックアップすることをお勧めします。
バックアップ方式については,第 4 章
を参照してください。
ドメインを再作成するのに,このバックアップ,他の最新のバックアップ,および復旧ユーティリティ (/sbin/advfs/verify
,/sbin/advfs/fixfdmn
,および
/sbin/advfs/salvage
) の出力を使用することができます。
6.2.4 ファイル・システムの整合性の確認
メタデータの整合性を維持するため,/sbin/advfs/verify
コマンドを実行して,ファイル・システムの構造を確認します。
verify
コマンドを実行すると,ビットファイル・メタデータ・テーブル (BMT),ストレージ・ビットマップ,タグ・ディレクトリ,フラグ・ファイルなどのディスク構造がファイルセットごとにチェックされ,ディレクトリ構造が正しいかどうか,すべてのディレクトリ・エントリが有効なファイルを参照しているかどうか,およびすべてのファイルにディレクトリ・エントリがあるかどうかを確認できます。
このコマンドを実行するには,root 権限が必要です。
verify
コマンドは,次のような場合に実行します。
問題が明白な場合 (破損,ドメイン・パニック,データの喪失,I/O エラー)
アップデート・インストレーションの前
ファイルにアクセスしない状態が 3 〜 6 か月以上続いた後,ドメイン内の全ファイルにアクセスするユーティリティ (balance
,defragment
,migrate
,quotacheck
,repquota
,rmfset
,rmvol
,またはvdump
など) を実行する前
SysMan Menuの「AdvFS ドメインの管理」ユーティリティ (付録 A参照) を使用するか,コマンド行で次のように
verify
コマンドを実行します。
/sbin/advfs/verify
domain_name
verify
コマンドは,ファイルセットを特殊なディレクトリにマウントします。
ドメイン障害のために
verify
コマンドでファイルセットをマウントできない場合には,最後の手段として
verify
コマンドに
-F
オプションを指定して実行します。
-F
オプションを指定した場合,verify
コマンドは
mount
コマンドの
-d
オプションを使用してファイルセットをマウントします。
つまり,AdvFS は当該ドメインを復旧せずに,トランザクション・ログ・ファイルを初期化します。
注意
verify
コマンドに -F オプションを指定しすると,直前の不完全な動作に対するドメインの復旧処理が行われないため,データが破損するおそれがあります。
状況によっては,verify
コマンドでファイルセットがアンマウントされないことがあります。
その場合には,ファイルセットを手動でアンマウントし,/etc/fdmns
ファイル内に作成されているマウント・ポイントを削除する必要があります。
ファイル数が数百万にも及ぶマシンで
verify
コマンドを正常に動作させるためには,同コマンドに十分なスワップ領域を割り当てる必要があります。
verify
ユーティリティに必要なメモリ・サイズがカーネル変数の
proc/max_per_proc_data_size
プロセス変数の値を超過している場合には,このユーティリティは正常に終了しません。
この問題に対処するには,ドメイン・サイズの 10% までスワップ領域の割り当てを増やして
verify
コマンドを実行します。
詳細については,
swapon
(8)
verify
コマンドが成功した場合,クラッシュをまねいたイベントが繰り返されたときのために,ドメインをバックアップすることをお勧めします。
setx
と
sety
という 2 つのファイルセットを含むドメイン
domainx
を,verify
コマンドでチェックしたときの出力例を次に示します。
# /sbin/advfs/verify domainx +++Domain verification+++ Domain Id 2f03b70a.000f1db0 Checking disks ... Checking storage allocated on disk /dev/disk/dsk10g Checking storage allocated on disk /dev/disk/dsk10a Checking mcell list ... Checking mcell position field ... Checking tag directories ... +++ Fileset verification +++ +++ Fileset setx +++ Checking frag file headers ... Checking frag file type lists ... Scanning directories and files ... 1100 Scanning tags ... 1100 Searching for lost files ... 1100 +++ Fileset sety +++ Checking frag file headers ... Checking frag file type lists ... Scanning directories and files ... 5100 Scanning tags ... 5100 Searching for lost files ... 5100
この例では,ドメインに問題は見つかっていませんので,復旧手順を行なう必要はありません。
詳細については,
verify
(8)6.2.5 fixfdm ユーティリティを使用したディスク上のメタデータ損傷への対処
/sbin/advfs/fixfdmn
ユーティリティは,壊れたメタデータを修復することによってドメインを使用可能な (マウント可能な) 状態にすることを主な目的として設計されています。
次の状況で,ファイルセットをアンマウントし,このユーティリティを実行します。
6.2.4 項で説明した/sbin/advfs/verify
ユーティリティが動作しない場合。
verify
ユーティリティがディスク上の (メタデータ) 損傷を検出した場合。
ドメインに,マウントすると必ずドメイン・パニックを引き起こすファイルセットがあり,verify
コマンドに
-F
オプションを指定して実行したくない場合。
fixfdmn
ユーティリティはメタデータを走査し,壊れたメタデータを検索して,利用可能なメタデータが十分ある場合,これを修復しようとします。
利用可能なメタデータが十分にない場合は,できるだけ壊れたメタデータを移動または削除し,さらに必要に応じてファイルを削除することによって損傷部分を取り除こうとします。
このユーティリティは,ファイルの内容のチェックと修正は行いません。
ファイルからデータを復元することが急務である場合や,ドメインの大きな部分が壊れてしまった場合は,/sbin/advfs/salvage
ユーティリティの使用法について,6.2.6 項
を参照してください。
fixfdmn
ユーティリティを実行した後は,ファイルセットを再度マウントします。
ファイルセットを再マウントできたら,ファイルが削除されていないかチェックします。
削除されている場合,バックアップからリストアします。
ファイルセットをマウントできない場合,fixfdmn
コマンドに
-u
オプションを指定してプロセスを取り消し,salvage
コマンドで変更のないデータにアクセスできるようにします。
fixfdmn
コマンドが成功した場合,クラッシュをまねくイベントが繰り返されたときのために,ドメインをバックアップすることをお勧めします。
fixfdmn
コマンドが成功すれば,さらに回復手順を実行する必要はありません。
fixfdmn
コマンドに
-n
オプションを指定すると,ドメインをチェックだけして,修復は行なわれません。
システム・メッセージを出力だけし,変更をディスクに書き込みません。
6.2.6 損傷したドメインからのファイル・データの救済
ドメインのファイルを復旧するには,/sbin/advfs/salvage
ユーティリティを使用します。
このコマンドは,壊れたドメインから救済可能なファイルを抽出し,復旧したファイルを置くためのファイルセットにそれらをコピーします。
ドメインの損傷の性質によっては,すべてのデータを救済できる場合もあれば,いくつかしか救済できない場合もあります。
/sbin/advfs/fixfdmn
コマンドを実行し,成功しなかった場合,salvage
コマンドを実行する前に,まず
fixfdmn
コマンドに
-u
オプションを指定して実行し,このユーティリティが行なった変更を元に戻す必要があります。
salvage
機能を使用するには,SysMan Menuの「AdvFS ドメインの管理」ユーティリティ (付録 Aを参照) を使用するか,コマンド行で次のように
salvage
コマンドを実行します。
/sbin/advfs/salvage
domain_name
fileset_name
復元されたデータのコピー先には,ディスクとテープのどちらでも使用できます。
復元できるデータの量は,ドメインの損傷の種類によって左右されます。
詳細については,
salvage
(8)
salvage
コマンドを実行しても,ドメインのすべてのデータを復旧できるという保証はありません。
ファイル,ディレクトリ,ファイル名,またはファイルの一部が失われる可能性もあります。
このユーティリティは,復元されたファイルの状態を記録したログ・ファイルを生成します。
-l
オプションを指定すると,このユーティリティが処理したすべてのファイルがログ・ファイルに記録されます。
salvage
コマンドは,復元したファイルを,ファイルセット名に基づいて付けられた名前のディレクトリに格納します。
salvage
コマンドはファイルセットごとにlost+found
ディレクトリを作成し,その中に親ディレクトリが見つからないファイルを格納します。
復元されたファイルセット・ディレクトリが配置されるディレクトリのパス名は明示的に指定できます。
このディレクトリを指定しない場合,salvage
コマンドは,復元したファイルセットを現在の作業ディレクトリの下に格納します。
-F tar
オプションを指定することによって,損傷のあるドメインから復元したデータを,tar
形式でテープに格納することも可能です。
6.2.6.1 ファイル・データの復元
最新のバックアップ・ソースがある場合,/sbin/advfs/salvage
ユーティリティに
-d
オプションを指定して,バックアップの日付以降に変更されたデータのみを復元することができます。
これによって
salvage
ユーティリティが処理しなければならないデータ量を軽減することができます。
バックアップ・ソースがない場合は,指定したドメインのすべてのファイルに対して,salvage
ユーティリティを実行します。
システムに,復旧するすべてのファイルを保持するスペースがない場合は,データをテープに復元し,その後に元のディスクの場所に読み込むことができます。
また,salvage
コマンドを
-F
オプションと
-f
オプションを指定して実行し,データを
tar
形式で復元することもできます。
この手順は,次のとおりです。
破損したドメインのすべてのファイルセットをアンマウントします。
救済するデータをテープに保存する場合,ローカル・ドライブにテープを装着します。 詳細については,『ハードウェア管理ガイド』を参照してください。
tar
形式でデータを救済しない場合は,復旧した情報を一時的に保持するドメインとファイルセットを作成し,ファイルセットをマウントします。
salvage
コマンドを実行します。
salvage.log
ファイルを調べ,すべての必要なファイルを復旧したかを確認します。
失われたファイルがある場合,バックアップ・ソースから,それらを探す必要があります。
ドメインとマウント・ポイント・ディレクトリを再度作成します。 ファイルセットを作成し,そこにマウントします。
バックアップからファイルをリストアします。
救済したファイルを,一時的ドメインまたは
tar
ファイルからリストアします。
次の例では,ドメインをディスクに救済しています。
壊れたドメインは
PERSONNEL
で,このドメインにはファイルセット
personnel_a-e
があり,/personnel_a-e
にマウントされています。
元のドメインは,ボリューム
/dev/disk/dsk12c
にあり,salvage
コマンドの出力は,/dev/disk/dsk3c
に置かれます。
バックアップ・テープ
/dev/tape/tape0
が利用できるので,損傷した
PERSONNEL
ドメインから,2001 年 12 月 5 日の午後 1 時 30 分 (最後にバックアップした日時) 以降に変更されたファイルだけを抽出します。
ドメインは元のボリュームにリストアされます。
# umount /PERSONNEL # mkfdmn /dev/disk/dsk3c RECOVER # mkfset RECOVER recover_fset # mkdir /recover # mount RECOVER#recover_fset /recover # /sbin/advfs/salvage -d 200112051330 -D /recover PERSONNEL salvage: Domain to be recovered 'PERSONNEL' salvage: Volume(s) to be used '/dev/disk/dsk12c' salvage: Files will be restored to '/recover' salvage: Logfile will be placed in './salvage.log' salvage: Starting search of all filesets: 09-Dec-2001 salvage: Starting search of all volumes: 09-Dec-2001 salvage: Loading file names for all filesets: 09-Dec-2001 salvage: starting recovery of all filesets: 09-Dec-2001
mkfdmn
コマンドを実行する前に,salvage.log
ファイルを表示して,必要なすべてのファイルが復元されたことを確認します。
失われたファイルがある場合,salvage
コマンドの
-d
オプションにもっと前の日付を指定して実行することで,さらに情報を取得できる場合があります。
新しいドメインを作成すると,salvage
を再び実行することはできません。
ただし,6.2.6.3 項に説明するように,-S
オプションを指定して実行することはできます。
# mkfdmn /dev/disk/dsk12c PERSONNEL # mkfset PERSONNEL personnel_a-e # mkdir /personnel_a-e # mount PERSONNEL#personnel_a-e /personnel_a-e # vrestore /dev/tape/tape0 /personnel_a-e # cp -Rp /RECOVER/personnel_a-e/* /personnel_a-e # umount /recover # rmfdmn RECOVER rmfdmn: remove domain RECOVER [y/n] y rmfdmn: domain RECOVER removed.
ルート・ドメインが破損してシステムをブートできない場合,インストール CD-ROM からシステムをブートし,/sbin/advfs/salvage
コマンドを使用することができます。
6.3.4 項の手順に従ってください。
ルート・ドメインの損傷の種類と程度によって,ファイルの復旧が成功するかは左右されます。
6.2.6.3 ブロック単位でのデータの復元
salvage
ユーティリティを実行しても復元できないファイルが大量にある場合は,salvage
コマンドに
-S
オプションを指定して実行します。
この処理では,ユーティリティがすべてのディスク・ブロックを少なくとも一度は読み取ることになるため,完了までにかなりの時間を要します。
注意
正常なドメインに対して誤って
mkfdmn
コマンドを実行してしまった場合は,salvage
コマンドに -S オプションを指定して実行する以外にファイルを復元する方法はありません。
注意
salvage
ユーティリティはブロック型デバイスを直接オープンして読み取りを実行するため,セキュリティ上の問題につながる可能性があります。 salvage ユーティリティを-S
オプション付きで実行すると,現在の AdvFS ドメインからデータの復元を試みるときに,削除済みの古い AdvFS ドメインのデータも取り込まれる可能性があります。
次の例では,ドメイン
PERSONNEL
からデータをブロック単位で復元します。
# /sbin/advfs/salvage -S PERSONNEL salvage: Domain to be recovered 'PERSONNEL' salvage: Volume(s) to be used '/dev/disk/dsk12c' salvage: Files will be restored to '.' salvage: Logfile will be placed in './salvage.log' salvage: Starting sequential search of all volumes: 07-Oct-2001 salvage: Loading file names for all filesets: 07-Oct-2001 salvage: Starting recovery of all filesets: 07-Oct-2001
この節では,システムをリストアするさまざまな方法を説明します。
6.3.1 ドメイン・パニックからの回復
メタデータ書き込みエラーが発生するか,AdvFS ドメインの 1 つで破損が検出された場合,システムは,そのドメインに対して ドメイン・パニックが発生すると, 例:
特に設定しなければ,アクティブなドメインでドメイン・パニックが発生すると,ライブ・ダンプが生成され, ドメイン・パニックから回復するには,次の手順を実行します。
これらのファイルセットをすべてアンマウントします。
システムの障害レポート情報を保存します (6.2.1 項)。
ドメインのメタデータを保存します。
詳細については,
障害がハードウェアに起因するものである場合は,それを解決してから続けます。
ドメイン上で
エラーが発生しない場合は,アンマウントしたファイルセットをすべてマウントし,通常の操作を再開します。
障害のために完全な回復が行えない場合は,新しいドメインを作成します(6.2.6 項)。
次の例では,ドメイン
ドメイン・パニックが発生しても,リブートする必要はありません。
ドメイン・パニック前に,I/O エラーを報告するメッセージが表示された場合,修復すべきハードウェア障害に起因する可能性があります。
次に,I/O エラー・メッセージの例を示します。
I/O エラーを示さないドメイン・パニックが繰り返し起こる場合,まず, ファイルセットのマウント時に,AdvFS はドメイン内のすべてのボリュームにアクセスできることを確認します。
ドメインのメタデータに記録されているサイズは,各ボリュームでボリュームのサイズと一致しなければなりません。
サイズが一致すると,マウント処理が続行されます。
記録されているサイズよりも実際のボリュームが小さい場合,AdvFS は,ファイルセットで使用中とマークされている最後のブロックを読み込もうとします。
このブロックが読み込めればマウントは成功しますが,ファイルセットは読み取り専用になります。
使用中の最後のブロックが読み取れないボリュームがドメイン内にある場合,マウントは失敗します。
詳細については,
ファイルセットが読み取り専用でマウントされている場合,エラー・メッセージにフラグ付きで示されたボリュームのラベルをチェックしてください。
よくあるエラーには,次の 2 つがあります。
RAID アレイ上のディスクのラベルが適切でない。
AdvFS ドメインが置かれているボリュームが,元のサイズより縮小された。
AdvFS Utilities を利用でき,かつドメインが複数のボリュームで構成されており,さらに障害の発生したボリューム (フラグのついた) を削除できるだけの空きスペースがある場合,ファイルセットを削除する必要はありません。
ただし,次の作業に進む前に,バックアップを作成してください。
たとえば,ドメイン
AdvFS Utilities を利用できない場合,次の手順を実行します。
ドメイン内のすべてのファイルセットのバックアップを取ります。
新しいドメインを作成します。
バックアップからファイルセットをリストアします。
たとえば,ドメイン
ファイルセットをマウントするためには,AdvFS に有効な
このディレクトリの最新状態のバックアップ・コピーがある場合には,バックアップから
ディレクトリを手作業で再構築する場合は,それぞれのドメイン名とその対応するボリュームを知っておく必要があります。
既存のドメインを再構築するために
次の例では,
次の例では,1 つのマルチボリューム・ドメインを再構成しています。
AdvFS ファイル・システムを正しく動作させるためには,各ドメインで,次の 3 つの数値が一致していなければなりません。
ドメインのボリューム・カウント。
AdvFS のディスク上のメタデータに記憶され,ドメイン内のパーティション数を示します。
これらの数値が一致しない場合, これらの数値が一致しなくなる原因はいくつかあります。
一般的に 表 6-1
は,
表 6-2
は,ドメイン・ボリューム・カウントが,パーティション数と
表 6-3
は,パーティション数が,ドメイン・ボリューム・カウントと
次の例では,見つからなかったドメインはありません。
次の例では, AdvFS ドメインを含むパーティションを見つけます。
ドメインのボリューム・カウントとして 1 を報告していますが, 別の AdvFS ドメインを含む別のパーティションを見つけます。
ドメインのボリューム・カウントは同様に 1 です。
このパーティションを含むドメイン・ディレクトリはありません。
それ以外に AdvFS パーティションは見つかっていません。
ドメイン・ボリューム・カウントと見つかったパーティションの数は,検出されたどちらのドメインでも一致しています。
通常,AdvFS のルート・ドメインに回復不可能な損傷が生じた場合には,ルート・ファイル・システムを作り直して,システムをブート可能にする必要があります。
クラスタ構成を採用している場合は,『システム管理ガイド』および 『クラスタ管理ガイド』を参照してください。
また,ルート・ボリュームが LSM ボリュームの場合には,『Logical Storage Manager』を参照してください。
ルート・ドメインを再構築するには,root ユーザの特権が必要です。
インストレーション CD-ROM か,RIS (Remote Installation Service) サーバが必要です。
ルート・ドメインは,ブート・デバイス上に作成します。
ルート・ドメインの適切なバックアップがない場合は,損傷の性質と程度によっては,ルート・ファイルを まず,ハードウェア・リソースを特定します。
インストレーション CD-ROM からシステムをリブートする場合,SRM (System Reference Manual) コンソールのプロンプトに次のコマンドを入力し,CD-ROM デバイスの名前を調べます。
この例では,CD-ROM デバイスの名前は
RIS サーバからブートする場合は,次のコマンドを入力してネットワーク・インタフェース・デバイスの名前を調べます。
この例では,ネットワーク・インタフェース・デバイスの名前は
コンソール・ブート・デバイスの名前を調べます。
デフォルト・ブート・デバイスの場合,次のコマンドで調べることができます。
上記の例の
デフォルト・ブート・デバイスでない場合は, システムをインストレーション CD-ROM または RIS サーバからブートします。
たとえば,特定した上記のデバイスを,CD-ROM を使ってブートする場合,次のコマンドを入力します。
RIS サーバを使用する場合は,次のコマンドを入力します。
インストールを終了します。
VGA グラフィック・コンソールを利用している場合は,インストレーションの終了を選択するか,「Installation and Configuration Welcome」ダイアログ・ボックスの [File] メニューからシェル・ウィンドウを選択します。
シリアル・コンソール・ターミナルを使用している場合には,
システム構成を確認したら,次の手順を実行します。
インストール・メディアからブートしたときに,ルート・ドメインがマウント可能の場合には,インストール手順では,まずインストールしたルート・ドメインの既存のデバイス・データベースを読み取ろうとします。
ハードウェア・データベースの読み取りに失敗すると,エラー・メッセージが表示されます。
このような状況が発生した場合は,UNIX が割り当てたそのデバイス名を,適切なハードウェア・デバイス名に変換する必要があります。
この例のハードウェア・データベースでは,バス/ターゲット/LUN が 1/4/00 のディスクが
特定したデバイスが妥当かどうかは,
この時点でテープ・デバイスをインストールする必要がある場合は,次のコマンドを入力します。
有効なバックアップがある場合は,そこからリストアできます。
バックアップが古いものである場合は,そこからリストアした後,
古いルート・ドメインをマウントします。
マウントに失敗した場合は,ステップ 7 に進みます。
バックアップを行なうことはできません。
可能ならバックアップを作成します。
第 4 章を参照してください。
たとえば,ボリューム
復旧した情報を一時的に保管するドメインとファイルセットを作成し,ファイルセットをマウントします。
この例では,
新しいルート・ドメインとルート・ファイルセットを作成します。
このファイルセットを
有効なバックアップ・ソースがある場合,そこからファイルをリストアします。
救済したファイルがあれば,復旧先からルート・ドメインにコピーします。
そして復旧用のドメインを削除します。
ルート・ドメインがリストアされました。
システムを停止しリブートします。
この手順が成功しない場合は,オペレーティング・システムを再インストールし,ファイルを再作成します。
ハードウェア障害のために AdvFS に問題が発生することがあります。
たとえば,ファイル・システムへの書き込みが,ハードウェア障害によって失敗した場合,メタデータの損傷として現れることがあります。
ハードウェアの問題は,AdvFS ファイル・システム側では解決できません。
マルチボリューム・ドメインの 1 つのドメインに原因不明のエラーが発生した場合,次の手順の 1 つ以上を行ないます。
AdvFS の I/O エラー・メッセージが記録されていないにもかかわらず,ファイル・システムで不可解な動作が見られる場合には,できるだけ早くドメインをアンマウントし, AdvFS の I/O エラー・メッセージに示されているボリュームの,デバイス・ドライバの I/O エラー・メッセージをチェックします。
AdvFS の I/O エラー・メッセージに対応するこの I/O エラー・メッセージが存在しない場合は,ファイル・システムは,それが置かれているハードウェアの障害による影響を受けています。
できるだけ早くドメインをアンマウントし, マルチボリューム・ドメインを使用していて,十分な空き領域がある場合は, 最新のバックアップがあれば,ドメインをリストアすることができます。
バックアップがない場合,またはあっても情報が古すぎて使えない場合は, 再作成したドメインの内容を,救済しバックアップした情報を使用してリストアします。
ドメイン内のファイルセットを再度マウントします。
マシンに障害が発生した場合,AdvFS ドメインを含むディスクを AdvFS ソフトウェアが動作している他のコンピュータに移すことができます。
ディスクを新しいマシンに接続し, DVN4 ドメインを,オペレーティング・システム・ソフトウェアの Version 4 が動作しているシステムに移動することはできません。
これを行なうとエラー・メッセージが生成されます (互換性については,6.4.6 項を参照)。
Version 4 が動作しているマシンの DVN3 ドメインを Version 5 が動作しているマシンに移動することはできます。
新しいオペレーティング・システムは,以前の OS で作成されたドメインを認識します。
ボリュームを新しいマシンに移動するのに
ドメインがどのパーティション上にあるか分らない場合は,新しいマシンにディスクを追加し, 次の例では,古いマシン上の 2 つのディスク, ディスクの移動先となる稼働中のマシンをシャットダウンします。
異常のあるマシンから取り出したディスクを正常なマシンに取り付けます。
システムをリブートします。
シングルユーザ・モードでリブートする必要はありません。
この新しいディスク用に作成されたデバイス・ノードを確認します。
Device Name 欄をチェックして,今追加したディスクの名前を確認します。
ディスク番号が最も大きいものが,それに相当します。
新しいディスク ID はこの例では,
ボリュームをマウントします。
マルチボリューム
最初に 1 つのボリュームを含む usr ドメインを作成して
LMF は 2 つのコンポーネント,すなわち
次の例は, ルート・ファイルセットを読み書き両用でマウントします。
古い
ライセンス・データベースをリセットします。
次の例も, ルート・ファイルセットを読み書き両用でマウントします。
古い
ライセンス・データベースをリセットします。
ボリュームを
クラッシュ発生後に各ドメインがマウントされると,システムによって回復コードが自動的に実行されます。
このコードはトランザクション・ログ・ファイルを見て,システム・クラッシュ時に実行していたファイル・システム操作が完了したか,バックアップされたかをチェックします。
これにより,AdvFS メタデータは,クラッシュ後も一貫した状態を保つことができます。
クラッシュ発生時とは異なるオペレーティング・システムでファイル・システムを回復することはお勧めできません。
システム・クラッシュによってデータがダメージを受けた場合,5.5 節
を参照して,そのような問題が将来起きないようにするために,データをディスクに書き込む方法を改善してください。
ディスク・スペースの割り当て状況は,ファイル,ファイルセット,またはドメイン別に確認できます。
表 6-4
は,ディスク・スペースの使用状況を調べるために使用できるコマンドを示しています。
状況によっては,AdvFS のディスク使用状況の情報が破損することもあります。
この情報を修復するには, クォータのディスク使用量を調べるには,3.4 節を参照してください。
既存ドメイン ( たとえば,ドメイン
追加するディスクまたはディスク・パーティションが既存のドメインの一部でなくても,ラベルが設定されているために警告メッセージが表示される場合は,ディスク・ラベルをリセットします。
これを
データを定期的かつ頻繁にバックアップし,ディスク障害の兆候を見逃さないようにします。
障害が顕在化する前に,問題のあるディスクからファイルを削除することにより,多くのトラブルを未然に防ぐことができます。
AdvFS Utilities を利用している場合, リソースの使用についての制限が一切ない状態でシステムが稼働している場合は,システムにクォータを追加して,ユーザがアクセスできるディスク・スペースの容量を制限することができます。
ユーザ・クォータおよびグループ・クォータは,UFS のクォータと同様に,ユーザまたはグループが 1 つのファイルセットに対して割り当てることができるスペースの量を制限します。
ファイルセット・クォータは,AdvFS で導入されたもので,ドメインで利用できるすべてのスペースを 1 つのファイルセットで使い切ってしまうのを防ぎます。
詳細については,第 3 章を参照してください。
クォータ限界値に達しつつある場合,または限界値に達するとは思えない場合でも,クォータ・システムの限界値を超過する可能性があります。
クォータに関する詳細は
第 3 章
を参照してください。
エディタの使用中に,編集データを保存するとクォータの限界値を超えることが分かった場合,エディタを強制終了したりファイルに書き出すとデータが失われる可能性があります。
その代わり,次のいずれかを行ないます。
編集中のファイルを保存する前に,他のファイルを削除して,編集中のファイルのために十分な空きスペースを作ります。
編集中のファイルを
ハードおよびソフト限界値は,その値自体を含みません。
その値未満の場合だけ,ファイルを作成することができます。
たとえば,ハード限界値が1000 ファイルの場合,作成できるのは 999 ファイルまでです。
ブロック数のハードおよびソフト限界値も同様に,その値自体を含みません。
AdvFS ではまれに,ユーザ,グループ,またはファイルセット・クォータ値に達するまでに残り 8K バイトとなった時点で,残りのスペースの一部または全部を使用しようとすると,クォータに制約される場合があります。
これは,AdvFS がストレージを 8K バイト単位で割り当てるためです。
ファイルに 8K バイトのデータを追加するとクォータの限界値に達するか超えてしまう場合,そのファイルは拡張されません。
マウントしていないか,または
猶予期間を無効にするには, Version 5.0 以降のオペレーティング・システムで作成されるドメインは,以前のバージョンとは互換性のない新しいオンディスク・フォーマットになります (2.3.3 項を参照)。
新しいオペレーティング・システムは以前のディスク構造を認識しますが,以前のオペレーティング・システムは新しいディスク構造を認識しません。
Version 5.0 以降のオペレーティング・システムのフル・インストレーションを行う代わりに,Version 4 からのアップデート・インストレーションを行う場合, 旧バージョンのオペレーティング・システムから DVN4 のファイルセットにアクセスするには,Version 5.0 以降のオペレーティング・システム・ソフトウェアが稼働しているサーバからファイルセットを NFS マウントします。
Version 5.0 より前のバージョンのオペレーティング・システムが稼働している環境で,DVN4 のドメインに属するファイルセットをマウントしようとすると,エラー・メッセージが表示されます。
DVN3 のドメインを DVN4 に自動的にアップグレードするツールはありません。
ドメインを DVN4 にアップグレードするには,2.3.3.4 項の手順に従ってください。
Version 5.0 以降のオペレーティング・システムで作成されるドメインは,新しいオンディスク・ファイル・フォーマットになっているため,以前のリリースの AdvFS Utilities の中には,使用すると DVN4 ドメインを壊す可能性があるものがあります。
旧バージョンのオペレーティング・システムの,静的にリンクされた AdvFS 固有のユーティリティは,Version 5.0 以降では動作しません。
このようなユーティリティは,通常 Version 4.0 より前のオペレーティング・システムのユーティリティです。
また,旧バージョンの Tru64 UNIX に含まれる,以下に示す動的にリンクされた AdvFS Utilities は,Version 5.0 以降では動作しません。
システムがクラッシュすると,AdvFS はリブート時に復旧しようとします。
クラッシュ時にマウントされていたファイルセットのあるドメインは,そのドメインのファイルセットを再マウントすると回復します。
この回復処理では,AdvFS トランザクション・ログ・ファイルを使用して,AdvFS メタデータの一貫性を保ちます。
オペレーティング・システムのバージョンによってトランザクション・ログ・ファイルの構造は異なります。
そのため,AdvFS の回復操作は,クラッシュ時に使用していたオペレーティング・システムと同じバージョンで実行することが重要です。
そうしないと,ドメイン・メタデータの破壊やドメイン・パニック (あるいはその両方) が発生する危険性があります。
AdvFS のルート・ドメインを置くことができるボリューム (パーティション) の数は,クラスタ構成の場合を除いて 1 つだけです。
したがって,ルート・ドメインのサイズを拡張するには,ルート・ドメインを含むボリュームのサイズを増やすか,より大きなボリューム上にルート・ドメインを作り直す必要があります。
ルート・ドメインを含むボリュームのサイズを拡張した場合,2.3.4.3 項
の手順に従って, ルート・ドメインを別のデバイスに再作成するには,インストールした新しいデバイスと,インストレーション CD-ROM または RIS サーバ,およびドメインをバックアップするためのバックアップ・テープまたは未使用のディスク・パーティションが必要です。
ルート・ドメインを移動するには,まず新しいディスクをインストールし,それを認識させる必要があります。
ルート・ボリュームに使用するディスクがすでにインストールされている場合は,ステップ 5 を省略し,次に進みます。
システムをシャットダウンします。
新しいディスク・デバイスをインストールします。
この方法については,ハードウェア・マニュアルを参照してください。
追加したディスクがコンソールで認識されることを確認します。
次の例では,
システムをリブートします。
ブート中にオペレーティング・システムが新しいデバイスを認識し,それをデバイス情報データベースに適宜反映します。
追加したディスクには,オペレーティング・システムによって
特定したデバイスが妥当かどうかは,
root としてログインし,
この例では
必要に応じ
新しいデバイスにルート・ドメインを作成します。
古いルート・ドメインからブートしたシステムをシャットダウンします。
オペレーティング・システム CD-ROM または RIS サーバからブートします。
たとえば CD-ROM を使用する場合,次のコマンドを入力します。
たとえば RIS サーバを使用する場合,次のコマンドを入力します。
インストールを終了します。
VGA グラフィック・コンソールを使用している場合は,インストレーションの終了を選択するか,「Installation and Configuration Welcome」ダイアログ・ボックスの [File] メニューからシェル・ウィンドウを選択します。
シリアル・コンソール・ターミナルを使用している場合には, 新しいルート・デバイスに新しいルート・ドメインとルート・ファイルセットを作成します。
元のデバイスにリンクするために
古いルート・ドメインからファイルをダンプし,新しいルート・ドメインにリストアします。
システム情報を新しいルート・ボリュームを指すようにアップデートします。
この例では,ルート・ドメインとスワップ・パーティションは
システムを停止し,省略時のブート・デバイスを変更します。
新しいルート・ドメインをブートします。
メモリ・マッピング・モードのファイルは, ディスク上の古くなったデータは削除しない限り,クラッシュの後,または
オブジェクト・セーフティ・オプションを有効にすると,そのファイルセットに属するディスク上のページがゼロで充填され,ファイルによって使用される前にディスクに強制的に書き込まれます。
これにより,そのファイルの書き込み中にシステムがクラッシュしても,古いデータが見えてしまうことはなくなります。
オブジェクト・セーフティを有効にする直前にストレージを割り当てられたファイルでは,その割り当てに関連するバッファがディスクに書き込みされると,オブジェクト・セーフティが起動します。
たとえば,
オブジェクト・セーフティを使用すると,ページを 2 度ディスクに書き込まなければならないため性能は低下します。
ディスクに書き込まれたセーブセットのリストア時に,フォーマットが無効であるか,または壊れていることを示すメッセージが表示された場合には,そのセーブセットがパーティション
ディスクのブロック 0 から始まるパーティションにセーブセットを正しくダンプするには,あらかじめディスク・ラベルをクリアする必要があります。
ディスク・ラベルをクリアしないで
ディスクの性能は,それへの I/O 要求に依存します。
1 つのボリュームに高負荷のアクセスが集中するようにドメインが構築されている場合,システムの性能が低下します。
マルチボリューム・ドメインがある場合,さまざまな方法で負荷のバランスを改善し,スループットを向上させることができます。
詳細については,『システムの構成とチューニング』,および第 5 章を参照してください。
性能を低下させている原因を見つけるには,まずシステムの動作をチェックします。
性能を改善する方法は,数多くあります。
ドメインのアップグレード (2.3.3.4 項を参照)
ディスク・アクセスの互換性の問題の回避 (5.6 節を参照)
ドメインの断片化解消 (5.9 節を参照)
他のボリュームへのファイルセットの移動 (5.14 節を参照)
AdvFS Utilities を使用できる場合には,以下の作業を行うこともできます。
リソース割り当ての変更。
ドメインのサイズを増やすか,遅いボリュームを速いボリュームに交換します。
マルチボリューム・ドメインのバランシング (5.11 節を参照)
ファイル単位でのストライプ化 (5.13 節を参照)
ファイル単位での移動 (5.12 節を参照)
EVM
イベントのログが記録され
(
EVM
(5)AdvFS Domain Panic; Domain
name
Id
domain_Id
AdvFS Domain Panic; Domain staffb_domain Id 2dad7c28.0000dfbb
An AdvFS domain panic has occurred due to either a
metadata write error or an internal inconsistency.
This domain is being rendered inaccessible.
/var/adm/crash
ディレクトリに置かれます。
さらに,AdvFS 関連のエラーが
/var/adm/binary.errlog
に記録される場合もあります。
mount
コマンドに
-t advfs
オプションを指定して実行し,影響を受けているドメイン内のファイルセットをすべて把握します。
savemeta
(8)/sbin/advfs/verify
ユーティリティを実行します (6.2.4 項を参照)。
verify
コマンドは実行できても,エラーが表示される場合,/sbin/advfs/fixfdmn
コマンド (6.2.5 項) を実行し,メタデータの破損を修復します。
staffb_dmn
上のシステム・パニックの後で,必要な一連のコマンドを実行しています。
# mount -t advfs
staffb_dmn#staff3_fs on /usr/staff3 type advfs (rw)
staffb_dmn#staff4_fs on /usr/staff4 type advfs (rw)
# umount /usr/staff3
# umount /usr/staff4
# sys_check -escalate
# /sbin/advfs/savemeta staffb_dmn /tmp/saved_dmn
# /sbin/advfs/savemeta -f staff3_fs /tmp/saved_staff3
# /sbin/advfs/savemeta -f staff4_fs /tmp/saved_staff4
# /sbin/advfs/verify staffb_dmn
AdvFS I/O error:
Domain#Fileset: staffb_dmn#staff3_fs
Mounted on: /usr/staff3
Volume: /dev/disk/dsk6c
Tag: 0x00000006.8001
Page: 56
Block: 1200
Block count: 128
Type of operation: Write
Error: 19
EEI: 0x6200 (Advfs cannot retry this)
AdvFS initiated retries: 0
Total AdvFS retries on this volume: 0
I/O error appears to be due to a hardware problem.
Check the binary error log for details.
To obtain the name of the file on which
the error occurred, type the command:
/sbin/advfs/tag2name /usr/staff3/.tags/6
fixfdmn
ユーティリティを実行してみます (6.2.5 項)。
fixfdmn
を実行してもドメイン・パニックが起こる場合,AdvfsDomainPanicLevel
属性 (5.15 節) を調整して,問題解決に役立つ情報を取得することもできます。
6.3.2 読み取り専用でマウントされたファイルセットの復旧
mount
(8)
rmvol
コマンドを使って,ドメインからボリュームを削除します。
これにより,データは自動的に残りのボリュームに移されます。
残りのボリュームに十分な空きスペースがない場合は,ボリュームを削除する前に
addvol
コマンドを使用してスペースを追加します。
disklabel
コマンドを使って,障害のあるボリュームのディスク・ラベルを修復します。
addvol
コマンドを使って,修復したボリュームをドメインに戻します。
balance
コマンドを実行して,データを新しいボリュームに分散させます。
data5
内の
/dev/disk/dsk2c
(disk_a
と呼ぶデバイスにあるとする) のラベルが正しくない場合,以下のコマンドで,そのボリューム上のファイルを移動し (rmvol
コマンドで自動的に),ボリュームを修復しデータをリストアした後に,それらのファイルを元に戻すことができます。
最初の
addvol
のステップは,削除するボリューム上の情報のためにドメインのスペースが必要な場合のみ行ないます。
# addvol /dev/disk/dsk3c data5
# rmvol /dev/disk/dsk2c data5
# disklabel -z dsk2
# disklabel -rw dsk2 disk_a
# addvol /dev/disk/dsk2c data5
# balance data5
rmfdmn
コマンドを使って,ドメインを削除します。
disklabel
コマンドを使って,ボリュームのディスク・ラベルを修復します。
data3
を含む
/dev/disk/dsk1c
(disk_a
と呼ぶデバイスにあるとする) のラベルが正しくない場合,次のようにコマンドを実行します。
# vdump -0f -u /data3
# rmfdmn data3
# disklabel -z dsk1
# disklabel -rw dsk1 disk_a
# mkfdmn data3
# mkfset data3 data3fset
# mount data3#data3fset /data3
# vrestore -xf - /data3
/etc/fdmns
ディレクトリがなければなりません (2.3.1 項を参照)。
/etc/fdmns
ディレクトリが間違っているか,または損傷していると,ドメインにアクセスできなくなりますが,ドメイン内のデータはそのまま残っています。
/etc/fdmns
ディレクトリはバックアップからリストアするか,あるいは再作成することができます。
/etc/fdmns
ディレクトリをリストアすることをお勧めします。
/etc/fdmns
ディレクトリのバックアップには,標準のバックアップ機能 (vdump
,tar
,または
cpio
) を使用できます。
ディレクトリをリストアするには,バックアップ・プロセスと互換性のある回復手順を使用します。
/etc/fdmns
ディレクトリをリストアできない場合,このディレクトリは手作業または
/sbin/advfs/advscan
コマンドによって再構成できます。
手作業での再構成については
6.3.3.1 項,/sbin/advfs/advscan
コマンドによる再構成については
6.3.3.2 項をそれぞれ参照してください。
/etc/fdmns
ディレクトリを再構成するための手順は,シングル・ボリュームとマルチボリュームのいずれのドメインの場合も類似しています。
失われているドメイン,失われているリンク,またはディレクトリ全体に関して,ディレクトリの再構成を行うことができます。
6.3.3.1 手作業による /etc/fdmns ディレクトリの再構成
注意
mkfdmn
コマンドを実行しないでください。
実行するとそのボリューム上のデータが破損します。
ファイルが破損した場合,salvage
コマンドに
-S
オプションを指定して実行することで,一部のファイルを復旧できる場合があります。
/etc/fdmns
ディレクトリと 2 つのドメインを再構築します。
この例では,ドメインは存在してその名前も知っています。
各ドメインは,シングル・ボリューム (特殊デバイス) からなります。
リンクを作成する順序は問いません。
この 2 つのドメインは,/dev/disk/dsk1c
上の
domain1
と,/dev/disk/dsk2c
上の
domain2
です。
# mkdir /etc/fdmns
# mkdir /etc/fdmns/domain1
# cd /etc/fdmns/domain1
# ln -s /dev/disk/dsk1c .
# mkdir /etc/fdmns/domain2
# cd /etc/fdmns/domain2
# ln -s /dev/disk/dsk2c .
domain1
ドメインは,3 つのボリューム
/dev/disk/dsk1c
,/dev/disk/dsk2c
,および
/dev/disk/dsk3c
を含みます。
# mkdir /etc/fdmns
# mkdir /etc/fdmns/domain1
# cd /etc/fdmns/domain1
# ln -s /dev/disk/dsk1c .
# ln -s /dev/disk/dsk2c .
# ln -s /dev/disk/dsk3c .
6.3.3.2 advscan コマンドによる /etc/fdmns ディレクトリの再構成
/sbin/advfs/advscan
コマンドを使用すると,ディスクを新しいシステムに移動した場合,デバイス番号を変更した場合,またはドメインの位置が分らなくなった場合に,どのディスク・パーティションや,どの Logical Storage Manager (LSM) ボリュームが AdvFS のドメインの一部になっているかを確認することができます。
このコマンドはまた,間違えて
/etc/fdmns
ディレクトリを削除してしまった場合,/etc/fdmns
ディレクトリからドメインを削除してしまった場合,または
/etc/fdmns
ディレクトリのドメインのサブディレクトリからのリンクを削除してしまった場合に,/etc/fdmns
ディレクトリのすべてまたは一部を再構築する目的でも使用できます。
詳細については,
advscan
(8)
advscan
コマンドによって検索された,同一のドメイン ID を持つ物理パーティションの数。
/etc/fdmns
のパーティションへのリンク数。
各パーティションがリンクで表されるためです。
advscan
コマンドは,そのドメインを修正しようとします。
advscan
コマンドは,パーティション数や
/etc/fdmns
リンクの数よりもドメインのボリューム・カウントの方を信頼性が高いものとして扱っています。
以下の表では,不一致状態,考えられる原因,および
advscan
ユーティリティで実行できる修正処置の一覧を示します。
/etc/fdmns/domain_name
ディレクトリ内のリンク数が,パーティション数とドメイン・ボリューム・カウントの予想値と一致しない場合の,考えられる原因と修正処置を示しています。
表 6-1: リンク数の不一致
リンク数
考えられる原因
修正処置
少なすぎる
addvol
コマンドが早期に終了してしまった。
または
/etc/fdmns/domain_name
内のリンクが手動で削除された。advscan
コマンドに
-f
オプションを指定して実行する前にドメインがアクティブ化されており,不一致の原因が
addvol
の中断によるものである場合,この状態は自動的に修正されます。
それ以外の場合には,advscan
ユーティリティが,/etc/fdmns/domain_name
ディレクトリにパーティションを追加します。
多すぎる
rmvol
コマンドが早期に終了してしまった。
または
/etc/fdmns/domain_name
内のリンクが手動で追加された。ドメインがアクティブ化されており,不一致の原因が
rmvol
の中断である場合,状況は自動的に修正されます。
/etc/fdmns/domain_name
に手動で追加したリンクが原因であれば,/etc/fdmns/domain_name
ディレクトリ内のリンクを体系的に削除し,ドメインをアクティブ化します。
削除するリンクの数は,/etc/fdmns/domain_name
ディレクトリ内のリンク数から,advscan
コマンドで表示されるドメイン・ボリューム・カウントを引いた数です。/etc/fdmns/domain_name
ディレクトリ内のリンク数の予想値と一致しない場合の,考えられる原因と修正処置を示しています。
表 6-2: ドメイン・ボリューム・カウントの不一致
ドメイン・ボリューム・カウント
考えられる原因
修正処置
少なすぎる
原因不明
修正できない。
/sbin/advfsfixfdmn
コマンドを実行し,ドメインを使用可能な状態にします。
多すぎる
addvol
コマンドが早期に終了してしまった。
追加しようとしているパーティションが存在しない,あるいは再利用された。修正できません。
salvage
ユーティリティを実行し,ドメインに残っているボリュームからできるだけ多くのデータを復元します。/etc/fdmns/domain_name
ディレクトリ内のリンク数の予想値と一致しない場合の,考えられる原因と修正処置を示しています。
パーティション数
考えられる原因
修正処置
少なすぎる
パーティションの消失
修復できません。
fixfdmn
コマンドを使用してドメインを使用可能な状態にします。
多すぎる
addvol
コマンドが早期に異常終了した。addvol
コマンドを再度実行します。advscan
コマンドはデバイス
dsk0
と
dsk5
を走査して,AdvFS パーティションを探し,2 つのパーティション,dsk0c
と
dsk5c
が見つかっています。
ドメイン・ボリューム・カウントとして,2 が報告され,2つのリンクが
/etc/fdmns
ディレクトリ内に登録されています。
# /sbin/advfs/advscan dsk0 dsk5
Scanning disks dsk0 dsk5
Found domains:
usr_domain
Domain Id 2e09be37.0002geb40
Created Thu Feb 28 09:54:15 2002
Domain volumes 2
/etc/fdmns links 2
Actual partitions found:
dsk0c
dsk5c
dsk6
を含むドメインを定義しているディレクトリが
/etc/fdmns
ディレクトリから削除されています。
このため,/etc/fdmns
リンクの数,パーティションの数,およびドメインのボリューム・カウントが一致していません。
この例では
advscan
コマンドが,デバイス
dsk6
を走査し,見つからないドメインを次のようにして再生しています。
/etc/fdmns
ディレクトリにはこのパーティションを含むドメイン・ディレクトリはありません。
advscan
コマンドは,/etc/fdmns
ディレクトリ内に,2 つのドメインのためのディレクトリを作成しています。
advscan
コマンドは,/etc/fdmns/domain_name
ドメイン・ディレクトリ内にそれらのデバイスに対するシンボリック・リンクを作成しています。
/etc/fdmns
ディレクトリにそのパーティションのディレクトリのエントリがない場合,そのパーティション名にはアスタリスク (*) がつけられ,ユーティリティによってそのドメイン名が作成されます。
復旧したドメインを元のドメインの名前に変更する必要があります。
この例では,元のドメインの名前は
revenue
と
expenses
です。
# /sbin/advfs/advscan -r dsk6
Scanning disks dsk6
Found domains:
*unknown*
Domain Id 2f2421ba.0008c1c0
Created Sun Jan 20 13:38:02 2002
Domain volumes 1
/etc/fdmns links 0
Actual partitions found:
dsk6a*
*unknown*
Domain Id 2f535f8c.000b6860
Created Mon Feb 25 09:38:20 2002
Domain volumes 1
/etc/fdmns links 0
Actual partitions found:
dsk6b*
Creating /etc/fdmns/domain_dsk6a/
linking dsk6a
Creating /etc/fdmns/domain_dsk6b/
linking dsk6b
# mv /etc/fdmns/domain_dsk6a /etc/fdmns/revenue
# mv /etc/fdmns/domain_dsk6b /etc/fdmns/expenses
6.3.4 AdvFS ルート・ドメインのデータの損傷からの復旧
/sbin/advfs/salvage
ユーティリティで復旧できる場合があります。
詳細については,6.2.6 項
を参照してください。
salvage
ユーティリティを使用して,最新のバックアップ後に修正または作成されたファイルを復旧できる場合もあります。
>>> show device
...
DKA500 RRD47 1206 dka500.4.0.5.0
...
DKA500
です。
>>> show device | more
....
ewa0.0.0.8.0 EWA0 08-00-2B-C3-E3-DC
...
EWA0
です。
>>> show bootdef_dev
bootdef_dev dkb400.4.0.5.1
dkb400.4.0.5.1
は,dkb400
がブート・デバイスであること,dk
はデバイスが SCSI ディスクであること,b
はデバイスが SCSI バス
b
に接続されていること,400
はデバイスの SCSI ターゲット ID が
4
で 論理ユニット番号 (LUN) が
00
であることを示しています。
そこで,この例では,バス/ターゲット/LUN は,1/4/00
です。
show device
コマンドを実行し,表示されるリストから特定します。
>>> boot dka500
>>> boot ewa0
3) Exit Installation
を選択します。
/sbin/hwmgr
コマンドに
-view devices
オプションを指定することで,(前の手順で説明したように) 復旧するデバイスをそのバス/ターゲット/LUN 情報から調べ,バックアップに使用するディスクを特定し,テープ・デバイスがインストールされていることを確認します。
# /sbin/hwmgr -view devices
HWID: Device Name Mfg Model Location
------------------------------------------------------------
38:/dev/disk/floppy0c 3.5in floppy fdi0-unit-0
41:/dev/disk/dsk0c DEC RZ1DB-CA (C) DEC bus-1-targ-4-lun-0
42:/dev/disk/dsk1c DEC RZ1CB-CA (C) DEC bus-1-targ-5-lun-0
43:/dev/disk/dsk2c DEC RZ1CB-CA (C) DEC bus-1-targ-6-lun-0
44:/dev/disk/cdrom0 DEC RRD47 (C) DEC bus-0-targ-5-lun-0
46:/dev/ntape/tape0 DEC TLZ10 (C) DEC bus-1-targ-4-lun-0
dsk0
として認識されています。
/dev/disk/dsk0a
は,損傷のあるルート・ドメインを含むボリュームです。
hwmgr
コマンドに
-flash
オプションを指定すれば視覚的に確認できます。
このコマンドを実行すると,指定したディスクのランプが 30 秒間にわたって点滅します。
# /sbin/hwmgr -flash light -dsf /dev/disk/dsk0a
# /sbin/dn_setup -install_tape
salvage
コマンドに
-d
オプションを指定してその後の情報を復元します。
有効なバックアップがある場合は,ステップ 9 に進みます。
バックアップに関連したファイルを救済する必要がある場合は,ステップ 8 に進みます。
# mount old_root_domain#root /var/mnt
/sbin/advfs/verify
コマンドに
-a
を指定して実行します (6.2.4 項を参照)。
このコマンドが成功してエラーが表示されない場合,ステップ 12 に進みます。
/sbin/advfs/fixfdmn
コマンドを実行します。
詳細については,6.2.5 項を参照してください。
成功した場合は,ステップ 12 に進みます。
salvage
コマンドを実行してファイルを復旧し,一時ファイルセットかテープにそれを保存します。
古いバックアップがある場合,salvage
コマンドに
-d
を指定して実行します。
オプションを指定しないと,ドメイン全体を救済することになります。
/dev/disk/dsk0a
上の壊れたルート・ドメインのファイルを,ローカルの未使用ディスク
/dev/disk/dsk2c
に復旧するには,次の手順を実行します。
# mkfdmn /dev/disk/dsk2c RECOVER
# mkfset RECOVER recover_fset
# mkdir /var/recover
# mount RECOVER#recover_fset /var/recover
salvage
コマンドを実行します。
コマンドの対象のボリュームを指定するために,-V
オプションを使用する必要があります。
古いバックアップとともに用いるファイルを救済している場合は,-d
オプションを使用し,バックアップ後に変更になった情報のみを救済するようにします。
root
ドメインのファイルが抽出され,/recover
にマウントされたファイルセットに保存されます。
# /sbin/advfs/salvage -D /var/recover -V /dev/disk/dsk0a
salvage: Volume(s) to be used '/dev/disk/dsk0a'
salvage: Files will be restored to '/recover'
salvage: Logfile will be placed in './salvage.log'
salvage: Starting search of all filesets: 09-Dec-2001
salvage: Loading file names for all filesets: 09-Dec-2001
salvage: Starting recovery of all filesets: 09-Dec-2001
salvage.log
ファイルを調べ,すべての必要なファイルを復旧できたことを確認します。
いったん次のステップで
mkfdmn
コマンドを実行すると,さらに情報を抽出するために
salvage
コマンドを実行することはできません。
/var/mnt
にマウントします。
# mkfdmn -r /dev/disk/dsk0a root_domain
Warning: /dev/disk/dsk0a is marked in use for AdvFS.
If you continue with the operation you can
possibly destroy existing data.
CONTINUE? [y/n] y
# mkfset root_domain root
# mkdir /var/mnt
# mount root_domain#root /var/mnt
# vrestore -xf /dev/tape/tape0 -D /var/mnt
# cd /
# cp -Rp /recover/root/* /var/mnt
# umount /mnt /recover
# rmfdmn RECOVER
rmfdmn: remove domain RECOVER [y/n] y
rmfdmn: domain RECOVER removed.
6.3.5 ハードウェア障害からの回復
/var/adm/messages
ファイルを,AdvFS の I/O エラー・メッセージがないか調べます。
このファイルを見るには,root 特権が必要です。
このファイルには,エラーが発生したドメイン,ファイルセット,ボリュームが示されます。
また,I/O エラーの影響を受けたファイルを特定する方法も示されます。
次のようなファイルが表示されます。
Dec 05 15:39:16 systemname vmunix: AdvFS I/O error:
Dec 05 15:39:16 systemname vmunix: Domain#Fileset:test1#tstfs
Dec 05 15:39:16 systemname vmunix: Mounted on: /test1
Dec 05 15:39:17 systemname vmunix: Volume: /dev/rz11c
Dec 05 15:39:17 systemname vmunix: Tag: 0x00000006.8001
Dec 05 15:39:17 systemname vmunix: Page: 76926
Dec 05 15:39:17 systemname vmunix: Block: 5164080
Dec 05 15:39:17 systemname vmunix: Block count: 256
Dec 05 15:39:17 systemname vmunix: Type of operation: Read
Dec 05 15:39:17 systemname vmunix: Error: 5
Dec 05 15:39:17 systemname vmunix: To obtain the name of
Dec 05 15:39:17 systemname vmunix: the file on which the
Dec 05 15:39:17 systemname vmunix: error occurred, type the
Dec 05 15:39:17 systemname vmunix: command
Dec 05 15:39:17 systemname vmunix: /sbin/advfs/tag2name
Dec 05 15:39:17 systemname vmunix: /test1/.tags/6
/sbin/advfs/verify
ユーティリティ (6.2.4 項を参照),または/sbin/advfs/fixfdmn
コマンドに
-n
オプションを指定して実行し (6.2.5 項),ドメインのメタデータの整合性をチェックしてください。
verify
ユーティリティ,またはfixfdmn
コマンドに
-n
オプションを指定して実行し,ドメインのメタデータの整合性をチェックしてください。
rmvol
ユーティリティを
2.3.5 項
の説明に従って使用して,問題のあるボリュームを削除してみます。
これに成功すれば,ファイル・システムの問題は繰り返されなくなります。
rmvol
に失敗した場合,ボリュームを再作成する必要があります。
salvage
ユーティリティを使用して (6.2.6 項),破損したドメインの内容を抽出します。
rmfdmn
コマンドを使用して問題のあるドメインを削除します。
mkfdmn
コマンドを使用して,ドメインを再作成します。
新しいドメインは,省略時の設定でドメイン・バージョン番号 (DVN) が 4 になります (2.3.3 項を参照)。
必要に応じてボリュームを追加します。
問題のあるボリュームは,新しいドメインには入れないでください。
/etc/fdmns
ディレクトリを変更して,移動したボリュームを新しいシステムが認識するようにします。
新しいシステムとの競合を回避するために,ディスクの SCSI ID を割り当て直す必要がある場合があります。
詳細については,ディスクの製造元が提供する指示書を参照してください。
この処理を実行するには,root ユーザでなければなりません。
注意
addvol
コマンド や
mkfdmn
コマンドは使用しないでください。
このコマンドを実行すると,移動しようとしているディスク上のすべてのデータが削除されます。
すでにこのコマンドを実行してしまった場合は,6.2.6 項
を参照してください。
/sbin/advfs/advscan
ユーティリティを実行すると,この情報を再作成できることがあります。
また,ディスクのラベルをチェックして,過去にどのパーティションが AdvFS パーティションとして作成されていたかを確認することもできます。
パーティションがどのドメインに含まれていたかをディスク・ラベルで確認することはできません。
dsk3
と
dsk4
にドメイン
testing_domain
が存在するものとします。
このドメインには,2 つのファイルセット,sample1
と
sample2
が含まれています。
これらのファイルセットは,/sample1
と
/sample2
にマウントされています。
移動するドメインにパーティション
dsk3c
,dsk4a
,dsk4b
,および
dsk4g
があることが既に分かっているものとします。
この場合,ディスクは次の手順で移動します。
# /sbin/hwmgr -show scsi -full
disk 7
と
disk 8
です。
/etc/fdmns
ディレクトリを,移動したドメインからのシンボリック・リンクを含むように変更します。
# mkdir -p /etc/fdmns/testing_domain
# cd /etc/fdmns/testing_domain
# ln -s /dev/disk/dsk7c .
# ln -s /dev/disk/dsk8a .
# ln -s /dev/disk/dsk8b .
# ln -s /dev/disk/dsk8g .
# mkdir /sample1
# mkdir /sample2
/etc/fstab
ファイルに,移動したファイルセットのマウント・ポイント情報を追加します。
testing_domain#sample1 /sample1 advfs rw 1 0
testing_domain#sample2 /sample2 advfs rw 1 0
# mount /sample1
# mount /sample2
/usr
ファイル・システムをリストアするには,その前に
usr_domain
ドメインとそのすべてのボリュームを再構成する必要があります。
ただし,マルチボリューム・ドメインのリストアには License Management Facility (LMF) が必要です。
LMF によって,マルチボリューム・ドメインの作成に必要な
addvol
コマンドを含む AdvFS Utilities が制御されます。
addvol
コマンドをリストアします。
続いて LMF をリストアし,それを使用して
addvol
コマンドを有効化します。
以上の処理が完了すれば,usr ドメインにボリュームを追加して,マルチボリューム・ドメイン全体を復元できます。
/usr/sbin/lmf
に格納されているユーティリティと
/var/adm/lmf
内のデータベースから構成されています。
システムによっては
/var
が
/usr
にリンクされており,これらのディレクトリがともに usr ファイルセットに位置している場合もあります。
そのような構成のシステムでは,addvol
コマンドと LMF の 2 つのコンポーネントを usr ファイルセットにリストアします。
/usr
ディレクトリと
/var
ディレクトリが
usr_domain
内の異なるファイルセットに配置されているシステムでは,addvol
コマンドと LMF ユーティリティを usr ファイルセット,LMF データベースを var ファイルセットにそれぞれリストアします。
dsk1g
,dsk2c
,dsk3c
の 3 つのボリュームで構成されるマルチボリューム・ドメイン
usr_domain
のリストア方法を示しています。
usr_domain
ドメイン内のファイルセット
usr
内には,/var
ディレクトリと
/usr
ディレクトリがともに配置されています。
/usr
と
/var
のバックアップ・テープが存在します。
(バックアップ・テープを作成する必要がある場合は
第 4 章
を参照してください。)
この手順では,ルート・ファイル・システムは既にリストアされているものとします。
ルート・ファイル・システムのリストア方法については,6.3.4 項を参照してください。
# mount -u /
usr_domain
へのリンクを削除して,1 つ目のボリュームを使用して新しい
usr_domain
を作成します。
# rm -rf /etc/fdmns/usr_domain
# mkfdmn /dev/disk/dsk1g usr_domain
/usr
および
/var
ファイルセットを作成しマウントします。
# mkfset usr_domain usr
# mount -t advfs usr_domain#usr /usr
/usr
にソフト・リンクを作成します。
lmf
コマンドは,このディレクトリでデータベースを探すようになります。
# ln -s /var /usr/var
/usr
のバックアップ・テープをセットし,そこからリストアします。
# cd /usr
# vrestore -vi
(/) add sbin/addvol
(/) add sbin/lmf
(/) add var/adm/lmf
(/) extract
(/) quit
# /usr/sbin/lmf reset
usr_domain
にボリュームを追加します。
# /usr/sbin/addvol /dev/disk/dsk2c usr_domain
# /usr/sbin/addvol /dev/disk/dsk3c usr_domain
/usr
バックアップの完全なリストアを行います。
# cd /usr
# vrestore -xv
dsk1g
,dsk2c
,dsk3c
の 3 つのボリュームで構成されるマルチボリューム・ドメイン
usr_domain
のリストア方法を示しています。
この例では,/var
ディレクトリと
/usr
ディレクトリは
usr_domain
ドメイン内の異なるファイルセットに配置されています。
/usr
と
/var
のバックアップ・テープが存在します。
(バックアップ・テープを作成する必要がある場合は
第 4 章
を参照してください。)
この場合は,/var
と
/usr
のバックアップ・テープをともにマウントしなければなりません。
この手順では,ルート・ファイル・システムは既にリストアされているものとします。
ルート・ファイル・システムのリストア方法については,6.3.4 項を参照してください。
#
mount -u /
usr_domain
へのリンクを削除し,1 つ目のボリュームを使用して新しい
usr_domain
を作成します。
# rm -rf /etc/fdmns/usr_domain
# mkfdmn /dev/disk/dsk1g usr_domain
/usr
および
/var
ファイルセットを作成しマウントします。
# mkfset usr_domain usr
# mkfset usr_domain var
# mount -t advfs usr_domain#usr /usr
# mount -t advfs usr_domain#var /var
/var
バックアップ・テープをセットし,そこからリストアします。
# cd /var
# vrestore -vi
(/) add adm/lmf
(/) extract
(/) quit
/usr
バックアップ・テープをセットし,そこからリストアします。
# cd /usr
# vrestore -vi
(/) add sbin/addvol
(/) add sbin/lmf
(/) extract
(/) quit
# /usr/sbin/lmf reset
usr_domain
に追加します。
# /usr/sbin/addvol /dev/disk/dsk2c usr_domain
# /usr/sbin/addvol /dev/disk/dsk3c usr_domain
/usr
バックアップの完全なリストアを行います。
# cd /usr
# vrestore -xv
/var
バックアップの完全なリストアを行います。
# cd /var
# vrestore -xv
6.3.8 mkfdmn コマンドまたは addvol コマンドの誤った使用からの復旧
mkfdmn
および
addvol
コマンドは,AdvFS で使用するようにボリュームを初期化します。
そのボリュームがすでに他の AdvFS ドメインの一部である場合,このコマンドを使用するとそのボリュームに存在するドメインのメタデータを壊します。
すでに初期化したボリュームに対して,これらのコマンドを誤って使用した場合,salvage
ユーティリティに
-S
オプションを使用することで,そのファイルの一部を回復することができる場合があります。
詳細については,6.2.6.3 項を参照してください。
mkfdmn
または
addvol
コマンドを実行した後に実行したコマンドが多いほど,元のボリュームの内容にはその分だけ変更が加えられ,salvage コマンドで救済できる情報は少なくなります。
salvage
コマンドを使用しても十分な情報が得られない場合,唯一の選択肢は,バックアップからデータをリストアすることです。
6.4 問題の予防
6.4.1 未使用スペースとディスク使用状況のチェック
表 6-4: ディスク・スペースの使用状況に関するコマンド
コマンド
機能
df
[脚注 2]
[脚注 3]
ディスク・スペースの使用状況をファイルセット別に表示します。
ファイルセットが使用できるスペースは,ファイルセット・クォータが設定されている場合,それによって制限されます。
ソフトとハードの両方のクォータが設定されている場合は,そのうちの小さい方のクォータ限界値を使って,利用できるディスク・スペースの値が計算されます。
ドメインに,指定したファイルセット・クォータで利用可能な値より少ないスペースしかない場合は,このコマンドは,そのドメインで実際に使用できるスペースの値を表示します。
複数のファイルセットを含み,ファイルセット・クォータを設定していないドメインの場合,すべてのファイルセットの容量の合計が 100% を超える場合があります。
各ファイルセットで使用可能なスペースはドメイン全体であるため,この計算で使われる利用可能なスペースの数値が,ドメインの全スペースになるためです。
du
ファイルのブロック割り当てに関する情報を表示します。
-a
オプションを指定すると,個々のファイルの情報が表示されます
ls
ファイルごとにディスク・スペース使用量を表示します。
-l
オプションを指定すると,スパース・ファイルの未割り当て部分も含めて,ディスク・スペースの大きさが表示されます。
-s
オプションを指定すると,実際に割り当てられているブロック数が表示されます。
このオプションは,特にスパース・ファイルの占有領域を確認する手段として利用できます。
showfdmn
[脚注 3]アクティブなドメイン内のそれぞれのボリュームの属性とブロック使用状況を表示します。
マルチボリューム・ドメインでは,その他のボリューム情報も表示されます。
showfile
特定のファイルの,またはディレクトリ内のファイルの,ブロック使用状況とボリューム情報を表示します。
showfsets
[脚注 3]ドメイン内のファイルセットに関する情報を表示します。
-q
オプションを指定すると,ファイルセット・クォータの限界値が表示されます。
vdf
[脚注 2]
[脚注 3]showfdmn
,showfsets
,およびdf
コマンドの出力を再フォーマッティングします。
この 3 つのコマンドの機能は,vdf
コマンドにもあてはまります。df
および
showfsets
コマンドでは,メタデータとクォータ・ファイルが使用するディスク・スペースを含みません。
そこで Used フィールドには,実際にドメインが使用している容量より小さい値が示されている可能性があります。
vdf
コマンドでは,メタデータとクォータ・ファイルの情報を含むディスク使用量を表示します。
詳細については,3.4.2.4 項
とこのコマンドのリファレンス・ページを参照してください。
quotacheck
コマンドに
-v
オプションを指定して実行します。
6.4.2 ボリュームの再利用
/etc/fdmns
ディレクトリにエントリが存在する) のストレージを他のドメインに追加するには,rmvol
コマンドを使ってそのドメインからボリュームを削除して,それを他のドメインに追加します。
AdvFS は自動的にドメインのディスク使用量を更新します。
old_domain
内のボリューム
/dev/disk/dsk5c
を,ドメイン
new_domain
に追加する場合には,old_domain
内のファイルセットをすべてマウントした後,次のコマンドを実行します。
# rmvol /dev/disk/dsk5c old_domain
# addvol /dev/disk/dsk5c new_domain
disklabel
コマンドを使用せずに行なうことができます。
addvol
または
mkfdmn
コマンドの実行時に表示されるプロンプトに
yes
と答えると,ディスク・ラベルがリセットされます。
この操作を行うと,追加するディスクまたはディスク・パーティション上のすべての情報が失われます。
ディスクを他のシステムで使用するために移動したい場合は,6.3.6 項を参照してください。
6.4.3 ディスク障害
addvol
コマンドを使用して新しいディスクを追加し,rmvol
コマンドを使用して問題のあるディスクを削除することができます。
ディスクの動作状況の確認方法についての詳細は,『システム管理ガイド』のイベント管理に関する情報を参照してください。
6.4.4 ディスク使用量の制御
6.4.5 クォータ限界値と猶予期間の上限の設定
6.4.5.1 クォータ限界値の超過
tmp
などの別のファイルセットに保存し,他のファイルをいくつか削除するか,そのファイルセットのクォータを増やし,その後でファイルを元のファイルセットに戻します。
6.4.5.3 クォータ限界値の変更
/etc/fstab
ファイル (2.4.1 項) に
userquota
と
groupquota
オプションが設定されていないファイルセットに対して,クォータ限界値または猶予期間を設定しても,設定した値は保持されません。
edquota
コマンドを実行する前に,/etc/fstab
のエントリをアップデートし,ファイルセットをマウントする必要があります。
6.4.5.4 猶予期間の無効化
edquota
コマンドで値を 1 秒に設定します。
値を 0 日に設定すると,省略値の猶予期間の7 日が適用されます。
6.4.6 ディスク構造の互換性の問題の回避
/root
,/usr
,および
/var
のファイルは,DVN が 3 のままになります。
一方,Version 5.0 のフル・インストレーションを行う場合には,これらの各ディレクトリに含まれるファイルの DVN は 4 になります。
6.4.7 ユーティリティの互換性の問題の回避
advfsstat
balance
chvol
defragment
rmvol
showfdmn
verify
AdvfsDomainPanicLevel
属性 (5.7 節を参照) で,ドメイン・パニックをシステム・パニックに発展させるように設定したためにシステム・クラッシュが発生した場合,パニックが発生したドメインで
/sbin/advfs/verify
コマンドを実行して,データが損傷していないことを確認します。
クラッシュ時にファイルセットがアンマウントされていた場合,または再マウントを実行し,verify
コマンドを実行した場合,そのファイルセットを,適切であれば,異なるバージョンのオペレーティング・システムにマウントすることができます。
6.4.9 AdvFS ルート・ドメインのサイズ拡張
6.4.9.1 ルート・ボリュームのサイズ拡張
mount
コマンドに
-o extend
オプションを指定して,システムにそれを知らせる必要があります。
ルート・ボリュームが,LSM ボリュームの場合は,『Logical Storage Manager』を参照してください。
6.4.9.2 ルート・ボリュームの大きなデバイスへの移動
DKB300
が追加されています。
>>> show device
polling ncr0(NCR 53C810) slot 1, bus 0 PCI,
hose 1 A SCSI Bus ID 7
dka500.5.0.1.1 DKA500 RRD45 1645
polling isp0(QLogic ISP1020) slot 4, bus 0 PCI,
hose 1 SCSI Bus ID 7
dkb0.0.0.4.1 DKB0 RZ1DB-CA LYJ0
dkb100.1.0.4.1 DKB100 RZ1CB-CA LYJ0
dkb200.2.0.4.1 DKB200 RZ1CB-CA LYJ0
dkb300.3.0.4.1 DKB300 RZ1BB-CS 0656
mkb400.4.0.4.1 MKB400 TLZ10 02ab
...
dsk6
というデバイス名が付けられているとします。
/sbin/hwmgr
コマンドに
-flash
オプションを指定すれば視覚的に確認できます。
このコマンドを実行すると,指定したディスクのランプが 30 秒間にわたって点滅します。
# /sbin/hwmgr -flash light -dsf /dev/disk/dsk6a
/etc/fdmns
ディレクトリでルート・ドメインを含むボリュームを調べます。
# ls -l /etc/fdmns/root_domain
total 0
lrwxrwxrwx 1 root system 15 Feb 1 2002 dsk3a -> /dev/disk/dsk3a
/dev/disk/dsk3a
がルート・ドメインを含むボリュームです。
disklabel
コマンドに
-t advfs
オプションを指定して,または
diskconfig
ユーティリティを使用して (Boot Block:
リストから AdvFS を選択),新しいディスクを AdvFS のブート可能ディスクとして構成します。
この作業には root 権限が必要です。
# disklabel -r dsk6 > /tmp/backupdisklabel
# disklabel -R -r -t advfs dsk6 /tmp/backupdisklabel
# rm /tmp/backupdisklabel
>>> boot dka500
>>> boot ewa0
3) Exit Installation
を選択します。
/etc/fdmns
ディレクトリに新しいエントリを作成します。
# mkfdmn -r /dev/disk/dsk6a root_domain
# mkfset root_domain root
# mkdir /var/new_root
# mount root_domain#root /var/new_root
# mkdir /etc/fdmns/orig_root
# ln -s /dev/disk/dsk3a /etc/fdmns/orig_root
# mount orig_root#root /var/orig_root
# vdump -0f - /var/orig_root | vrestore -xf \
-D /var/new_root
dsk3
から
dsk6
に移されています。
他に変更はありません。
/etc/fdmns
ディレクトリを,新しいルート・ドメインを認識するようにアップデートします。
ここでは,dsk6a
が新しいルート・ドメインを含むボリュームであり,dsk3a
が元のルート・ドメインを含むボリュームです。
# cd /var/new_root/etc/fdmns/root_domain
# ln -s /dev/disk/dsk6a dsk6a
# rm dsk3a
# halt
. . .
>>> set bootdef_dev dkb300
>>> boot
6.4.10 メモリ・マッピング,ダイレクト I/O,およびデータ・ロギングの互換性の問題
mount
コマンドに
-o adl
オプションを指定して実行し一時的アトミック書き込みデータ・ロギングを有効にした場合を除き,メモリ・マッピング,アトミック書き込みデータ・ロギング,およびダイレクト I/O は相互に排他的です。
ファイルがこれらのモードのいずれかでオープンされている場合,同じファイルを競合するモードでオープンしようとすると失敗します。
詳細については,5.5 節,5.6 節,および
mmap
(2)smoothsync
でフラッシュされますが,smoothsync_age
によりフラッシュしない場合もあります。
これは,ファイルがマッピング解除された後で一時的にメモリ・マッピング・モードにとどまることがあることを意味します。
詳細については,『システムの構成とチューニング』 を参照してください。
6.4.11 古いデータへのアクセスの禁止
salvage
コマンドを実行した後に復旧することができます。
これらのデータがアクセスされないようにするには,chfsets
コマンドを
-o objectsafety
オプションを指定して実行します。
オブジェクト・セーフティを選択すると,アプリケーションは古いデータにアクセスできなくなりますが,データが完全に破壊されるわけではありません。
xyz_domain
のファイルセット
xyz3
のオブジェクト・セーフティを有効にするには,次のコマンドを入力します。
# chfsets -o objectsafety xyz_domain xyz3
6.4.12 無効または破損したセーブセット・フォーマット
a
またはパーティション
c
にバックアップされていないかを確認してください。
これらのパーティションにはブロック 0 が含まれています。
ブロック 0 はディスク・ラベル・ブロックであり,不慮の書き込みから保護されています。
そこで,これらのパーティションにセーブセットをバックアップしようとしても,適切に保存されません。
vdump
コマンドを実行した場合でも,コマンド出力では有効なセーブセットが含まれているように見えます。
ところが,vrestore
コマンドを実行すると,セーブセットに含まれるディスク・ラベルをセーブセットとして解釈したときに,エラーが返されます。
ディスク・パーティションへのダンプについては,4.3.7 項
を参照してください。
6.4.13 性能低下の対策
vfast
ユーティリティの実行 (5.8 節を参照)
6.4.14 rmvol または migrate コマンドを起動できない
rmvol
コマンド (2.3.5 項) を使用してボリュームの削除を実行し,そのコマンドが異常終了すると,まれにボリュームがアクセスできない状態になり,書き込みができなることがあります。
これらのボリュームには,showfdmn
コマンドの出力結果に,"data unavailable" というマークがつきます。
この場合,chvol
コマンドに
-A
オプションを指定して実行し,ボリュームを再度アクティブ化します。