1    ハードウェアの管理

本章では,ハードウェア管理モデルの概要を説明するとともに,利用可能な参考資料について解説します。以下のトピックについて取り上げます。

hwmgr コマンドを使うことによって,CPU のホットスワップのようなサービス・タスクを実施できます。この機能の詳細については, hwmgr_ops(8) と『Managing Online Addition and Removal』を参照してください。

1.1    ハードウェアの理解

ハードウェア・コンポーネントは,CPU,ネットワーク・カード,またはハードディスクのような,システムの個別の部品のことです。システムは,CPU (中央演算処理装置) を頂点とし,ディスク・ドライブやテープ・ドライブなどの周辺機器を最下層に置く階層構造になっています。これを,システム・トポロジと呼ぶこともあります。以下に述べるようなコンポーネントは,これがすべてではありませんが,ほとんどのコンピュータ・システムにある一般的なデバイスです。

ハードウェアを管理するには,すべてのコンポーネントがお互いにどのように関連し合っているか,また,システム・トポロジの中でコンポーネントが論理的および物理的にどのように位置しているか,さらにはシステム・ソフトウェアがコンポーネントをどのように認識し,それらとどのように通信しているか,を理解していなければなりません。システム・コンポーネントの位置関係をより詳しく知るためには,『システム管理ガイド』で &DNOSysManStation の紹介を参照してください。このユーティリティは,システム・コンポーネントの位置関係を表示し,その表示内容を操作できるようにするグラフィカル・ユーザ・インタフェースです。

大部分のハードウェア管理作業は自動化されています。サポートされている SCSI ディスクをシステムに追加接続してリブートすると,ディスクが自動的に検出され,システム内に構成されます。オペレーティング・システムは,必要なドライバを動的にロードし,デバイス特殊ファイルを作成します。管理者が行う必要のある作業は,必要に応じてディスクのパーティションを作成し,そのパーティションにファイル・システムを作成して (『システム管理ガイド』 で説明),データを格納できるようにすることだけです。ただし,定期的に手動で行わなければならないハードウェア管理作業はあります。たとえば,ディスクがクラッシュした場合には,代替ディスクを同じ論理位置でオンラインにしなければなりません。また,稼働中のシステムにコンポーネントを手動で追加したり,ディスクの入出力を他のディスクにリダイレクトしなければならないこともあります。

それら以外のハードウェア管理作業の多くは,ディスク・パーティションの作り直しやバスへのアダプタの追加など,標準的なシステムの操作と保守です。このような作業については,通常,コンポーネントに付属しているハードウェア・マニュアルで十分に説明されていますが,新しいコンポーネントの物理/論理位置を最適な (あるいは,より適した) 位置にするためにシステムをチェックするというような作業が必要になることもあります。

ハードウェア管理の重要な側面に,予防を目的とした保守およびモニタリング作業があります。システム環境を健全に保つには,次のようなオペレーティング・システム機能を使用します。

このマニュアルの構成は,次のように,管理するハードウェア・コンポーネントやデバイスを反映したものになっています。

観点を変えれば,汎用ツールを使って多数のコンポーネントを対象にタスクを実行できる一方で,ハードウェア別ツールを使って単一のコンポーネントのみを対象にタスクを実行することもできます。特に明記しない限り,ほとんどの操作は 1 つのシステムまたは 1 つのクラスタを対象とします。クラスタ・ハードウェアの管理についての詳細は,TruCluster サーバのドキュメントを参照してください。

1.2    参照情報

以降の各項で,ドキュメント,システム・ファイル,関連のソフトウェア・ツールに関する参照情報を示します。ここで説明するツールの中には,将来のリリースで廃止される予定のものもあります。廃止される予定のオペレーティング・システム機能の一覧を『リリース・ノート』で参照し,できるだけ早く新しいツールへ移行してください。サイト固有のシェル・スクリプトの中でこうした廃止予定のコマンドを起動していないか,チェックしてください。

1.2.1    ドキュメント

以下のドキュメントに,ハードウェア管理の情報が記載されています。

コマンド行とグラフィカル・ユーザ・インタフェースには,詳細なオンライン・ヘルプもあります。

1.2.2    Web リソース

本書で説明する手順の大半は,システム・ハードウェアや,ストレージ・デバイスなどの周辺機器の管理に関連します。ハードウェア固有のアプリケーション・ソフトウェアの使い方に関して情報が必要な場合には,ハードウェアのオーナーズ・マニュアルも参照してください。

次の Web サイトでは,ドライバのアップデート情報のような情報やリソースを提供しています。

1.2.3    ソフトウェアとアプリケーション

ローカル・システムの構成に応じて,1 つ以上のアプリケーションを使ってシステム・コンポーネントを管理します。多くの場合,これらのアプリケーションでは,システムに接続されているファイバ・チャネル・スイッチのような他のデバイスとそのローカルなコンポーネントも管理できます。利用できるアプリケーションは,対象となるストレージ・コンポーネントと,アプリケーションがサポートする Tru64 UNIX のバージョンによって異なります。プログラムの中には,ネットワークに接続された PC システム上だけで動作し,Web 接続を使ってストレージにアクセスするものもあります。また,ハードウェアにソフトウェアがバンドルされておらず,プログラムのライセンスを別に購入する必要があるかもしれません。

複雑な管理手順では,多くの場合,Tru64 UNIX のコマンドや hwmgr のようなユーティリティとともに,これらのアプリケーションを 1 つ以上使う必要があります。このような複雑な手順の例としては,マルチパス・フェールオーバのための冗長ファイバ・チャネル・ストレージの構成があります。

システム・コンポーネントは,以下のアプリケーションを使って管理します。

システム・コンソール

システム・コンソールは,AlphaServer の電源を入れたときに最初に現れるコマンド・インタフェースです。電源投入後の初期テストが正しく完了すると,システムによってコンソール・プロンプト (>>>) が表示されます。このインタフェースは,SRM (System Reference Manual) コンソールと呼びます。これは,システム・ファームウェアと呼ばれることもあります (ただし,ファームウェアには SRM に属さない他のコンポーネントも含まれます)。

コンソールを使って,システム・コンポーネントに関する情報を表示させることができます。たとえば,次のコマンドは,ローカルの SCSI バスに接続されているディスク・ドライブのバス,ターゲット,論理ユニット番号 (lun) アドレスなど,システムのハードウェア・コンポーネントに関する情報を表示します。

>>>show device

AlphaServer のオーナーズ・マニュアルでは,SRM コンソール・コマンドについて説明しています。AlphaServer システムによっては,SRM コマンドのオプションに若干の違いがあります。システムのハードウェア・マニュアルが手元になければ,次に示す Alpha Systems Technology Web サイトから印刷可能な PDF 版をダウンロードできます。 http://www.compaq.com/alphaserver/technology/index.html

使用するプロセッサのコンソールに固有の制限については,Tru64 UNIX の『リリース・ノート』を参照してください。

アレイ・コントローラ・ソフトウェアと階層性記憶域オペレーティング・ファームウェア

以下のソフトウェアは,特定のいくつかのモデルのストレージ・アレイ・コントローラで動作し,管理タスクを実行できます。

ACS または HSOF オペレーティング・ファームウェアにアップデートがあるたびに,コントローラのモデルごとに新しい PCMCIA プログラム・カードが提供されます。リリースごとにアップデート・カードを個別に購入することも,アップデート・サービス契約の一環として自動的に受け取ることもできます。ファームウェアのアップデート情報については,次の Web サイトを参照してください。

http://h18000.www1.hp.com/products/storageworks/
 

ACS と HSOF のオンライン・ドキュメントは,次の Web サイトで参照できます。

http://h18000.www1.hp.com/products/storageworks/
 

SWCC (StorageWorks Command Console)

SWCC (StorageWorks Command Console) は,EMA12000 と EMA16000 RAID アレイを対象とした,ストレージの構成とモニタリングのための視覚的なツールです。このツールは,ストレージ管理をポイント・アンド・クリック式の単純な操作で行えるようにし,単独の管理コンソールからストレージを視覚的に構成したりモニタリングしたりできるようにします。SWCC 2.3 は,Tru64 UNIX Version 4.0F 以降を対象とするエージェントを提供します。

SWCC の情報については,次の Web サイトを参照してください。

http://h18000.www1.hp.com/products/storageworks/
 

ストレージ・エリア・ネットワーク (SAN)

HP は,数が増えているいくつかのソフトウェア・アプリケーションを通じて SAN の管理をサポートしています。表 1-1 に,本書発行時点で入手可能なアプリケーションのいくつかを示します。いくつかのアプリケーションは,ネットワークに接続された SAN アプライアンスで動作し,別のソフトウェア・コンポーネントに依存することがあります。他の SAN ツールは,特定のバージョンのオペレーティング・システムを対象としたエージェントだけを提供します。その場合には,Tru64 UNIX で動作するエージェント・プログラムにコマンドを発行する,アプライアンス (または PC) 上で動作するインタフェースを通じてハードウェアを管理することになります。

表 1-1:  SAN ソフトウェア

名称 説明
SANworks Command Scripter HSJ80,HSG60,HSG80,HSZ70 および HSZ80 アレイ・コントローラをコマンド制御できるようにします。CLI (Command Line Interpreter) コマンドを含むスクリプト・ファイルの作成,編集,実行ができます。この製品は,ローカルな LAN 接続と,リモート接続のためのブラウザ・インタフェースの両方を提供します。このアプリケーションは,SWCC との組み合わせで動作します。
SANworks Data Replication Manager (DRM) ハードウェア冗長性と,距離の離れた複数のサイトの間でデータを複製することによるデータ・レプリケーション機能を提供することによって,耐災害性を実現します。距離の離れている DRM サイトの間は,光ファイバ・ケーブルまたは ATM (非同期転送モード) で結ばれます。DRM は,ファイバ・チャネル・ギガビット・スイッチを使ってサイト間でデータを転送します。
SANworks Element Manager for StorageWorks HSG HSG コントローラでストレージを一元管理するための,構成とモニタリングを行う Web ベースの視覚的なツールです。
SANworks Enterprise Volume Manager この Web ベースのアプリケーション・ソフトウェアを使って,コントローラでのクローン操作とスナップショット操作を管理できます。
SANworks Network View SAN のトポロジを自動的にマッピングし,アベイラビリティを監視し,ストレージ環境のマップを表示するブラウザ・ベースのアプリケーションです。
SANworks Open SAN Manager Open SAN 向けに,集中化された,アプライアンス・ベースのモニタリングと管理のためのインタフェースを提供します。このインタフェースを使って,SAN 内の一箇所からストレージの編成,表示,構成,および監視ができます。また,SANworks アプリケーションを起動するための手段と,SAN 内のストレージ・コンポーネントを直接管理するためのリンクも提供します。

SAN ソフトウェアとドライバに関する情報については,次の Web サイトを参照してください。

http://www.compaq.com/storage/

Media Robot Utility (MRU)

DLT や,4mm (DAT) または TKZ シリーズのローダなどのオートローダを制御するためのアプリケーションです。

1.2.4    関連コマンドとユーティリティ

デバイスの管理に使用できるコマンドは,次のとおりです。

1.3    ハードウェア管理のためのシステム・ファイル

次に示すシステム・ファイルには,コンポーネントを構成してカーネルへ組み込む場合にシステムで使用する静的情報または動的情報が含まれています。これらのファイルは,ASCII テキスト・ファイルであっても,編集しないでください。ファイルの中には,『システム管理ガイド』で説明するようなコンテキスト依存シンボリック・リンク (CDSL) もあります。リンクが切れると,そのリンクを検証して再度作成するまでは,クラスタ・システムでそのファイルを使用できなくなります。CDSL の再作成については, cdslinvchk(8) および mkcdsl(8) を参照してください。

注意

ハードウェア・データベースの中にはテキスト形式のものもありますが,データベースを編集してはなりません。データベースに誤りがあると,システムがデバイスにアクセスできなくなったり,データが損傷を受けたり,システムが起動できなかったりすることがあります。デバイスの管理には,適切なコマンドとユーティリティだけを使うようにしてください。

1.4    WWID と共用デバイス

SCSI デバイスの命名は,デバイスの論理識別子 (ID) に基づいて行われます。SCSI デバイスのデバイス特殊ファイル名と物理位置の間に相関関係はありません。UNIX はデバイスからの情報を用いてワールドワイド識別子という ID (通常は WWID と表記) を作成します。

デバイスの WWID が一意に定まり,システムに取り付けられた各 SCSI デバイスの ID を識別できるのが理想です。しかし,一部の古いディスクでは,情報が不足していて,特定のデバイスに一意の WWID を作成できないことがあります (他社製の新しいディスクでもこうしたものがあります)。このようなデバイスに対しても,オペレーティング・システムは WWID を生成しようとします。極端な場合にはデバイスの接続情報 (SCSI バス/ターゲット/LUN) を用いてデバイスの WWID を作成します。

したがって,一意の WWID を持たないデバイスは共用バスで使わないようにしてください。一意の WWID を持たないデバイスを共用バスに接続すると,そのデバイスへの異なるパスごとに異なるデバイス特殊ファイルが作成されます。このような場合,オペレーティング・システムが 2 つの異なるデバイス特殊ファイルを用いて同じデバイスに同時にアクセスして,データが損傷受ける可能性があります。デバイスがクラスタの中で一意な WWID を持っているかどうかは,次のコマンドで調べます。

#  /sbin/hwmgr show components

デバイスの FLAGS フィールドに c フラグがセットされていれば,クラスタ内で一意の WWID があるので,共用バスに置くことができます。このようなデバイスはクラスタ内の共用バスに置くことができるため,「クラスタ内共用可」といいます。

注意

HSZ デバイスにはこの規則はあてはまりません。HSZ デバイスがクラスタ内共用可とマークされていても,HSZ のファームウェアの中には,複数のイニシエータがデバイスを同時にアクセスできないようにしているバージョンがあります。現在の制限については,HSZ デバイスのオーナーズ・マニュアルと Tru64 UNIX 『リリース・ノート』を参照してください。

次の例は,ハードウェア・コンポーネントのうち,クラスタ内で一意の WWID を持つものをすべて表示させたものです。

# /sbin/hwmgr show component -cshared
HWID:HOSTNAME FLAGS SERVICE COMPONENT NAME
-----------------------------------------------
35:   pmoba    rcd-- iomap   SCSI-WWID:0410004c:"DEC  RZ28     ..."
36:   pmoba    -cd-- iomap   SCSI-WWID:04100024:"DEC  RZ25F    ..."
42:   pmoba    rcd-- iomap   SCSI-WWID:0410004c:"DEC  RZ26L    ..."
43:   pmoba    rcds- iomap   SCSI-WWID:0410003a:"DEC  RZ26L    ..."
48:   pmoba    rcd-- iomap   SCSI-WWID:0c000008:0000-00ff-fe00-0000
49:   pmoba    rcd-- iomap   SCSI-WWID:04100020:"DEC  RZ29B    ..."
50:   pmoba    rcd-- iomap   SCSI-WWID:04100026:"DEC  RZ26N    ..."

一意の WWID を持っていないデバイスでも,共用バス上で利用可能にしなければならないことがあります。このようなデバイスは共用バスで使用しないほうが良いのですが,共用バス上でこれを構成する方法があります。hwmgr edit scsi コマンド・オプションを使って一意の WWID を作成する方法については,第 3 章を参照してください。

1.5    デバイスの命名とデバイス特殊ファイル

デバイスは,/dev ディレクトリにあるデバイス特殊ファイルを通して,システムの他の部分から使用できるようになっています。デバイス特殊ファイルにより,アプリケーション (データベース・アプリケーションなど) はデバイス・ドライバを通してデバイスにアクセスできます。個々のデバイス・ドライバは,特定の種類のハードウェア・コンポーネントを 1 つまたは複数制御するカーネル・モジュールです。ここで言うデバイスとは,たとえば,ネットワーク・コントローラ,グラフィックス・コントローラ,ディスク (CD-ROM デバイスを含む) などが該当します。

システムは,ハードウェア・コンポーネントを制御しない擬似デバイス・ドライバへアクセスするのにもデバイス特殊ファイルを使います。たとえば,擬似端末 (pty) の端末ドライバは端末デバイスをシミュレートします。端末ドライバ pty は文字型ドライバであり,一般に,リモート・ログインに使用します。これについては,第 4 章 で説明しています デバイス・ドライバの詳細な情報については,次の URL にあるデバイス・ドライバのドキュメントを参照してください。http://h30097.www3.hp.com/docs/pub_page/devdoc_list.html

通常,デバイス特殊ファイルの管理はシステムが自動的に行います。たとえば,UNIX オペレーティング・システムの新バージョンをインストールする場合,あるタイミングでシステムがすべてのバスとコントローラを調べ,システム・デバイスをすべて検出します。次に,システムは検出したデバイスを記述するデータベースを構築し,デバイス特殊ファイルを作成して,ユーザが使用できるようにします。デバイス特殊ファイルを使用する最も一般的な方法は,それをシステムの /etc/fstab ファイルに UFS ファイルの位置として指定することです。

デバイス特殊ファイルの操作を手動で実行しなければならないのは,システムに問題がある場合と自動的に処理できないデバイスをサポートしなければならない場合のみです。この節では,バージョン 5.0 以降でデバイスとデバイス特殊ファイルに名前を割り当て構成する方法について説明します。

次の点に注意してください。

旧式のデバイス名およびデバイス特殊ファイルはしばらく維持されます。廃止予定については,将来のリリースでお知らせします。

1.5.1    関連ドキュメントとコマンド

次のドキュメントに,デバイス名に関する情報があります。

1.5.2    デバイス特殊ファイルのディレクトリ

デバイス特殊ファイルを入れるために,/devices ディレクトリがルート・ディレクトリ (/) の下に作成されています。このディレクトリにはサブディレクトリがあり,その中にそのデバイス・クラスのデバイス特殊ファイルが置かれます。デバイス・クラスは,同類のデバイスをまとめたタイプ (ディスクや非巻戻し型テープ・デバイスなど) に対応しています。たとえば,/dev/disk ディレクトリには,サポートされているすべてのディスクに対するファイルが置かれ,/dev/ntape ディレクトリには非巻戻し型テープ・デバイスに対するデバイス特殊ファイルが置かれます。このリリースの場合,作成されているサブディレクトリは一部のクラスのみです。どの操作の場合でも,/devices ディレクトリではなく /dev ディレクトリを用いてパスを指定する必要があります。

注意

いくつかのデバイス特殊ファイル・ディレクトリは CDSL です。システムがクラスタの一部のとき,クラスタ単位でデバイスを使用可能にします。『システム管理ガイド』で示すファイル・システム階層 (特に CDSL のインプリメント) について良く理解しておく必要があります。

/dev ディレクトリには,/devices ディレクトリのサブディレクトリに対応するシンボリック・リンクがあります。たとえば,次のようになっています。

lrwxrwxrwx 1 root system 25 Nov 11 13:02 ntape -> ../../../../devices/ntape

lrwxrwxrwx 1 root system 25 Nov 11 13:02 rdisk -> ../../../../devices/rdisk

lrwxrwxrwx 1 root system 24 Nov 11 13:02 tape -> ../../../../devices/tape

このような構造になっていることによって,システムがクラスタのメンバになっているときに,特定のデバイスをホスト固有にできます。そしてそれ以外のデバイスを,クラスタの全メンバで共用できます。また,デバイス・ドライバの開発者やコンポーネント・ベンダが,新しいデバイス・クラスを追加することもできます。

1.5.2.1    擬似デバイスと非ストレージ・デバイス

デバイスと,それらに関連付けられているデバイス特殊ファイルを管理するにあたって,システムの /dev ディレクトリに何があるかを知っていると役立ちます。/dev ディレクトリには,次の出力例に示すように,多数のデバイスがあります。

# ls -l
total     47
drwx------   2 root     system           512 Jun  5 15:55 .audit
-rwxr-xr-x   1 bin      bin            34777 Jun 19 00:02 MAKEDEV
-rw-r--r--   1 root     system          2238 Jun 28 16:42 MAKEDEV.log
-rwxr-xr-x   1 bin      bin             1418 Jun 19 00:02 SYSV_PTY
-rwxr-xr-x   1 bin      bin             1418 Aug  1  2001 SYSV_PTY.PreUPD
crw-------   1 root     system    47,      0 May 30 17:16 atm_cmm
crw-rw-rw-   1 root     system    87,      0 May 30 17:16 aud97
cr--------   1 root     system    17,      0 May 30 16:45 audit
srw-rw----   1 root     system             0 Jul 25 13:40 binlogdmb
crw-------   1 root     system    30,      0 May 30 16:45 cam
lrwxrwxrwx   1 root     system            27 May 30 17:16 changer -> \
../../../../devices/changer
crw--w--w-   1 root     daemon     0,      0 Jul 25 13:44 console
-rw-r--r--   1 root     system            12 Jul 25 13:39 console.gen
lrwxrwxrwx   1 root     system            25 May 30 17:16 cport -> \
../../../../devices/cport
lrwxrwxrwx   1 root     system            24 May 30 17:16 disk -> \
../../../../devices/disk
lrwxrwxrwx   1 root     system            25 May 30 17:16 dmapi -> \
../../../../devices/dmapi
crw-------   1 root     system    31,      0 Jul 26 13:43 kbinlog
crw-------   1 root     system     3,      1 May 30 16:45 kcon
crw-------   1 root     system    82,      0 May 30 17:16 kevm
crw-------   1 root     system    82,      2 May 30 17:16 kevm.pterm
crw-rw----   1 root     system    25,      1 May 30 16:45 keyboard0
crw-------   1 root     system     3,      0 May 30 16:45 klog
cr--r-----   1 root     mem        2,      1 May 30 16:45 kmem
drwxr-xr-x   2 root     system           512 May 12 18:14 lat
cr--r-----   1 root     mem       45,      0 May 30 16:45 lockdev
srw-rw-rw-   1 root     system             0 Jul 25 13:40 log
crw-rw-rw-   1 root     system    34,      0 May 30 17:16 lp0
cr--r-----   1 root     mem        2,      0 May 30 16:45 mem
crw-rw-rw-   1 root     system    88,      0 May 30 17:16 mmsess0
crw-rw----   1 root     system    23,      1 May 30 16:45 mouse0
crw-rw-rw-   1 root     system    52,      0 May 30 17:16 msb0
lrwxrwxrwx   1 root     system            15 May 30 17:16 none -> \
../devices/none
lrwxrwxrwx   1 root     system            25 May 30 17:16 ntape -> \
../../../../devices/ntape
crw-rw-rw-   1 root     system     2,      2 Jul 26 13:28 null
cr--r--r--   1 root     system    26,      0 May 30 16:45 pfcntr
crw-rw-rw-   1 root     system    32,     58 May 30 17:16 pipe
crw-rw-rw-   1 root     system    46,      0 May 30 16:45 poll
crw-------   1 root     system    37,      0 May 30 16:45 prf
srwxrwxrwx   1 root     system             0 Jul 25 13:43 printer
crw-rw-rw-   2 root     system    32,      7 May 12 18:12 ptm
crw-rw-rw-   1 root     system    32,     65 Jun 28 17:14 ptmx
crw-rw-rw-   2 root     system    32,      7 May 12 18:12 ptmx_bsd
drwxr-xr-x   2 root     system           512 May 12 18:12 pts
crw-rw-rw-   1 root     system     7,     31 May 30 16:45 ptyqf
crw-rw-rw-   1 root     system    89,      0 May 30 17:16 random
lrwxrwxrwx   1 root     system            25 May 30 17:16 rdisk -> \
../../../../devices/rdisk
drwxr-xr-x   2 root     system           512 May 30 17:16 sad
crw-------   1 root     system    80,1048575 May 30 17:16 scp_scsi
crw-rw-rw-   2 root     system    32,     49 May 12 18:12 snmpinfo
drwxr-xr-x   3 root     system           512 May 30 17:21 streams
crw-r--r--   1 root     system    15,      0 May 30 16:45 sysdev0
lrwxrwxrwx   1 root     system            24 May 30 17:16 tape -> \
../../../../devices/tape
crw-rw-rw-   1 root     system     1,      0 May 30 16:45 tty
crw-rw-rw-   1 root     system    35,      0 May 30 17:16 tty00
crw-rw-rw-   1 root     system    89,      1 Jul 25 13:39 urandom
crw-r-----   1 root     mem        2,      5 May 30 16:45 vmzcore
crw-rw----   1 root     system    33,      1 May 30 16:45 ws0
crw-rw-rw-   1 root     system    38,      0 May 30 16:45 zero
 
 

上記のリストでは,重複するデバイスの種類は除いてあります。ディレクトリには,端末 (ttys),擬似端末 (ptys),ディスク・ストレージ・デバイス (dsk) など多数のデバイスが含まれています。デバイスの数と種類は,システムのハードウェアおよびソフトウェアの構成によって異なります。これらのデバイスの大半は,オペレーティング・システムとアプリケーションが必要とするもので,ストレージに関係しません。最も頻繁に管理の対象になるのが,ディスク,テープ,ネットワーク・カードなど,データ入出力を伴うデバイスです。

頻繁に管理するデバイスとコントローラの一覧を表示するには,hwmgr show devices コマンドを使います。このコマンドの出力には,dsfmgr または hwmgr コマンドを使って管理できない入出力デバイスは含まれません。hwmgr show devices コマンドの出力には,SCSI カード,ファイバ・チャネル,ストレージ・アレイ・コントローラなどのデバイスに関連する dev/cport/scp2 のようなストレージ・デバイスも含まれます。dev/changer/mc* のエントリは,テープ交換デバイスに対応します。

デバイスの一覧を表示するには,次の hwmgr コマンドを使用します。

# hwmgr view dev
 HWID: Device Name          Mfg      Model            Location
 ------------------------------------------------------------------------
    6: /dev/dmapi/dmapi
    7: /dev/scp_scsi
    8: /dev/kevm
   53: /dev/cport/scp5               SWXCR            xcr0
   54: /dev/disk/dsk1197c            SWXCR            ctlr-0-unit-0
   69: /dev/disk/floppy53c           3.5in floppy     fdi0-unit-0
   46: /dev/disk/dsk1155c   DEC      HSG80            bus-4-targ-2-lun-17
   79: /dev/disk/dsk6c      DEC      HSZ22    (C) DEC bus-0-targ-0-lun-5
   81: /dev/random
   82: /dev/urandom
   84: /dev/ntape/tape11    COMPAQ   SDT-10000        bus-5-targ-0-lun-0
   90: /dev/disk/dsk1194c   COMPAQ   BD009122C6       bus-2-targ-0-lun-0
   91: /dev/disk/dsk1195c   COMPAQ   BD009122BA       bus-2-targ-1-lun-0
  871: /dev/disk/dsk1180c   DEC      HSG80            bus-4-targ-2-lun-13
  122: /dev/changer/mc1              TL800    (C) DEC bus-4-targ-0-lun-10
  127: /dev/cport/scp2               DATA ROUTER      bus-4-targ-0-lun-0
  128: /dev/cport/scp3               HSG80CCL         bus-4-targ-2-lun-0
  129: /dev/cport/scp4               HSV110 (C)COMPAQ bus-4-targ-4-lun-0
  926: /dev/ntape/tape0     COMPAQ   DLT8000          bus-4-targ-0-lun-8
  927: /dev/ntape/tape1     COMPAQ   DLT8000          bus-4-targ-0-lun-9
  942: /dev/disk/dsk1199c   COMPAQ   HSV110 (C)COMPAQ IDENTIFIER=1001
  687: /dev/disk/cdrom53c   COMPAQ   CDR-8435         bus-6-targ-0-lun-0

上記の出力例からは,類似のディスク・ストレージ・デバイスは除いてあります。この出力には,/dev/kevm (カーネル・イベント・マネージャ) のように,一部のカーネル・サブシステム擬似デバイスが含まれていますが,無数にある端末と擬似端末は含まれていません。/dev/kevm のようなカーネル・サブシステムについての情報は,システム属性 (sys_attrs*) のリファレンス・ページにあります。 sys_attrs(5) を参照してください。/dev/random のような他の擬似デバイスについては,リファレンス・ページに説明があります。特定のデバイスに関するリファレンス・ページを探すには,次の例に示すように apropos コマンドを使います。

# apropos random
.
.
random, urandom (4)     - Kernel random number source devices
# apropos disk
.
.
disk, dsk, cdrom, rz (7)  - SCSI disk interface

1.5.2.2    旧式のデバイス特殊ファイル名

旧式のデバイス命名規則に従えば,デバイス特殊ファイルはすべて /dev ディレクトリに置くことになります。デバイス特殊ファイル名は,デバイスの種類,物理的な位置,およびその他のデバイス属性を表してます。古い規則を使用するディスクやテープ・ドライブのデバイス特殊ファイル名は,たとえば,SCSI ディスクの /dev/rz14f やテープ・ドライブの /dev/rmt0a といったファイル名の形式をとります。名前には,次のような情報が含まれます。

パス 接頭語 タイプ 番号 (インスタンス) 接尾語
/dev r (raw) rz (ディスク) 0 c (パーティション)
/dev (巻戻し) rmt (テープ) 4 a (密度)
/dev n (非巻き戻し) rmt (テープ) 12 h (密度)

この情報は,次のように解釈されます。

パスは,デバイス特殊ファイルが置かれるディレクトリです。デバイス特殊ファイルはすべて /dev ディレクトリに置かれます。

接頭語は,次のように,同じ物理デバイスでもそのデバイス特殊ファイルとしての性質 (型) が異なる場合,その違いを区別します。

タイプは,2 文字または 3 文字のドライブ名です。SCSI ディスク・デバイスは rz,テープ・デバイスは rmt になります。

次に示すように,番号はデバイスのユニット番号です。

接尾語は,次のように同じ物理デバイスに対する複数のデバイス特殊ファイルを区別します。

スクリプトが期待どおりに動作するように,旧式のデバイス命名規則がサポートされています。しかし,新しいデバイス命名規則を通じて使用できる機能は,旧式の命名規則と組み合わせて使うとうまく動かないないことがあります。バージョン 5.0 以降をインストールする場合,インストール時に旧式のデバイス特殊ファイル (rz13d など) が作成されることはありません。旧式のデバイス特殊ファイル命名規則が必要な場合は, dsfmgr(8) の説明にある適切なコマンドを用いて旧式のデバイス特殊ファイル名を作成しなければなりません。旧式のデバイス特殊ファイルをサポートしないデバイスもあります。

1.5.2.3    新しいデバイス特殊ファイル名

現在のデバイス特殊ファイルには,抽象的なデバイス名が使われており,デバイスの構造やデバイスへの論理パスについての情報は何も得られません。新しいデバイス命名規則は,デバイスの種類を表す名前とインスタンス番号で構成されています。表 1-3 に示すように,この 2 つが,デバイスのベース名の要素になります。

表 1-3:  新しいデバイス特殊ファイル名の例

/dev 内の位置 デバイス名 インスタンス ベース名
/disk dsk 0 dsk0
/rdisk dsk 0 dsk0
/disk cdrom 1 cdrom1
/tape tape 0 tape0

デバイス名を,システムが割り当てるインスタンス番号と組み合わせて,dsk0 のようなベース名が作成されます。

現在のデバイス特殊ファイルはデバイスのベース名を使って命名され,対象デバイスに関するより詳しい情報を伝える接尾語が含まれます。接尾語は,次のようにデバイスの種類によって異なります。

1.5.2.4    デバイス特殊ファイル名の変換

デバイス特殊ファイルを対象とするコマンドを使用するシェル・スクリプトがある場合には,その中で使用しているオペレーティング・システム付属のコマンドやユーティリティごとに,新しいファイル名と旧式のファイル名に対するサポートが次のように異なるので,注意してください。

ただし,どのデバイスも形式の異なるデバイス名を同時に使用することはできません。シェル・スクリプトがデバイス命名方法に適合しているかテストしてください。コマンドのリファレンス・ページやオンライン・ヘルプを参照してください。

スクリプトを更新する場合は,旧式の名前から対応する新しい名前へ簡単に変換できます。旧式のデバイス名と,それに対応する新しいデバイス名の例をいくつか,表 1-4 に示します。インスタンス番号どうしは何も関係もありません。したがって,旧式のデバイス特殊ファイル /dev/rz10b を,現在のシステムの /dev/disk/dsk2b に対応付けることができます。

これらの名前を例として使用すれば,スクリプトにあるデバイスは変換できるはずです。 dsfmgr(8) コマンドを使ってデバイス名を変換することもできます。

表 1-4:  デバイス名の変換例

旧式のデバイス特殊ファイル名 新しいデバイス特殊ファイル名
/dev/rmt0a /dev/tape/tape0
/dev/rmt1h /dev/tape/tape1_d1
/dev/nrmt0a /dev/ntape/tape0_d0
/dev/nrmt3m /dev/ntape/tape3_d2
/dev/rz0a /dev/disk/dsk0a
/dev/rz10g /dev/disk/dsk10g
/dev/rrz0a /dev/rdisk/dsk0a
/dev/rrz10b /dev/rdisk/dsk10b

1.5.3    デバイス特殊ファイルの管理

ほとんどの場合,デバイス特殊ファイルの管理はシステム自身が行います。オペレーティング・システムを最初にフル・インストールする際,そのシステムで検出された SCSI ディスクと SCSI テープ・デバイスごとにデバイス特殊ファイルが作成されます。アップデート・インストレーションによってオペレーティング・システムを旧バージョンから更新した場合,新しいデバイス特殊ファイルと旧式のデバイス特殊ファイルが混在している可能性があります。ただし,その後で新しい SCSI デバイスを追加すると,特に指定しない限り,dsfmgr コマンドは新しいデバイス特殊ファイルのみを作成します。システムをリブートすると,ブート・シーケンスで dsfmgr コマンドが自動的に呼び出され,デバイスに対する新しいデバイス特殊ファイルを作成します。また,システムは,pty (擬似端末) のような擬似デバイスに必要なデバイス特殊ファイルも自動的に作成します。

SCSI ディスクまたはテープ・デバイスをシステムに追加すると,新しいデバイスが自動的に検出されて認識され,ハードウェア管理データベースに追加され,デバイス特殊ファイルが作成されます。新しいデバイスを追加した後に行う最初のリブートでは,ブート・シーケンスで dsfmgr コマンドが自動的に呼び出され,そのデバイスのデバイス特殊ファイルが作成されます。

旧式のデバイス名でしか動作しないアプリケーションをサポートする場合,既存のすべてのデバイスについて,または,最近追加したデバイスについてのみ,旧式のデバイス特殊ファイルを手動で作成する必要があるかもしれません。しかし,ファイバ・チャネルなどの機能をサポートする最近のデバイスには,新しい特殊ファイル命名規則しか使用できないものがあります。

以降の項で,dsfmgr コマンドの一般的な使い方を説明します。コマンド構文についての詳細は, dsfmgr(8) を参照してください。デバイス特殊ファイルを作成するためにブート時に実行されるシステム・スクリプト・ファイル /sbin/dn_setup は,dsfmgr コマンド・オプションの使い方の例を示します。

1.5.3.1    一般的な操作の実行 (dn_setup)

/sbin/dn_setup スクリプトは,デバイス特殊ファイルを作成するために,システムの起動時に自動的に実行されます。/sbin/bcheckrc ユーティリティも,システム起動時にデバイス特殊フィルの確認をします。/sbin/bcheckrc によって何らかの問題が検出されると,コンソールに次のメッセージが表示されます。

bcheckrc: Device Naming failed initial check.
    Run dsfmgr -v, and if no errors are 
    reported, exit or type CTRL-D to continue
    booting normally.

通常は dn_setup コマンドを実行する必要はありません。デバイス名に関する問題のトラブルシューティングや,壊れたデバイス特殊ファイル・ディレクトリあるいはデータベース・ファイルの復元に役立ちます (1.5.3.3 項も参照してください)。システム構成を頻繁に変更したり,別のバージョンのオペレーティング・システムをインストールした場合は,システムの起動中に,システム・コンソールにデバイス関連のエラー・メッセージが表示されることがあります。これらのメッセージは,デバイス特殊ファイル名を割り当てることができないことを示す場合があります。この問題は,保存されている構成を現在の構成に対応付けることができない場合に発生する可能性があります。また,インストレーションとインストレーションの間にデバイスの追加や削除を行った場合にもこの問題が発生することがあります。

管理者が使って便利なオプションは,-sanity_check だけです。デバイス名データベースを検証するには,次のコマンドを入力します。

# /sbin/dn_setup -sanity_check
Passed.

Passed 以外のメッセージが表示された場合には,dsfmgr コマンドを使ってデバイス名データベースの検証と修復を行います。問題が深刻で正常にブートできない場合には,技術サポート担当者によって,デバッグと問題解決のための他のコマンドを使うように指示されることがあります。 dn_setup(8) を参照してください。

1.5.3.2    デバイス・クラスとカテゴリの表示

システムにあるデバイスのタイプはすべて,「Category to Class-Directory,Prefix Database」ファイル /etc/dccd.dat で個々に識別できます。これらのデータベース内の情報は,dsfmgr コマンドを使って表示できます。この情報から,システムにどのようなデバイスがあるかがわかります。また,他の dsfmgr コマンド・オプションで使用できるデバイス識別属性を知ることもできます。たとえば,ディスク・デバイスである,というように,物理的な特性が互いに関連するデバイスのクラスを見つけることができます。デバイスの各クラスは,/dev の下に独自のディレクトリを持っています (非巻き戻し型テープ・デバイスの /dev/ntape など)。デバイス・クラスは,「Device Class Directory Default Database」ファイル /etc/dcdd.dat に格納されています。

データベースのエントリを表示するには,次のコマンドを使用します。

# /sbin/dsfmgr -s

dsfmgr:show all datum for system at /
 
Device Class Directory Default Database:
     # scope mode  name
    --  ---  ----  -----------
     1   l   0755  .
     2   c   0755  disk
     3   c   0755  rdisk
     4   c   0755  tape
     5   c   0755  ntape
     6   l   0755  none
 
Category to Class-Directory, Prefix Database:
 #   category       sub_category   type        directory  iw  t mode prefix
--   -------------- -------------- ----------  ---------  --  - ---- --------
 1   disk           cdrom          block       disk        1  b 0600 cdrom
 2   disk           cdrom          char        rdisk       1  c 0600 cdrom
 3   disk           floppy         block       disk        1  b 0600 floppy
 4   disk           floppy         char        rdisk       1  c 0600 floppy
 5   disk           floppy_fdi     block       disk        1  b 0666 floppy
 6   disk           floppy_fdi     char        rdisk       1  c 0666 floppy
 7   disk           generic        block       disk        1  b 0600 dsk
 8   disk           generic        char        rdisk       1  c 0600 dsk
 9   parallel_port  printer        *           .           1  c 0666 lp
10   pseudo         kevm           *           .           0  c 0600 kevm
11   tape           *              norewind    ntape       1  c 0666 tape
12   tape           *              rewind      tape        1  c 0666 tape
13   terminal       hardwired      *           .           2  c 0666 tty
14   *              *              *           none        1  c 0000 unknown
 
Device Directory Tree:
   12800    2 drwxr-xr-x  6 root system 2048 May 23 09:38 /dev/.
     166    1 drwxr-xr-x  2 root system  512 Apr 25 15:58 /dev/disk
    6624    1 drwxr-xr-x  2 root system  512 Apr 25 11:37 /dev/rdisk
     180    1 drw-r--r--  2 root system  512 Apr 25 11:39 /dev/tape
    6637    1 drw-r--r--  2 root system  512 Apr 25 11:39 /dev/ntape
     181    1 drwxr-xr-x  2 root system  512 May  8 16:48 /dev/none
 
Dev Nodes:
 13100  0 crw-------  1 root system 79,  0 May  8 16:47 /dev/kevm
 13101  0 crw-------  1 root system 79,  2 May  8 16:47 /dev/kevm.pterm
 13102  0 crw-r--r--  1 root system 35,  0 May  8 16:47 /dev/tty00
 13103  0 crw-r--r--  1 root system 35,  1 May  8 16:47 /dev/tty01
 13104  0 crw-r--r--  1 root system 34,  0 May  8 16:47 /dev/lp0
   169  0 brw-------  1 root system 19, 17 May  8 16:47 /dev/disk/dsk0a
  6627  0 crw-------  1 root system 19, 18 May  8 16:47 /dev/rdisk/dsk0a
   170  0 brw-------  1 root system 19, 19 May  8 16:47 /dev/disk/dsk0b
  6628  0 crw-------  1 root system 19, 20 May  8 16:47 /dev/rdisk/dsk0b
   171  0 brw-------  1 root system 19, 21 May  8 16:47 /dev/disk/dsk0c
    
.
.
.

この表示から,他の dsfmgr コマンドで使える情報を得ることができます (データベースのフィールドについての完全な説明は dsfmgr(8) を参照してください)。たとえば,次のような情報があります。

1.5.3.3    データベースの検証と修復

異常な状況では,デバイス・データベースが壊れたり,デバイス特殊ファイルが間違ってシステムから削除されてしまうことがあります。デバイスを使用できないというエラーが表示されているにもかかわらず,デバイス自体は故障しているように見えないこともあります。デバイス特殊ファイルに問題がありそうな場合は,dsfmgr -v (検証) コマンド・オプションを用いてデータベースをチェックします。

注意

システムの起動時にデバイス名の問題を示すエラー・メッセージが表示された場合は,ブートを継続できるように,検証コマンド・オプションを使用しなければなりません。データベースの検証前と検証後に,システム構成をチェックしてください。検証手続きによって,大半の問題が解決され,ブートを継続できます。ただし,検証オプションによってデバイス自身の問題や構成の問題は解決できません。

このような問題はまれで,主に通常と異なる操作 (ブート・ディスクの切り替えなど) を行った場合に発生します。エラーは一般的に,システムが回復不能で,正しく動作する最新の構成のコピーが使用できなかったことを意味します。また,エラーが発生するのは,一般的に,現在のシステム構成がデータベースに合わなくなった場合です。

システムを壊す可能性のあるシステム操作をするときは,システムを直前の構成と同じ状態に戻せて,バックアップから直前のバージョンのオペレーティング・システムを復元できるようにしなければなりません。

たとえば,mtools コマンドが使えるようにフロッピィ・ディスク・デバイスを構成しようとしたが,デバイスにアクセスできなくなったとします。その場合,次の dsfmgr コマンドを使用して,問題を診断するために役立てます。

# /sbin/dsfmgr -v
dsfmgr:verify all datum for system at /
 
Device Class Directory Default Database:
    OK.
 
Device Category to Class Directory Database:
    OK.
 
Dev directory structure:
    OK.
 
Dev Nodes:
    ERROR:device node does not exist: /dev/disk/floppy0a
    ERROR:device node does not exist: /dev/disk/floppy0c
  Errors:   2
 
Total errors:  2

この出力から,問題のフロッピィ・ディスク・デバイスに対応するデバイス特殊ファイルがないことがわかります。この問題を解決するために,同じコマンドに -F (修復) フラグを指定して,次のようにエラーを修正します。

# /sbin/dsfmgr -v -F
 
dsfmgr:verify all datum for system at /
 
Device Class Directory Default Database:
    OK.
 
Device Category to Class Directory Database:
    OK.
 
Dev directory structure:
    OK.
 
Dev Nodes:
    WARNING:device node does not exist: /dev/disk/floppy0a
    WARNING:device node does not exist: /dev/disk/floppy0c
    OK.
 
Total warnings:  2

この例では,ERRORWARNING に変わり,フロッピィ・ディスクのデバイス特殊ファイルが自動的に作成されることを示しています。dsfmgr -v コマンドをもう一度実行しても,エラーはもう表示されません。

1.5.3.4    デバイス特殊ファイルの削除

デバイスをシステムから恒久的に取り外した場合,そのデバイスのデバイス特殊ファイルを削除して,他の種類のデバイスに再度割り当てることができます。次の例に示すように,dsfmgr -D コマンド・オプションを使用してデバイス特殊ファイルを削除します。

# ls /dev/disk
cdrom0a   dsk0a     dsk0c     dsk0e     dsk0g     floppy0a
cdrom0c   dsk0b     dsk0d     dsk0f     dsk0h     floppy0c
 
#  /sbin/dsfmgr -D /dev/disk/cdrom0*
 -cdrom0a -cdrom0a -cdrom0c -cdrom0c
#  ls /dev/disk
dsk0a     dsk0c     dsk0e     dsk0g     floppy0a
dsk0b     dsk0d     dsk0f     dsk0h     floppy0c

削除前の ls コマンドの出力にデバイス特殊ファイル cdrom0 があることに注目してください。この例では,ワイルドカード文字 (*) を使うことによってすべての cdrom デバイスを対象にして dsfmgr -D コマンド・オプションを実行し,そのサブカテゴリに属するすべてのデバイス特殊ファイルを恒久的に削除しています。削除コマンドの後のメッセージには,ベース名 (cdrom0) が 2 回繰り返して現れています。これは,対象となる raw または 文字型特殊ファイルがあった /dev/rdisk ディレクトリからもデバイス特殊ファイルを削除したためです。

ハードウェアの変更がないのに,デバイス特殊ファイルを誤って削除してしまった場合には,次の手順でファイルを再作成します。

#  /sbin/dsfmgr -n cdrom0a
 
  +cdrom0a +cdrom0a
#  /sbin/dsfmgr -n cdrom0c
 
  +cdrom0c +cdrom0c

1.5.3.5    デバイス特殊ファイル名の移動と交換

dsfmgr -m (移動) コマンド・オプションを使用して,デバイス特殊ファイルをデバイス間で移動する (再割当てする) ことができます。また,-e オプションを使用して,デバイス特殊ファイルを他のデバイスと交換することもできます。たとえば次のようにします。

#  /sbin/dsfmgr -m dsk0 dsk10
#  /sbin/dsfmgr -e dsk1 15
 
 

次の手順は,これらのコマンド・オプションを使用してテープ・デバイスの交換をする方法を示す例です。この例では,故障した内蔵テープ・ドライブの緊急代替装置として,デスクトップ型の TLZ06 (DAT) SCSI ドライブを使います。この手順は,内蔵テープ・ドライブの交換やテープ・チェンジャ (ジュークボックス) にマウントされているドライブの追加と削除にも適用できます。

この手順は,利用可能な SCSI アドレスと (必要に応じて) 適切な SCSI 空きポートを持つすべての構成に適用されます。空いている SCSI バスがなければ,故障したテープ・ドライブを先に取り外してから代替機を取り付ける必要があるかもしれません。テープ・ドライブを追加したら,システムを再起動する必要があります。一般的にシステムが再起動に要する時間だけファイル・システムが利用できないことをユーザに知らせてください。

以下の手順では,既存のデバイスの名前を新しくインストールするデバイスに付け直したいものとし,システムが新しいデバイスに自動的に割り当てる名前を使わないものとします。たとえば,システムに接続されている 3 つのデバイスのうち,テープ・デバイス tape0 を使うバックアップ・スクリプトを作成したとします。使われていないのは,tape1tape2 です。tape0 が故障し,これを新しいデバイスに置き換えると,新しいデバイスには tape3 という名前が割り当てられます。しかし,バックアップ・スクリプトはなくなったデバイスを指定しているので,処理が失敗します。新しいデバイス名を指定するようにスクリプトを書き換えるか,デバイスの名前を変えて,故障したデバイスの名前にする必要があります。

または,デバイス名の自動作成機能の利点を考慮して,ローカルのスクリプトとユーティリティがデバイス名に依存しないようにします。そうすれば,スクリプトはハードウェア構成の変更にかかわりなく動作し続けられます。dsfmgrhwmgr コマンドを使えば,システム構成を照会して,デバイスの特性と属性を動的に知ることができます。この方法の場合,本来のターゲットが使用不可能になったときに正常なデバイスにフェールオーバできるため,より効率的です。

この手順の実行に先立ち,必ず以下を実行してください。

手順は次のとおりです。

  1. hwmgr コマンドを使って,次のようにすべての SCSI デバイスに関する情報を表示します。

    #  /sbin/hwmgr show scsi
          SCSI               DEVICE DEVICE  DRIVER NUM  DEVICE FIRST
    HWID: DEVICEID HOSTNAME  TYPE   SUBTYPE OWNER  PATH FILE   VALID PATH
    --------------------------------------------------------------------
     32:  0        f2394     disk   none    2      1    dsk0   [0/0/0]
     33:  1        f2394     disk   none    2      1    dsk1   [0/1/0]
     34:  2        f2394     cdrom  none    0      1    cdrom0 [0/4/0]
     35:  3        f2394     disk   none    0      1    dsk4   [0/2/0]
     41:  4        f2394     tape   none    0      1    tape0  [1/3/0]
    

    既存の SCSI デバイスの記録をとっておくために,出力をパイプに通してファイルに書き出してください。

    このコマンド出力は,この手順にとって重要な以下の情報を提供します。

  2. sysman shutdown または shutdown コマンドを使って,全ユーザに通知を出し,システムをシャットダウンします。オペレーティング・システムを停止するには,-h (halt) オプションを使います。たとえば次のようにします。

    # shutdown -h +10
    "System shutting down to replace backup device \
    Back in 15 minutes"
    

  3. コンソールのプロンプトで,次のコマンドを実行して現在割り当てられているデバイスのアドレスを知ることができます。

    >>> show config
    

    このコマンドの出力には,各 SCSI バスに接続されているデバイスのリストが含まれています。たとえば,MKB300.3.0.13.0 は,バス B のターゲット 3 に接続されている TLZ06 テープ・デバイスに対応するエントリです。末尾の 3 つの数字は,バス,ターゲット,LUN アドレスです。

    手順 1 で利用可能なバス・アドレスがわからなかったら,show config コマンドの出力から知ることができます。

  4. 前面パネルのスイッチを使ってシステムの電源を切り,少なくとも 20 秒待ってからケーブルの取り外しを始めます。

  5. 以下の手順は,次のいずれかに該当する場合にのみ実施してください。該当しない場合は,手順 6 へ進んでください。

    どちらかに該当する場合には,次のようにします。

    1. テープ・ドライブへの電源を切り,オーナーズ・マニュアルに書かれている手順に従って,システムからテープ・ドライブを物理的に取り外します。

    2. コンソールのプロンプトで,次のようにしてシステムをシングル・ユーザ・モードで起動します。

      >>> boot -flags s
      

    3. テープ・ドライブを削除するには,次のコマンドを使用します。

      # /sbin/hwmgr delete scsi -did NN
      

      -did オプションに対して指定している値は,手順 1 で調べた SCSI DEVICEID です。

    4. まれな状況で,削除が完全でないことがあります。デバイスが削除されたかどうか,手順 1 で説明したように hwmgr show scsi コマンドを再度実行して調べます。また,/dev/tape ディレクトリと /dev/ntape ディレクトリの中を調べて,デバイス特殊ファイルがないことを確認します。

    システムにデバイスのレコードが少しでも残っていたら,この手順の終わりにあるトラブルシューティングの説明を参照してください。

  6. この手順は,テープ・デバイスを置き換える場合にのみ実施してください。

    新しいテープ・ドライブを,オーナーズ・マニュアルの説明に従って接続します。テープ・ドライブの電源とシステムの電源を適切な順番で入れます。

    システムをリブートし,次のようにしてシングルユーザ・モードにします。

    >>> boot -flags s
    

  7. ブート・プロシージャを監視し,メッセージに注意します。リブートの過程で,新しいテープ・ドライブは自動的に検出され,次のようなメッセージがコンソールに表示されます。

    dsfmgr:  Note creating device special files
    +tape16...
    

    このメッセージは,新しいテープ・デバイスが検出され,デバイス特殊ファイルが /dev/tape また /dev/ntape ディレクトリに作成されることを示します。このようなメッセージが表示されなかったら,デバイス特殊ファイルを手作業で作成する必要があります (ただし,先に移行の手順を最後まで実行してみること)。

  8. システムをリブートして,マルチユーザ・モードになったら,次のコマンドを入力して新しく追加したテープ・ドライブに関する情報を表示します。

    # /sbin/hwmgr show scsi
          SCSI               DEVICE DEVICE  DRIVER NUM  DEVICE FIRST
    HWID: DEVICEID HOSTNAME  TYPE   SUBTYPE OWNER  PATH FILE   VALID PATH
    --------------------------------------------------------------------
    48:   5        f2394     tape   none    0      1    tape16 [1/4/0]
    

    このコマンド出力を,手順 1 の出力と見比べると,新しいテープ・ドライブが tape16,HWID 48 として表示されているのがわかります。新しいテープ・ドライブの DEVICE FILE (デバイス特殊ファイル) インスタンス番号が 16 で,元のテープ・ドライブの番号 (0) よりもかなり大きいことに注目してください。

  9. デバイスを交換したら,次の作業も行う必要があるかもしれません。

    1. 既存の (故障していると思われる) テープ・ドライブのデバイス名を交換ドライブに移す。それには,次のように dsfmgr コマンドに -e (交換) オプションを付けて,DEVICE FILE を指定します。

      # /sbin/dsfmgr -e tape16 tape0
      tape16<==>tape0       tape16_d0<==>tape0_d0 tape16_d1<==>tape0_d1
      tape16_d2<==>tape0_d2 tape16_d3<==>tape0_d3 tape16_d4<==>tape0_d4
      tape16_d5<==>tape0_d5 tape16_d6<==>tape0_d6 tape16_d7<==>tape0_d7
      tape16c<==>tape0c     tape16<==>tape0       tape16_d0<==>tape0_d0
      tape16_d1<==>tape0_d1 tape16_d2<==>tape0_d2 tape16_d3<==>tape0_d3
      tape16_d4<==>tape0_d4 tape16_d5<==>tape0_d5 tape16_d6<==>tape0_d6
      tape16_d7<==>tape0_d7 tape16c<==>tape0c
      

      この出力には双頭の矢印 (<==>) が含まれています。これは,デバイス特殊ファイルの名前が交換されたことを示します。次のようにして変更を確認します。

      # /sbin/hwmgr show scsi
            SCSI              DEVICE DEVICE  DRIVER NUM  DEVICE FIRST
      HWID: DEVICEID HOSTNAME TYPE   SUBTYPE OWNER  PATH FILE   VALID PATH
      -------------------------------------------------------------------
      48:   5        f2394    tape   none    0      1    tape0  [1/4/0]
      

      SCSI アドレス 1/4/0 にあるテープ・ドライブ (新しく追加したドライブ) の名前が tape0 に変わっています。

    2. デバイス特殊ファイルの番号を低い番号または 0 にする。たとえば,dump コマンドのデフォルト・デバイスは tape0_d0 (デフォルトの密度のテープ 0) です。複数のテープ・ドライブを持つテープ・チェンジャ (ジュークボックス) を使っている場合には,ローカルのスクリプトが期待どおりに動作するようにデバイスの番号を付け替えなければならないことがあります。

      それには,次のように dsfmgr コマンドに -m (移動) オプションを付けて,DEVICE FILE を指定します。

      # /sbin/dsfmgr -m tape16 tape1
       
      tape16=>tape1       tape16_d0=>tape1_d0 tape16_d1=>tape1_d1
      tape16_d2=>tape1_d2 tape16_d3=>tape1_d3 tape16_d4=>tape1_d4
      tape16_d5=>tape1_d5 tape16_d6=>tape1_d6 tape16_d7=>tape1_d7
      tape16c=>tape1c     tape16=>tape1       tape16_d0=>tape1_d0
      tape16_d1=>tape1_d1 tape16_d2=>tape1_d2 tape16_d3=>tape1_d3
      tape16_d4=>tape1_d4 tape16_d5=>tape1_d5 tape16_d6=>tape1_d6
      tape16_d7=>tape1_d7 tape16c=>tape1c
      

      この出力には,デバイス特殊ファイル名が移動されたことを示す一方向の矢印が含まれています。次のようにして変更を確認します。

      # /sbin/hwmgr show scsi
            SCSI              DEVICE DEVICE  DRIVER NUM  DEVICE FIRST
      HWID: DEVICEID HOSTNAME TYPE   SUBTYPE OWNER  PATH FILE   VALID PATH
      --------------------------------------------------------------------
      46:   4        f2394    tape   none    0      1    tape1  [0/5/0]
      48:   5        f2394    tape   none    0      1    tape0  [0/6/0]
       
       
      

      SCSI アドレス 0/5/0 にあるテープ・ドライブの名前が tape1 に変わっています。

この手順に含まれているチェックポイントによって,作業は問題なく終わるはずです。しかしまれに,新しいテープ・ドライブの追加または既存テープ・ドライブの取り外しが失敗することがあります。その場合には,次のトラブルシューティング手順に従って問題を解決できます。

  1. フィールド・サービス窓口に連絡する必要が生じた場合に備えて,どのオプションを試したか記録を残しておくようにしてください。

    hwmgrdsfmgr コマンドをさまざまに組み合わせる試行錯誤による方法は避けてください。ほとんどの場合,問題の原因はデバイスに関係するデータベースのレコードが中間的な状態になっていることです。コマンド・オプションをあれこれ試すと,かえって問題が複雑になる可能性があります。

  2. Event Manager (EVM) ビューアを起動し,優先度 300 以上のイベントが表示されるように構成されていることを確認します。

    # /usr/sbin/sysman event_viewer
    

    イベント・ビューアを使って,手順の実行によって生成されるハードウェア・イベントを確認したり,エラーを発見したりできます。最新のイベントを見るには,イベント・ビューアの表示を更新する必要があります。イベント・ビューアには,テープ・ドライブが検出され,新しいベース名 (tape*) とハードウェア識別子 (HWID) が割り当てられたことを示すイベントが表示されます。システムがこれらのイベントを通知するまで少し時間がかかったり,イベントを見るためにイベント・ビューアを更新する必要があったりするかもしれません。

  3. SCSI バスをスキャンし,検出されたすべての新しいデバイスに識別子を割り当てるには,次のコマンドを使います。

    # /sbin/hwmgr scan scsi
    hwmgr: Scan request successfully initiated
    

    ハードウェア・スキャンは非同期で実行されるので,システム・プロンプトにすぐに戻りますが,それはスキャンが終わったことを示すわけではありません。SCSI デバイスの数が多いシステムでは,スキャンに数分かかることがあります。スキャンが完了するまで待ってください。通常,スキャンはシステム起動時に自動的に行われるため,処理が完了してもメッセージが表示されません。

  4. スキャンが完了したら,次のコマンドを実行してテープ・ドライブが検出されたことを確認します。

    # /sbin/hwmgr show scsi
          SCSI              DEVICE DEVICE  DRIVER NUM  DEVICE FIRST
    HWID: DEVICEID HOSTNAME TYPE   SUBTYPE OWNER  PATH FILE   VALID PATH
    -------------------------------------------------------------------
    46:   4        f2394    tape   none    0      1    tape1  [0/5/0]
    48:   5        f2394    tape   none    0      1           [1/4/0]
     
     
    

  5. 手順 4hwmgr の出力に,含まれているべきデバイス特殊ファイルが含まれていなければ,新しく追加したデバイスのデバイス特殊ファイルが作成されているかどうかを確認します。必要に応じて,/dev/tape ディレクトリまたは /dev/ntape ディレクトリの内容を確認します。

    デバイス特殊ファイルが見つからなければ,dsfmgr コマンド ( dsfmgr(8) を参照) に -K オプションを指定して,次のようにデバイス特殊ファイルを作成します。

    # /sbin/dsfmgr -K
    +tape16 +tape16_d0 +tape16_d1...
    

  6. 以上の手順で問題が解決しなければ,デバイス・データベースが中間的な状態になっている可能性があります。テープ・ドライブの HWID またはデバイス特殊ファイル名を指定して,/etc/dfsc.dat ファイルの中でテープ・ドライブのエントリを探します。たとえば,テープ・ドライブがリスト出力に tape0 と表示されている場合には,次のコマンドを入力します。

    # grep "tape0" /etc/dfsc.dat
    

    次のような出力が得られます。

    A: 0 130003e    48    9    6   c  ""   /dev/tape  tape 0
    

    この出力の第 4 欄にハードウェア識別子 (HWID) があります。ここでは 48 です。

  7. 前の手順でわかった HWID 48 を指定し,次のコマンドを使ってデバイスの状態を確認します。

    # /sbin/hwmgr show component -id 48
    

    コマンドから何か出力された場合には,技術サポート窓口までご連絡ください。さもなければ,次の手順に進みます。

  8. 依然としてデバイスにアクセスできなければ,システムを再起動してデバイス・データベースをリセットします。システムを再起動することもできなければ,技術サポート窓口までご連絡ください。

1.5.3.6    デバイス特殊ファイルの番号の付け替え

システムのコンポーネントを再構成すると (たとえば,デバイスを削除するなど),デバイス特殊ファイルに割り当てられているインスタンス番号がインクリメントされます。時間がたつにつれて,デバイス特殊ファイルが無作為に番号付けされているように見えてきます。また,クローニング,コピー,削除の手順を用いてシステムをバックアップした場合,バックアップのたびにインスタンス値が大きくなり,デバイス名が長くなって管理しにくくなってきます。クローニング・バックアップ・プログラムも,バックアップのたびに新しいデバイス・インスタンスを知る必要があるため,デバイス特殊ファイル名の変更によって,バックアップに要する時間が長くなります。

dsfmgr -vI コマンド・オプションを使うことによって,各デバイスのインスタンス番号を可能限り最小の値にリセットできます。システムの構成がバックアップ・プロシージャを除いて固定の場合,このオプションを使うことで,クローニングされるバックアップ・デバイスは,セットが改まるたびに同じ新しい名前を持つようになり,バックアップ・プロシージャが簡単になります。次の手順は,dsfmgr -vI コマンドを使ってすべてのデバイスのインスタンス値を可能な限り最小の値にリセットする方法を示します。この手順は,dsfmgr -vI コマンドの仕組みを示します。

  1. 次の (一部省略された) 出力は,新しくインストールされたシステムでテープ・ドライブのデバイス特殊ファイルがどのように番号付けされているかを示します。

    # /sbin/hwmgr view device
    61: /dev/ntape/tape0    COMPAQ  SDT-10000   bus-5-targ-0-lun-0
    

  2. システムの構成に多数の変更が加えられた状況を再現するために,次のコマンドでテープ・ドライブのデバイス特殊ファイルの番号を 40 にします。

    # /sbin/dsfmgr -m tape0 tape40
    tape0=>tape40  tape0_d0=>tape40_d0  tape0_d1=>tape40_d1
    tape0_d2=>tape40_d2  tape0_d3=>tape40_d3  tape0_d4=>tape40_d4.......
    

  3. 次の (一部省略された) 出力は,テープ・ドライブのデバイス特殊ファイルの番号が大きくなって tape40 に変わったことを示します。

    # /sbin/hwmgr view device
    .61: /dev/ntape/tape40    COMPAQ   SDT-10000        bus-5-targ-0-lun-0
    

  4. システムからデバイスを削除した状況を再現するために,次のコマンドでテープ・ドライブのデバイス特殊ファイルの番号を 10 にします。

    # /sbin/dsfmgr -m tape0 tape40
    tape40>tape10
    

    これは,11 から 39 の範囲で未使用のデバイス特殊ファイルのインスタンスがあることを意味します。しかし,システムは現時点ではこれらのインスタンスが空いていることを知らないので,新しくインストールされたデバイスをインスタンス番号 41 から番号付けをします。

  5. システムが可能な限り小さいインスタンス番号を割り当てるようにするには,次のコマンドを実行します。

    # /sbin/dsfmgr -vI
    dsfmgr: verify all datum for system (version) at /
     
    Default File Tree:
        OK.
     
    Device Class Directory Default Database:
        OK.
     
    Device Category to Class Directory Database:
        OK.
     
    Dev directory structure:
        OK.
     
    Device Status Files:
        OK.
     
    Dev Nodes:
        OK.
     
    Minimize next instance values:
          tape     41  =>   11
    

    "Minimize next instance values:" のメッセージは,利用可能な最小のインスタンス値が 11 であることを示します。

  6. 処理が正しく行われたことを確かめるために,次のコマンドを使ってテープ・デバイスの削除と再スキャンを行い,システムが新しいデバイス特殊ファイルにインスタンス番号 11 から番号を付けるようにします。

    # /sbin/hwmgr delete scsi -did 3
    hwmgr: The delete operation was successful
    # /sbin/hwmgr scan scsi
    hwmgr: Scan request successfully initiated
    # /sbin/hwmgr show scsi
    84:  3        argo1      tape      none    0      1    tape11 [5/0/0]
    

    これでテープ・デバイスのデバイス特殊ファイルが 11 番になり,システムが利用可能な最小のインスタンス値を使ったことがわかります。

このオプションを自分のシステムで使うには,バックアップ・スクリプトを修正するか,適切なタイミングで dsfmgr -vI コマンド・オプションを実行する新しいスクリプトを作成します。あるいは,ハードウェアの構成を変えるたびにこのコマンドを実行するようにします。