本章では,ハードウェア管理モデルの概要を説明するとともに,利用可能な参考資料について解説します。以下のトピックについて取り上げます。
ハードウェア管理の大まかな概念を説明するとともに,それが本書のどこと関連するかを示します (1.1 節)。
ハードウェアの管理に用いる他のドキュメント資料 (コマンドやユーティリティのリファレンス・ページなど) を示します。また,ハードウェアの管理に関係するユーティリティに関するドキュメントの参照先についても説明します (1.2 節)。
システム・デバイスに関する情報が格納されているシステム・ファイルとデータベースについて説明します (1.3 節)。
最近のほとんどのデバイスで,デバイス固有の名前がファームウェアにエンコードされていることについて説明します。オペレーティングシステムは,このワールドワイド識別子 (WWID) を使用してデバイスを管理します (1.4 節)。
特定の種類のデバイスの論理的な表現であるデバイス特殊ファイルについて説明します (1.5 節)。
hwmgr
コマンドを使うことによって,CPU
のホットスワップのようなサービス・タスクを実施できます。この機能の詳細については,
hwmgr_ops
(8)1.1 ハードウェアの理解
ハードウェア・コンポーネントは,CPU,ネットワーク・カード,またはハードディスクのような,システムの個別の部品のことです。システムは,CPU (中央演算処理装置) を頂点とし,ディスク・ドライブやテープ・ドライブなどの周辺機器を最下層に置く階層構造になっています。これを,システム・トポロジと呼ぶこともあります。以下に述べるようなコンポーネントは,これがすべてではありませんが,ほとんどのコンピュータ・システムにある一般的なデバイスです。
CPU には,シングル・プロセッサ・システム,マルチプロセッサ・システム,およびクラスタ・システムがあります。ハードウェアの管理では,システムをホストと呼ぶことがあります。また,システムには,ホスト名とホスト・アドレス (ネットワーク上にある場合) が割り当てられています。ホスト名を指定してコマンドを使うこともよくあります。CPU はシステムのハードウェア階層の最上位にあり,その他のシステム・コンポーネントは CPU の下に位置しています。
CPU に関する一般的な管理作業は,CPU のオンラインへの移行,起動および停止,CPU リソースの共用など,多岐にわたります。追加情報については,『システム管理ガイド』と『Managing Online Addition and Removal』を参照してください。
バス - システムには主要な内部通信バスがいくつかあり,それらのバスを通してシステムのコンポーネント間でデータを転送します。アダプタとコントローラは物理的にバスへ差し込まれます。こうしたデバイスには物理アドレスと論理アドレスの両方があります。
物理バスによっては特定のソフトウェアが必要なこともありますが,そうしたソフトウェアは,通常,UNIX オペレーティング・システムで管理されます。たとえば,PCI バスにサウンド・カードやネットワーク・カードなどのオプション・カードを追加するときには,システムをシャットダウンしてハードウェアを追加し,リブートしなければなりません。このようなコンポーネントは,通常,リブート時に自動的に認識されシステム構成に追加されますが,ファームウェア・ユーティリティを使ってそのデバイスのドライバをインストールしなければならないこともあります。そのようなコンポーネントの追加についての詳細は,そのシステムのマニュアルと,カードに添付されているマニュアルを参照してください。
コントローラとアダプタ - システムに,SCSI (Small Computer System Interface) コントローラのように,1 つ以上のストレージ・デバイスを制御するコントローラがいくつか接続されていることがあります。また,1 種類のディスクをサポートし,通常は物理ディスクが 1 台だけ接続されたフロッピィ・ディスク・インタフェース (fdi
) のようなコントローラが接続されていることもあります。さらに,ネットワーク・アダプタがバスに接続されることもあります。しかし,それより下の階層には,ネットワーク・ケーブル以外のコンポーネントはありません。
各アダプタはバス上で自分用の物理スロットを 1 つ占有し,管理用の論理アドレスと物理位置の両方が割り当てられます。アダプタを通してその他のコンポーネントがスロットを占有することもあり,その場合,そのコンポーネントにも物理アドレスと論理アドレスの両方が割り当てられます (コントローラとアダプタは,しばしばHBAまたはホスト・バス・アダプタと呼ばれます)。
SCSI ディスク,CD-ROM リーダなどのストレージ・デバイスは,システム階層の最下位の要素です。これらは一般にコントローラまたはアダプタに取り付けられ,管理用の物理位置と論理アドレスの両方が割り当てられます。
ストレージ (およびその他の) デバイスは,コンポーネント間またはクラスタのメンバ間で共用されることがあります。これは,コンポーネントのアクセス方法によっては,1 つのコンポーネントに複数の異なる名前および ID が割り当てられている可能性があるということです。コンポーネントの識別方法と,階層の他の部分からそのコンポーネントがどのように見えるかを理解することは,ハードウェア管理での重要な側面です。管理者はコンポーネントの論理位置および物理位置の両方を知っていなければなりません。
このマニュアルでは,SCSI デバイスについて説明する場合の例として,SCSI ディスクを最も多く使用しています。これは,SCSI デバイスが最も頻繁にハードウェア管理作業の対象となるデバイスであり,システムから見て,シングル・デバイスにも,グループやアレイにもなるからです。例を次に示します。
RZ
デバイス
オペレーティング・システムは,SCSI インタフェース仕様に従うストレージ・デバイスをサポートします。しかし,すべての SCSI デバイスがこの標準に厳密に従っているわけではないので,システムはこのようなデバイスを自動的に検出して追加することができない場合もあります。このようなデバイスは,第 4 章
で説明するように,ddr_config
を用いて追加します。
HSZ
デバイスと
HSV
デバイスRAID (Redundant Array of Inexpensive Disks または Redundant Array of Independent Disks) 技術。これは,複数の SCSI ディスクを連結してボックスに収納したデバイスであり,システムには単一デバイスとして見えます。ホット・スワッピング,フェイルオーバ,および冗長性などの機能をサポートしていることがあります。また,ファイバ・チャネル制御装置を使ってシステムに接続されていることがあります。このようなストレージ・アレイは,ストレージ・エリア・ネットワーク (SAN) 内のシステム間で共用できます。たとえば,HSV110-Enterprise Virtual Array HSV Controller はその例です。
SWCC (StorageWorks Console) のようなアプリケーションを使い,ストレージ・アレイとストレージ・エリア・ネットワークを管理します。このような構成では,hwmgr
コマンドのようなオペレーティング・システムの機能を使って,ストレージ管理作業の一部分だけを実行することができます。ストレージ・アレイの構成と管理方法の完全な説明は,StorageWorks のドキュメントを参考にしてください。
デバイス特性についての詳細は,
RAID
(7)SCSI
(7)rz
(7)tz
(7)
ハードウェアを管理するには,すべてのコンポーネントがお互いにどのように関連し合っているか,また,システム・トポロジの中でコンポーネントが論理的および物理的にどのように位置しているか,さらにはシステム・ソフトウェアがコンポーネントをどのように認識し,それらとどのように通信しているか,を理解していなければなりません。システム・コンポーネントの位置関係をより詳しく知るためには,『システム管理ガイド』で &DNOSysManStation の紹介を参照してください。このユーティリティは,システム・コンポーネントの位置関係を表示し,その表示内容を操作できるようにするグラフィカル・ユーザ・インタフェースです。
大部分のハードウェア管理作業は自動化されています。サポートされている SCSI ディスクをシステムに追加接続してリブートすると,ディスクが自動的に検出され,システム内に構成されます。オペレーティング・システムは,必要なドライバを動的にロードし,デバイス特殊ファイルを作成します。管理者が行う必要のある作業は,必要に応じてディスクのパーティションを作成し,そのパーティションにファイル・システムを作成して (『システム管理ガイド』 で説明),データを格納できるようにすることだけです。ただし,定期的に手動で行わなければならないハードウェア管理作業はあります。たとえば,ディスクがクラッシュした場合には,代替ディスクを同じ論理位置でオンラインにしなければなりません。また,稼働中のシステムにコンポーネントを手動で追加したり,ディスクの入出力を他のディスクにリダイレクトしなければならないこともあります。
それら以外のハードウェア管理作業の多くは,ディスク・パーティションの作り直しやバスへのアダプタの追加など,標準的なシステムの操作と保守です。このような作業については,通常,コンポーネントに付属しているハードウェア・マニュアルで十分に説明されていますが,新しいコンポーネントの物理/論理位置を最適な (あるいは,より適した) 位置にするためにシステムをチェックするというような作業が必要になることもあります。
ハードウェア管理の重要な側面に,予防を目的とした保守およびモニタリング作業があります。システム環境を健全に保つには,次のようなオペレーティング・システム機能を使用します。
Event Manager (EVM) - システム・イベントをフィルタにかけ,選択されたイベントについて知らせる,イベント・ロギング・システム。電子メールやポケットベルで問題を警告する高度な機能もあります。EVM の構成については,『システム管理ガイド』を参照してください。
SysMan Station - モニタリングのためにシステム (またはクラスタ) のハードウェア全体を表示させたり,コンポーネントの管理作業のためにアプリケーションを起動させたりできる,グラフィカル・ユーザ・インタフェース。これらのアプリケーションは,SysMan Menu から起動することもできます。アプリケーションの例をいくつか,この章で後述します。SysMan タスクの使い方についての詳細は,2.1 節を参照してください。また,『システム管理ガイド』を参照してください。
sys_check
システム調査ツール - システムの現在の構成に関するデータを HTML ドキュメントにして,Web ブラウザで読めるようにするコマンド行ユーティリティ。このデータをシステムの基準として使用したり,チューニングに使用したり,また,すべてのログ・ファイルをチェックするために使用したりすることができます。Storage 構成セクションには,ストレージ・デバイスとファイル・システムについての情報があります。このユーティリティの実行方法,および,これを定期的に実行するように構成する方法については,『システム管理ガイド
』の中でシステムのカスタマイズについて書いてある箇所と,
sys_check
(8)
HP Insight Manager Agents for Tru64 UNIX - 企業全体を扱える Web ベースの管理ツール。ローカル・エリア・ネットワーク内のどこからでも,システムとコンポーネントの状態を見ることができます。このツールから,SysMan Station,SysMan Menu,およびシステム調査ユーティリティ
sys_check
を起動することができます。詳細は,
insight_manager
(5)
このマニュアルの構成は,次のように,管理するハードウェア・コンポーネントやデバイスを反映したものになっています。
汎用のハードウェア管理ツール - これらのツールを使って,同じタイプの全コンポーネントに対しても,SCSI テープ・ドライブなど特定の種類のコンポーネントに対しても,また,個別のコンポーネントに対しても操作を行うことができます。場合によっては,このツールをクラスタに属するすべてのシステムに対して実行させることもできます。このようなツールの例としては,SysMan Station があります。このツールを使えば,クラスタの全メンバについて,そのコンポーネントの階層全体を視覚的に表示させることができます。
ソフトウェア管理 - これには,システムのハードウェア・コンポーネントに対応するソフトウェアの管理が含まれます。主な管理対象はデバイス特殊ファイルです。デバイス特殊ファイルは,ハードウェア・コンポーネントに結び付いており,どのアプリケーションからでもそのコンポーネントのデバイス・ドライバまたは擬似ドライバにアクセスできるようにします。
対象ハードウェア別管理ツール - これらのツールを使えば,特定のコンポーネントを対象とした操作や特定のタスクを行うことができます。ツールの例としては,ディスク構成のコマンド行インタフェース
disklabel
や,これと同じような機能を持つグラフィカル・ユーザ・インタフェース Disk Configuration (diskconfig
) があります。これらのツールを使うことによって,標準的なレイアウトや独自のレイアウトでディスクのパーティションを作成することができます。
デバイス固有またはシステム固有のタスク - これらの操作は,特定のデバイスやプロセッサ・プラットフォームを対象とします。このようなタスクの例としては,論理パーティションの構成があります。論理パーティションは,特定の種類のプロセッサだけでサポートされています。
観点を変えれば,汎用ツールを使って多数のコンポーネントを対象にタスクを実行できる一方で,ハードウェア別ツールを使って単一のコンポーネントのみを対象にタスクを実行することもできます。特に明記しない限り,ほとんどの操作は 1 つのシステムまたは 1 つのクラスタを対象とします。クラスタ・ハードウェアの管理についての詳細は,TruCluster サーバのドキュメントを参照してください。
1.2 参照情報
以降の各項で,ドキュメント,システム・ファイル,関連のソフトウェア・ツールに関する参照情報を示します。ここで説明するツールの中には,将来のリリースで廃止される予定のものもあります。廃止される予定のオペレーティング・システム機能の一覧を『リリース・ノート』で参照し,できるだけ早く新しいツールへ移行してください。サイト固有のシェル・スクリプトの中でこうした廃止予定のコマンドを起動していないか,チェックしてください。
1.2.1 ドキュメント
以下のドキュメントに,ハードウェア管理の情報が記載されています。
マニュアル (オンラインまたはハードコピーで提供)
『Managing Online Addition and Removal』 - システム管理アプリケーションを使用したシステム・コンポーネントのオンライン追加と削除 (OLAR) で使う管理および構成の方法について説明します。システム管理アプリケーションには,SysMan Station,SysMan Menu,hwmgr
コマンドなどがあります。コンポーネントの不具合,自動割り当て解除,関連サービス・ツールなどのトピックが含まれています。
『ネットワーク管理ガイド:接続編』と『ネットワーク管理ガイド:サービス編』 - ネットワーク・コンポーネントの構成や接続に関する情報を提供します。
Device Driver Documentation キット - 『Writing PCI Bus Device Drivers』や『『Writing Device Drivers: Reference』』のような関連ドキュメントが含まれています。
『Logical Storage Manager』 - LSM の概念とコマンドに関する情報が含まれています。LSM (Logical Storage Manager) は,物理ディスク・デバイス,論理エンティティ,およびそれらを相互に関連付けるマッピングからなります。
リファレンス・ページ
hwmgr
(8)/sbin/hwmgr
の構文と使用法についての概要です。
hwmgr_ops
(8)/sbin/hwmgr
コマンド用のシステム操作オプションを説明します。これらのオプションを使って,CPU ホット・スワップなどの手順を実行します。
hwmgr_show
(8)/sbin/hwmgr
コマンド用のハードウェア情報オプションを説明します。これらのオプションを使って,ハードウェア・データベースからの情報を表示します。
hwmgr_get
(8)/sbin/hwmgr
コマンド用のコンポーネント属性情報オプションを説明します。これらのオプションを使って,コンポーネント属性を取得,構成します。
hwmgr_view
(8)/sbin/hwmgr
コマンド用の状態情報オプションを説明します。これらのオプションを使って,コンポーネントとシステム状態を表示します。
dsfmgr
(8)/dev
ディレクトリにデバイス特殊ファイルを作成します。1.5 節
も参照してください。
mknod
(8)MAKEDEV
(8)scu
(8)ddr_config
(8)devswmgr
(8)
コマンド行とグラフィカル・ユーザ・インタフェースには,詳細なオンライン・ヘルプもあります。
1.2.2 Web リソース
本書で説明する手順の大半は,システム・ハードウェアや,ストレージ・デバイスなどの周辺機器の管理に関連します。ハードウェア固有のアプリケーション・ソフトウェアの使い方に関して情報が必要な場合には,ハードウェアのオーナーズ・マニュアルも参照してください。
次の Web サイトでは,ドライバのアップデート情報のような情報やリソースを提供しています。
Alpha 用のファームウェア・ダウンロードを始めとするソフトウェアやドライバは,次の Web サイトにあります。http://www.compaq.com/support/files
AlphaServers に関する一般的な情報は,次のサイトにあります。
http://h50146.www5.hp.com/products/servers/alpha/
次の Web サイトは,ファームウェアやドライバを含め,ストレージに関するサポートを提供します。
http://www.compaq.com/storage/
このサイトには,次のタイプのストレージ・デバイスに関する情報があります。
テープ・ストレージ (SDLT160/320) に関する情報は,次の URL にあります。
http://www.compaq.com/storage/
ローカル・システムの構成に応じて,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)
ACS はホストからの I/O リクエストを処理し,リクエストに応えるために必要なデバイス・レベルの操作を実行します。ACS は,クローニングやフォーマッティングなどのユーティリティを提供します。ACS オペレーティング・ファームウェアは,コントローラと同梱の PCMCIA プログラム・カードに格納されています。
階層性記憶域オペレーティング・ファームウェア (HSOF)
HSOF は機能コード,診断機能,ユーティリティ,および,特定の HS シリーズ・アレイ・コントローラの動作試験をする機能で構成されています。HSOF のコマンド行インタフェースを使って,構成やクローニングなどのコントローラ操作を実行できます。HSOF は,コントローラと同梱の PCMCIA プログラム・カードにも格納されています。
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) は,EMA12000 と EMA16000 RAID アレイを対象とした,ストレージの構成とモニタリングのための視覚的なツールです。このツールは,ストレージ管理をポイント・アンド・クリック式の単純な操作で行えるようにし,単独の管理コンソールからストレージを視覚的に構成したりモニタリングしたりできるようにします。SWCC 2.3 は,Tru64 UNIX Version 4.0F 以降を対象とするエージェントを提供します。
SWCC の情報については,次の Web サイトを参照してください。
http://h18000.www1.hp.com/products/storageworks/
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 サイトを参照してください。
DLT や,4mm (DAT) または TKZ シリーズのローダなどのオートローダを制御するためのアプリケーションです。
デバイスの管理に使用できるコマンドは,次のとおりです。
デバイスが正しく動作しているかどうかをテストするために使用します。
diskx
(8)tapex
(8)cmx
(8)fsx
(8)memx
(8)
scu
コマンド。SCSI 周辺機器および CAM I/O
サブシステムの保守と問題の診断を可能にします。
scu
(8)
sysconfig
コマンド。カーネル・サブシステムの構成を照会または変更する場合に使用します。このコマンドを用いれば,稼働しているカーネルへのサブシステムの追加,カーネルに現在あるサブシステムの再構成,カーネル内のサブシステムについての情報要求 (照会),そして,カーネルからのサブシステムの構成除外および削除ができます。sysconfig
コマンドを用いてコンポーネントの属性値を設定できます。sysconfig
コマンドの使い方については,『システム管理ガイド』を参照してください。同書には,Kernel Tuner (dxkerneltuner
) についての説明もあります。Kernel Tuner は,属性値を変更するためのグラフィカル・ユーザ・インタフェースです。
CDE のアプリケーション・マネージャ - 「SysMan アプリケーション」ポップアップ・メニューと「システム管理」フォルダには,いくつかのハードウェア管理ツールがあります。たとえば,次のようなツールです。
システム設定 - ATM,ディスク・デバイス,ネットワーク・デバイス,PPP (モデム) デバイス,および LAT デバイスなどのハードウェアを構成するグラフィカル・ユーザ・インタフェース。
日常管理 - 電力管理のためのグラフィカル・ユーザ・インタフェース。特定デバイスの電力属性の設定に使用します。
SysMan Checklist,SysMan Menu,SysMan Station - どのツールも,システム・デバイスの構成,モニタリング,および保守を行うためのインタフェースです。SysMan Menu と SysMan Station は,パーソナル・コンピュータや X11 ベースの環境など,さまざまなプラットフォームから起動できます。この機能により,リモート・モニタリングとリモート・デバイス管理が実行できます。詳細については,『システム管理ガイド』を参照してください。
次に示すシステム・ファイルには,コンポーネントを構成してカーネルへ組み込む場合にシステムで使用する静的情報または動的情報が含まれています。これらのファイルは,ASCII テキスト・ファイルであっても,編集しないでください。ファイルの中には,『システム管理ガイド』で説明するようなコンテキスト依存シンボリック・リンク (CDSL) もあります。リンクが切れると,そのリンクを検証して再度作成するまでは,クラスタ・システムでそのファイルを使用できなくなります。CDSL
の再作成については,
cdslinvchk
(8)mkcdsl
(8)
注意
ハードウェア・データベースの中にはテキスト形式のものもありますが,データベースを編集してはなりません。データベースに誤りがあると,システムがデバイスにアクセスできなくなったり,データが損傷を受けたり,システムが起動できなかったりすることがあります。デバイスの管理には,適切なコマンドとユーティリティだけを使うようにしてください。
/dev
- このディレクトリには,デバイス特殊ファイルが置かれています。詳細については,1.5 節を参照してください。
/etc/ddr_dbase
- 動的デバイス認識 (DDR) デバイス情報データベース。このファイルの内容は,コンパイルされてバイナリ・ファイル
/etc/ddr.db
にされます。システムはそのバイナリ・ファイルを用いてデバイス情報を取得します。
/etc/dec_devsw_db
- カーネルの
dev
スイッチ・コードを所有者とするバイナリ・データベース。このデータベースには,ドライバのメジャー・デバイス番号とスイッチ・テーブル・エントリの最新情報を記録します。
/etc/disktab
- ディスクのジオメトリとパーティション・レイアウト・テーブルを指定するファイル。このファイルは,ディスクのデバイス名と特定のディスク・デバイス属性を知るのに役立ちます。
/etc/dvrdevtab
- データベース名と,ドライバ名から特殊ファイル・ハンドラへのマッピングを指定するファイル。
/etc/gen_databases
- データベース名をデータベース・ファイルの位置とデータベース・ハンドラに変換するために必要な情報を含むテキスト・ファイル。
/etc/dec_hw_db
- ハードウェアの永続的な情報を含むバイナリ・データベース。一般に,バスやコントローラなどのハードウェアが該当します。
/etc/dec_hwc_ldb
- クラスタ・メンバから見てローカルにあるハードウェア・コンポーネントの情報を含む,バイナリ・データベース。
/etc/dec_hwc_cdb
- クラスタの全メンバによって共用されるハードウェア・コンポーネントの情報を含む,バイナリ・データベース。一意のクラスタ名を持つか,dev_t
にマッピングされたハードウェア・コンポーネントが,このデータベースに格納されています。
/etc/dec_scsi_db
- SCSI/CAM が所有するバイナリ・データベース。SCSI デバイスのワールドワイド識別子 (WWID) が格納されています。CAM は,このデータベースを使用して,システムが認識しているすべての SCSI デバイスの最新情報を把握します。
/etc/dec_unid_db
- ハードウェア・コンポーネントに割り当てられているハードウェア ID (HWID) の最高値を格納するバイナリ・データベース。オペレーティング・システムはこのデータベースを使って,新しくインストールするハードウェア・コンポーネントに自動的に割り当てる次の HWID を生成します。システムは HWID を再使用しません。たとえば,ディスクをシステムに追加したときに,124 という HWID が割り当てられたとします。システムからそのディスクを恒久的に取り外した場合でも,HWID 124 は代替のディスクやその他のデバイスに割り当てられることはありません。HWID の番号付けシーケンスをリセットする唯一の方法は,オペレーティング・システムを新たにインストールすることです。
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 以降でデバイスとデバイス特殊ファイルに名前を割り当て構成する方法について説明します。
次の点に注意してください。
SCSI デバイスに対するデバイス特殊ファイルの名前の形式は,SCSI ディスクが
/dev/disk/disk13a
,そして SCSI テープ・ドライブが
/dev/ntape/tape0_d0
となっています。/dev/rz10b
という形式の SCSI デバイス特殊ファイル名は,旧式のデバイス特殊ファイルです。この節では,現在のデバイス特殊ファイルと旧式のものを分けて説明します。また,一部のスクリプトおよびコマンドでは,この 2 つを old (または legacy) および new (または current) と表記して区別しています。日本語の説明では,それぞれ「古い」(または「旧式の」) と「新しい」(または「現在の」) で表記します。このオペレーティング・システムを初めて使うユーザは,現在の命名モデルをサポートしないサードパーティ製のドライバとデバイスを使うのでなければ,旧式のデバイス特殊ファイル名について気にする必要はありません (デバイス特殊ファイルの構造については,この節で後述します)。
現在,SCSI ディスクおよびテープ・デバイスに対しては 1 つの共通のデバイス特殊ファイル命名モデルが,また,他のデバイスすべてに対してはこれと異なる命名モデルが適用されています。SCSI ディスクおよびテープ・デバイスに対する命名方法は,将来のリリースでは他のデバイスにも拡張される予定です。そうなれば,旧式のデバイスおよびデバイス名のサポートが,非クラスタ・システムでも継続できるようになります。アプリケーションとコマンドは,すべてのデバイス名をサポートするか,またはサポートされているデバイス名の形式をエラー・メッセージで通知するかのどちらかです。
旧式のデバイス名およびデバイス特殊ファイルはしばらく維持されます。廃止予定については,将来のリリースでお知らせします。
1.5.1 関連ドキュメントとコマンド
次のドキュメントに,デバイス名に関する情報があります。
マニュアル:
コンテキスト依存シンボリック・リンク (CDSL) についての説明があります。デバイス特殊ファイルのあるディレクトリには,CDSL になっているものがあります。次に進む前に,この概念をよく理解してください。詳細については,『システム管理ガイド』を参照してください。
リファレンス・ページとコマンド
デバイス特殊ファイルの管理についての説明は,
dsfmgr
(8)MAKEDEV
を置き換えるものです
(
MAKEDEV
(8)
Disk Configuration GUI
の起動方法についての説明は,
diskconfig
(8)disklabel
より豊富な機能があり,ディスクのパーティションを作成してそこにファイル・システムを作る操作を 1 回で実行できます。Disk Configuration インタフェースは,CDE の「アプリケーション・マネージャ - システム管理」フォルダから実行することもできます。「ディスク」アイコンは「システム設定」フォルダ内にあります。このインタフェースの使い方は,オンライン・ヘルプに説明があります。
デバイス特殊ファイルを入れるために,/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
旧式のデバイス命名規則に従えば,デバイス特殊ファイルはすべて
/dev
ディレクトリに置くことになります。デバイス特殊ファイル名は,デバイスの種類,物理的な位置,およびその他のデバイス属性を表してます。古い規則を使用するディスクやテープ・ドライブのデバイス特殊ファイル名は,たとえば,SCSI ディスクの
/dev/rz14f
やテープ・ドライブの
/dev/rmt0a
といったファイル名の形式をとります。名前には,次のような情報が含まれます。
パス | 接頭語 | タイプ | 番号 (インスタンス) | 接尾語 |
/dev |
r (raw) | rz
(ディスク) |
0 |
c
(パーティション) |
/dev |
(巻戻し) | rmt
(テープ) |
4 |
a
(密度) |
/dev |
n (非巻き戻し) | rmt
(テープ) |
12 |
h
(密度) |
この情報は,次のように解釈されます。
パスは,デバイス特殊ファイルが置かれるディレクトリです。デバイス特殊ファイルはすべて
/dev
ディレクトリに置かれます。
接頭語は,次のように,同じ物理デバイスでもそのデバイス特殊ファイルとしての性質 (型) が異なる場合,その違いを区別します。
r
- 文字型 (raw) ディスク・デバイス。ブロック型デバイスのデバイス特殊ファイルには接頭語がありません。
n
- クローズ時非巻戻し型のテープ・デバイス。クローズ時巻き戻し型のテープ・デバイスには接頭語がありません。
タイプは,2 文字または 3 文字のドライブ名です。SCSI ディスク・デバイスは
rz
,テープ・デバイスは
rmt
になります。
次に示すように,番号はデバイスのユニット番号です。
SCSI デバイスの場合,ユニット番号は次の式で計算します。
unit = (bus * 8) + target
ディスク・デバイス HSZ40 および HSZ10 の場合,ユニット番号の前に 1 文字付けて,LUN を表すことがあります。この場合,a
は LUN 0 を表し,b
は LUN 1 を表すという具合になります。LUN 0 に文字
a
を付ける必要はありません。これは省略値だからです。
テープ・デバイスの場合,接頭語は 0 〜 7 の連番になります。
接尾語は,次のように同じ物理デバイスに対する複数のデバイス特殊ファイルを区別します。
ディスクのパーティションは
a
〜
h
の文字を使用して表します。ディスク・デバイスごとに合計 16 のファイルが作成されます。内訳は,文字型デバイス・パーティション
a
〜
h
に対して 8 個,ブロック型デバイス・パーティション
a
〜
h
に対して 8 個です。
テープ・デバイスは接尾語を用いてテープの密度を表します。テープ・デバイスごとに 8 個までのファイルが作成されます。その場合,表 1-2
に示す接尾語を使って,密度ごとに 2 つのファイルが作成されます。
表 1-2: 旧式のデバイス特殊ファイルに使うテープ・デバイスの接尾語
接尾語 | 説明 |
a |
密度 QIC-24 (SCSI QIC デバイスの場合) |
l |
デバイスがサポートする最低密度,または密度 QIC-120 (SCSI インタフェースの QIC デバイスの場合) |
m |
ドライブが 3 倍密度の場合の中間の密度,または密度 QIC-150 (SCSI インタフェースの QIC デバイスの場合) |
h |
デバイスがサポートする最高の密度,または密度 QIC-320 (SCSI インタフェースの QIC デバイスの場合) |
スクリプトが期待どおりに動作するように,旧式のデバイス命名規則がサポートされています。しかし,新しいデバイス命名規則を通じて使用できる機能は,旧式の命名規則と組み合わせて使うとうまく動かないないことがあります。バージョン 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
のようなベース名が作成されます。
現在のデバイス特殊ファイルはデバイスのベース名を使って命名され,対象デバイスに関するより詳しい情報を伝える接尾語が含まれます。接尾語は,次のようにデバイスの種類によって異なります。
ディスク - デバイス・ファイル名はベース名と
a
〜
z
の接尾語で構成されます。たとえば,dsk0a
のようになります。ディスクのパーティションは,a
〜
h
を使って表します。特に指定しない限り,CD-ROM とフロッピィ・ディスクは
a
と
c
のみを使用します。たとえば,cdrom1c
や
floppy0a
のようになります。
raw デバイスに対しては,クラス・レベルのディレクトリ
/dev/rdisk
に同じデバイス名があります。
テープ - デバイス・ファイル名は,ベース名と,文字
_d
の後に 1 個の整数を続けた接尾語で構成されます。たとえば,tape0_d0
のようになります。この接尾語は,/etc/ddr.dbase
ファイルにおけるデバイスのエントリに従ってテープ・デバイスの密度を表わします。たとえば次のようになります。
デバイス | 密度 |
tape0 |
省略時密度 |
tape0c |
圧縮付き省略時密度 |
tape0_d0 |
/etc/ddr.dbase
のエントリ 0 に対応する密度 |
tape0_d1 |
/etc/ddr.dbase
のエントリ 1 に対応する密度 |
新しいデバイス特殊ファイル名の接尾語と旧式のテープ・デバイス名の接尾語には,次に示す直接の対応関係があります。
旧式のデバイス名の接尾語 | 新しい接尾語 |
l (low) | _d0 |
m (medium) | _d2 |
h (high) | _d1 |
a (alternate) | _d3 |
テープ・デバイスについては,次に示すように,2 つの異なるデバイス名のセットが新しい命名規則に従っています。
/dev/tape
- このディレクトリには,巻き戻しテープ・デバイス用の名前が含まれます。
/dev/ntape
- このディレクトリには,非巻き戻しテープ・デバイス用の名前が含まれます。
使用するデバイス特殊ファイルを判断するには,/etc/ddr.dbase
ファイルを調べます。
デバイス特殊ファイルを対象とするコマンドを使用するシェル・スクリプトがある場合には,その中で使用しているオペレーティング・システム付属のコマンドやユーティリティごとに,新しいファイル名と旧式のファイル名に対するサポートが次のように異なるので,注意してください。
どちらの形式のデバイス名もサポートする。
新しいデバイス名のみをサポートする。旧式のデバイス名を使用している場合,このタイプのコマンドは使用できません。
旧式のデバイス名のみをサポートする。新しいデバイス名を使用している場合,このタイプのコマンドは使用できません。
ただし,どのデバイスも形式の異なるデバイス名を同時に使用することはできません。シェル・スクリプトがデバイス命名方法に適合しているかテストしてください。コマンドのリファレンス・ページやオンライン・ヘルプを参照してください。
スクリプトを更新する場合は,旧式の名前から対応する新しい名前へ簡単に変換できます。旧式のデバイス名と,それに対応する新しいデバイス名の例をいくつか,表 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 |
ほとんどの場合,デバイス特殊ファイルの管理はシステム自身が行います。オペレーティング・システムを最初にフル・インストールする際,そのシステムで検出された 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)
class
- デバイス・クラス。disk
(ブロック型デバイス),rdisk
(文字型デバイス),tape
(巻き戻し型テープ・デバイス) などがあります。この情報を
dsfmgr -a
(追加) または
dsfmgr -r
(削除) コマンド・オプションで使用して,クラスの追加または削除を行います。
category
- デバイス・カテゴリ。たとえば,SCSI ディスク,CD-ROM リーダ,フロッピィ・ディスク・リーダはすべて
disk
カテゴリに属します。この情報を
dsfmgr -a
(追加) または
dsfmgr -r
(削除) コマンド・オプションで使用して,カテゴリの追加または削除を行います。
異常な状況では,デバイス・データベースが壊れたり,デバイス特殊ファイルが間違ってシステムから削除されてしまうことがあります。デバイスを使用できないというエラーが表示されているにもかかわらず,デバイス自体は故障しているように見えないこともあります。デバイス特殊ファイルに問題がありそうな場合は,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
この例では,ERROR
が
WARNING
に変わり,フロッピィ・ディスクのデバイス特殊ファイルが自動的に作成されることを示しています。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
dsfmgr -m
(移動) コマンド・オプションを使用して,デバイス特殊ファイルをデバイス間で移動する (再割当てする) ことができます。また,-e
オプションを使用して,デバイス特殊ファイルを他のデバイスと交換することもできます。たとえば次のようにします。
# /sbin/dsfmgr -m dsk0 dsk10 # /sbin/dsfmgr -e dsk1 15
次の手順は,これらのコマンド・オプションを使用してテープ・デバイスの交換をする方法を示す例です。この例では,故障した内蔵テープ・ドライブの緊急代替装置として,デスクトップ型の TLZ06 (DAT) SCSI ドライブを使います。この手順は,内蔵テープ・ドライブの交換やテープ・チェンジャ (ジュークボックス) にマウントされているドライブの追加と削除にも適用できます。
この手順は,利用可能な SCSI アドレスと (必要に応じて) 適切な SCSI 空きポートを持つすべての構成に適用されます。空いている SCSI バスがなければ,故障したテープ・ドライブを先に取り外してから代替機を取り付ける必要があるかもしれません。テープ・ドライブを追加したら,システムを再起動する必要があります。一般的にシステムが再起動に要する時間だけファイル・システムが利用できないことをユーザに知らせてください。
以下の手順では,既存のデバイスの名前を新しくインストールするデバイスに付け直したいものとし,システムが新しいデバイスに自動的に割り当てる名前を使わないものとします。たとえば,システムに接続されている 3 つのデバイスのうち,テープ・デバイス
tape0
を使うバックアップ・スクリプトを作成したとします。使われていないのは,tape1
と
tape2
です。tape0
が故障し,これを新しいデバイスに置き換えると,新しいデバイスには
tape3
という名前が割り当てられます。しかし,バックアップ・スクリプトはなくなったデバイスを指定しているので,処理が失敗します。新しいデバイス名を指定するようにスクリプトを書き換えるか,デバイスの名前を変えて,故障したデバイスの名前にする必要があります。
または,デバイス名の自動作成機能の利点を考慮して,ローカルのスクリプトとユーティリティがデバイス名に依存しないようにします。そうすれば,スクリプトはハードウェア構成の変更にかかわりなく動作し続けられます。dsfmgr
と
hwmgr
コマンドを使えば,システム構成を照会して,デバイスの特性と属性を動的に知ることができます。この方法の場合,本来のターゲットが使用不可能になったときに正常なデバイスにフェールオーバできるため,より効率的です。
この手順の実行に先立ち,必ず以下を実行してください。
代替のテープ・ドライブと適切な接続ケーブルを入手します。システムのオンライン仕様書を参照し,サポートされているオプションに関する情報を入手します。たとえば,『AlphaServer ES40 QuickSpecs』 などを参照します。旧式のプロセッサの場合,サポートされているオプションのリストに,テープ・デバイスの最近のモデルが含まれていないことがあります。しかし,使用に関して制限があれば,デバイスに付属のインストレーション・ドキュメントに記載されているのが一般的です。
注意
テープ・ドライブが正しい SCSI モード (SCSI 2,Fast Wideなど) をサポートしていて,使用する SCSI バス・アダプタに対応していることを必ず確認してください。よくわからないときは,技術サポート窓口までご連絡ください。
システムから削除するデバイス,および,システムへ追加するデバイスのオーナーズ・マニュアルを用意します。オーナーズ・マニュアルには,ここに書かれていない,安全にかかわる重要な情報が書かれています。また,システムの損傷を防ぐための重要な情報が含まれていることもあります。手順の実施にあたっては,オーナーズ・マニュアルの説明に従ってテープ・ドライブの SCSI ターゲットを設定する必要があるかもしれません。
システムのファームウェアが最新版か確認します。この情報とダウンロード・キットは,「Firmware Updates」 Web ページで入手できます。
hwmgr
コマンドの使い方の詳細については,
hwmgr
(8)
手順は次のとおりです。
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 デバイスの記録をとっておくために,出力をパイプに通してファイルに書き出してください。
このコマンド出力は,この手順にとって重要な以下の情報を提供します。
ハードウェア識別子 (HWID) は,システムによってデバイスに割り当てられる整数値です。上の例では,HWID 41 (tape0
) が故障したデバイスです。
SCSI DEVICEID (デバイス識別子) は整数値です。これは,did
とも呼ばれます。この数値は,デバイスを SCSI データベースから削除するときに指定します。
DEVICE FILE は,device:instance
という形式の文字列です。たとえば,テープ・ドライブ 1 の場合は
tape1
となります。これは,巻き戻し型のテープ・デバイスを表すデバイス特殊ファイル
/dev/tape/tape1
の場所を示す省略形です。非巻き戻し型のデバイスを表すデバイス特殊ファイルは
/dev/ntape
ディレクトリにあります。
FIRST VALID PATH は,SCSI バス,ターゲット,論理ユニット番号 (LUN) を表す文字列です。この文字列は,3 つの整数値で構成され,N/N/N という形式です。このデータは,デバイスへの最初の有効なパスを示します。
テープ・ドライブの追加または交換をするとき,新しいデバイスで使用できる空いている SCSI バス・ターゲットを知る必要があります。TLZ06 のようなテープ・デバイスは多くの場合,SCSI ターゲットを手作業で設定する方法があり,オーナーズ・マニュアルに記載されています。未使用のアドレスを書き留めておいてください。先の例では,バス 1 は,アドレス位置 3 にデバイスが 1 つだけあります。これが既存のテープ・デバイスです (1/3/0
)。したがって,テープ・デバイスの SCSI ターゲットは
1
,2
,または
4 〜 6
に設定できます。
注意
hwmgr
コマンドの出力で,VALID PATH 欄に空のフィールドがある場合,バス,ターゲット,LUN アドレスの欠如はデバイスの I/O に問題があります。これがデバイスの故障の原因かもしれません。この手順の終わりにあるトラブルシューティングの説明で,この可能性について取り上げます。
FIRST VALID PATH 欄の 1 つ以上のエントリが空の場合,残りの (割り当て済みの) アドレスを書き留めておいてください。どのアドレスがないかは,手順 3 に従って調べることができます。
sysman shutdown
または
shutdown
コマンドを使って,全ユーザに通知を出し,システムをシャットダウンします。オペレーティング・システムを停止するには,-h
(halt) オプションを使います。たとえば次のようにします。
# shutdown -h +10 "System shutting down to replace backup device \ Back in 15 minutes"
コンソールのプロンプトで,次のコマンドを実行して現在割り当てられているデバイスのアドレスを知ることができます。
>>> show config
このコマンドの出力には,各 SCSI バスに接続されているデバイスのリストが含まれています。たとえば,MKB300.3.0.13.0
は,バス
B
のターゲット
3
に接続されている TLZ06 テープ・デバイスに対応するエントリです。末尾の 3 つの数字は,バス,ターゲット,LUN アドレスです。
手順 1
で利用可能なバス・アドレスがわからなかったら,show config
コマンドの出力から知ることができます。
前面パネルのスイッチを使ってシステムの電源を切り,少なくとも 20 秒待ってからケーブルの取り外しを始めます。
以下の手順は,次のいずれかに該当する場合にのみ実施してください。該当しない場合は,手順 6 へ進んでください。
テープ・ドライブをシステムから恒久的に取り外し,新しいテープ・ドライブと置き換えない。
(テープ・ドライブを別の場所で使うために,システムから一時的に取り外すことができます。システム・レコードは残るので,テープ・デバイスを後で置き換えてシステム・レコードを再割り当てできます。)
新しいテープ・ドライブをインストールする前に,既存のテープ・ドライブを取り外す必要がある。理由としては,テープ・ドライブが内蔵ベイにインストールされている,場所不足のために論理バス・アドレスを再利用する必要がある,といったことが考えられます。
どちらかに該当する場合には,次のようにします。
テープ・ドライブへの電源を切り,オーナーズ・マニュアルに書かれている手順に従って,システムからテープ・ドライブを物理的に取り外します。
コンソールのプロンプトで,次のようにしてシステムをシングル・ユーザ・モードで起動します。
>>> boot -flags s
テープ・ドライブを削除するには,次のコマンドを使用します。
# /sbin/hwmgr delete scsi -did NN
-did オプションに対して指定している値は,手順 1 で調べた SCSI DEVICEID です。
まれな状況で,削除が完全でないことがあります。デバイスが削除されたかどうか,手順 1
で説明したように
hwmgr show scsi
コマンドを再度実行して調べます。また,/dev/tape
ディレクトリと
/dev/ntape
ディレクトリの中を調べて,デバイス特殊ファイルがないことを確認します。
システムにデバイスのレコードが少しでも残っていたら,この手順の終わりにあるトラブルシューティングの説明を参照してください。
この手順は,テープ・デバイスを置き換える場合にのみ実施してください。
新しいテープ・ドライブを,オーナーズ・マニュアルの説明に従って接続します。テープ・ドライブの電源とシステムの電源を適切な順番で入れます。
システムをリブートし,次のようにしてシングルユーザ・モードにします。
>>> boot -flags s
ブート・プロシージャを監視し,メッセージに注意します。リブートの過程で,新しいテープ・ドライブは自動的に検出され,次のようなメッセージがコンソールに表示されます。
dsfmgr: Note creating device special files +tape16...
このメッセージは,新しいテープ・デバイスが検出され,デバイス特殊ファイルが
/dev/tape
また
/dev/ntape
ディレクトリに作成されることを示します。このようなメッセージが表示されなかったら,デバイス特殊ファイルを手作業で作成する必要があります (ただし,先に移行の手順を最後まで実行してみること)。
システムをリブートして,マルチユーザ・モードになったら,次のコマンドを入力して新しく追加したテープ・ドライブに関する情報を表示します。
# /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
) よりもかなり大きいことに注目してください。
デバイスを交換したら,次の作業も行う必要があるかもしれません。
既存の (故障していると思われる) テープ・ドライブのデバイス名を交換ドライブに移す。それには,次のように
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
に変わっています。
デバイス特殊ファイルの番号を低い番号または
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
に変わっています。
この手順に含まれているチェックポイントによって,作業は問題なく終わるはずです。しかしまれに,新しいテープ・ドライブの追加または既存テープ・ドライブの取り外しが失敗することがあります。その場合には,次のトラブルシューティング手順に従って問題を解決できます。
フィールド・サービス窓口に連絡する必要が生じた場合に備えて,どのオプションを試したか記録を残しておくようにしてください。
hwmgr
と
dsfmgr
コマンドをさまざまに組み合わせる試行錯誤による方法は避けてください。ほとんどの場合,問題の原因はデバイスに関係するデータベースのレコードが中間的な状態になっていることです。コマンド・オプションをあれこれ試すと,かえって問題が複雑になる可能性があります。
Event Manager (EVM) ビューアを起動し,優先度 300 以上のイベントが表示されるように構成されていることを確認します。
# /usr/sbin/sysman event_viewer
イベント・ビューアを使って,手順の実行によって生成されるハードウェア・イベントを確認したり,エラーを発見したりできます。最新のイベントを見るには,イベント・ビューアの表示を更新する必要があります。イベント・ビューアには,テープ・ドライブが検出され,新しいベース名 (tape*
) とハードウェア識別子 (HWID) が割り当てられたことを示すイベントが表示されます。システムがこれらのイベントを通知するまで少し時間がかかったり,イベントを見るためにイベント・ビューアを更新する必要があったりするかもしれません。
SCSI バスをスキャンし,検出されたすべての新しいデバイスに識別子を割り当てるには,次のコマンドを使います。
# /sbin/hwmgr scan scsi hwmgr: Scan request successfully initiated
ハードウェア・スキャンは非同期で実行されるので,システム・プロンプトにすぐに戻りますが,それはスキャンが終わったことを示すわけではありません。SCSI デバイスの数が多いシステムでは,スキャンに数分かかることがあります。スキャンが完了するまで待ってください。通常,スキャンはシステム起動時に自動的に行われるため,処理が完了してもメッセージが表示されません。
スキャンが完了したら,次のコマンドを実行してテープ・ドライブが検出されたことを確認します。
# /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]
手順 4
の
hwmgr
の出力に,含まれているべきデバイス特殊ファイルが含まれていなければ,新しく追加したデバイスのデバイス特殊ファイルが作成されているかどうかを確認します。必要に応じて,/dev/tape
ディレクトリまたは
/dev/ntape
ディレクトリの内容を確認します。
デバイス特殊ファイルが見つからなければ,dsfmgr
コマンド (
dsfmgr
(8)
# /sbin/dsfmgr -K +tape16 +tape16_d0 +tape16_d1...
以上の手順で問題が解決しなければ,デバイス・データベースが中間的な状態になっている可能性があります。テープ・ドライブの HWID またはデバイス特殊ファイル名を指定して,/etc/dfsc.dat
ファイルの中でテープ・ドライブのエントリを探します。たとえば,テープ・ドライブがリスト出力に
tape0
と表示されている場合には,次のコマンドを入力します。
# grep "tape0" /etc/dfsc.dat
次のような出力が得られます。
A: 0 130003e 48 9 6 c "" /dev/tape tape 0
この出力の第 4 欄にハードウェア識別子 (HWID) があります。ここでは
48
です。
前の手順でわかった HWID 48 を指定し,次のコマンドを使ってデバイスの状態を確認します。
# /sbin/hwmgr show component -id 48
コマンドから何か出力された場合には,技術サポート窓口までご連絡ください。さもなければ,次の手順に進みます。
依然としてデバイスにアクセスできなければ,システムを再起動してデバイス・データベースをリセットします。システムを再起動することもできなければ,技術サポート窓口までご連絡ください。
システムのコンポーネントを再構成すると (たとえば,デバイスを削除するなど),デバイス特殊ファイルに割り当てられているインスタンス番号がインクリメントされます。時間がたつにつれて,デバイス特殊ファイルが無作為に番号付けされているように見えてきます。また,クローニング,コピー,削除の手順を用いてシステムをバックアップした場合,バックアップのたびにインスタンス値が大きくなり,デバイス名が長くなって管理しにくくなってきます。クローニング・バックアップ・プログラムも,バックアップのたびに新しいデバイス・インスタンスを知る必要があるため,デバイス特殊ファイル名の変更によって,バックアップに要する時間が長くなります。
dsfmgr -vI
コマンド・オプションを使うことによって,各デバイスのインスタンス番号を可能限り最小の値にリセットできます。システムの構成がバックアップ・プロシージャを除いて固定の場合,このオプションを使うことで,クローニングされるバックアップ・デバイスは,セットが改まるたびに同じ新しい名前を持つようになり,バックアップ・プロシージャが簡単になります。次の手順は,dsfmgr -vI
コマンドを使ってすべてのデバイスのインスタンス値を可能な限り最小の値にリセットする方法を示します。この手順は,dsfmgr -vI
コマンドの仕組みを示します。
次の (一部省略された) 出力は,新しくインストールされたシステムでテープ・ドライブのデバイス特殊ファイルがどのように番号付けされているかを示します。
# /sbin/hwmgr view device 61: /dev/ntape/tape0 COMPAQ SDT-10000 bus-5-targ-0-lun-0
システムの構成に多数の変更が加えられた状況を再現するために,次のコマンドでテープ・ドライブのデバイス特殊ファイルの番号を 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.......
次の (一部省略された) 出力は,テープ・ドライブのデバイス特殊ファイルの番号が大きくなって
tape40
に変わったことを示します。
# /sbin/hwmgr view device .61: /dev/ntape/tape40 COMPAQ SDT-10000 bus-5-targ-0-lun-0
システムからデバイスを削除した状況を再現するために,次のコマンドでテープ・ドライブのデバイス特殊ファイルの番号を 10 にします。
# /sbin/dsfmgr -m tape0 tape40 tape40>tape10
これは,11 から 39 の範囲で未使用のデバイス特殊ファイルのインスタンスがあることを意味します。しかし,システムは現時点ではこれらのインスタンスが空いていることを知らないので,新しくインストールされたデバイスをインスタンス番号 41 から番号付けをします。
システムが可能な限り小さいインスタンス番号を割り当てるようにするには,次のコマンドを実行します。
# /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 であることを示します。
処理が正しく行われたことを確かめるために,次のコマンドを使ってテープ・デバイスの削除と再スキャンを行い,システムが新しいデバイス特殊ファイルにインスタンス番号 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
コマンド・オプションを実行する新しいスクリプトを作成します。あるいは,ハードウェアの構成を変えるたびにこのコマンドを実行するようにします。