JP2002049575A - ファイルシステム - Google Patents

ファイルシステム

Info

Publication number
JP2002049575A
JP2002049575A JP2000233291A JP2000233291A JP2002049575A JP 2002049575 A JP2002049575 A JP 2002049575A JP 2000233291 A JP2000233291 A JP 2000233291A JP 2000233291 A JP2000233291 A JP 2000233291A JP 2002049575 A JP2002049575 A JP 2002049575A
Authority
JP
Japan
Prior art keywords
path
file
disk
node
management table
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2000233291A
Other languages
English (en)
Other versions
JP3992427B2 (ja
Inventor
Akihiro Ito
昭博 伊藤
Naoki Utsunomiya
直樹 宇都宮
Koji Sonoda
浩二 薗田
Hiroyuki Kumazaki
裕之 熊▲崎▼
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP2000233291A priority Critical patent/JP3992427B2/ja
Priority to EP00127995A priority patent/EP1179770B1/en
Priority to US09/746,608 priority patent/US6654769B2/en
Publication of JP2002049575A publication Critical patent/JP2002049575A/ja
Priority to US10/695,149 priority patent/US7130868B2/en
Priority to US11/527,363 priority patent/US20070016751A1/en
Application granted granted Critical
Publication of JP3992427B2 publication Critical patent/JP3992427B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2053—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant
    • G06F11/2056—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant by mirroring
    • G06F11/2087—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant by mirroring with a common controller
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2002—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where interconnections or communication control functionality are redundant
    • G06F11/2007—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where interconnections or communication control functionality are redundant using redundant communication media
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2002—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where interconnections or communication control functionality are redundant
    • G06F11/2007—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where interconnections or communication control functionality are redundant using redundant communication media
    • G06F11/201—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where interconnections or communication control functionality are redundant using redundant communication media between storage system components
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2023—Failover techniques
    • G06F11/2033—Failover techniques switching over of hardware resources
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/0614—Improving the reliability of storage systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0629—Configuration or reconfiguration of storage systems
    • G06F3/0635—Configuration or reconfiguration of storage systems by changing the path, e.g. traffic rerouting, path reconfiguration
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/067—Distributed or networked storage systems, e.g. storage area networks [SAN], network attached storage [NAS]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F2003/0697—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers device management, e.g. handlers, drivers, I/O schedulers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0638—Organizing or formatting or addressing of data
    • G06F3/0643—Management of files
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/953—Organization of data
    • Y10S707/959—Network
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99951—File or database maintenance
    • Y10S707/99952—Coherency, e.g. same view to multiple users
    • Y10S707/99953—Recoverability

Abstract

(57)【要約】 【課題】 ＩＯパス切り替えのために要する時間を短縮
し、一般ユーザからＩＯパス切り替え処理を隠蔽するこ
とのできるファイルシステム。 【解決手段】 ファイル毎にファイルＩＤが定義されて
いるシステムにおいて、ユーザアプリケーションＵＡＰ
からのファイルＩＤを指定したアクセス要求に対して、
ファイルサーバＦＳはファイル管理テーブルを参照し、
そのファイルをアクセスするための論理ディスクＩＤを
求める。ファイルサーバは、さらに、論理ディスク管理
テーブルを参照し、論理ディスクＩＤに対応するＩＯパ
スを求め、そのＩＯパスを使って物理ディスク装置にア
クセスする。運用系のＩＯパスに障害発生時、全ノード
の論理ディスク管理テーブルを書き換えることによって
ＩＯパスの切り替えを行う。

Description

【発明の詳細な説明】
【０００１】
【発明の属する技術分野】本発明は、複数のディスク装
置に分散管理されたファイルの処理を行うファイルシス
テムに係り、特に、１つのディスク装置へアクセスする
ためのＩＯパスが複数存在する場合に、ＩＯパスの切り
替えを制御を行って一方のパスからディスク装置へアク
セスすることができるファイルシステムに関する。
【０００２】
【従来の技術】従来技術によるファイルシステムの１つ
であるＵＮＩＸ（登録商標）ファイルシステムは、各フ
ァイル毎にユニークに決まる番号（ファイルＩＤ）が定
義されており、ファイルサーバがファイルＩＤを指定す
ることによって、リード・ライト処理を行うファイルを
特定することができる。そして、ファイルサーバは、フ
ァイルＩＤとそのファイルが格納されているディスク装
置にアクセスするためのＩＯパス（ＩＯパスを決定する
情報は、ノード番号、ＩＯインターフェイス番号、装置
番号などである）との対応関係をメモリ上のファイル管
理テーブル（ＵＮＩＸではｉｎｏｄｅと呼ばれる）に登
録して管理している。この管理方法については、例え
ば、(The Design of The Unix Operating System; Maur
ice J. Bach; p60-p72)に述べられている。
【０００３】ファイルＩＤを指定したリード・ライトア
クセス要求に対して、ファイルサーバは、前述のファイ
ル管理テーブルを参照し、ファイルＩＤからディスク装
置にアクセスするためのＩＯパス名を決定し、そのＩＯ
パスを用いてディスク装置にアクセスを行う。ファイル
管理テーブルには、ＩＯパス情報の他に、ファイルサイ
ズやファイルの更新日付などのファイル管理情報が登録
されており、このファイル管理情報は、ファイルがオー
プンされたとき、ディスク装置から読み出され、定期的
あるいはファイルをクローズしたときに、ディスク装置
に書き戻される。ユーザがファイルにアクセスするとき
指定するファイル名からファイルＩＤへの変換は、ファ
イルサーバが行っている。
【０００４】また、複数のディスク装置をシステムで取
り扱う場合、あるディスク装置Ａで管理されるディレク
トリネームツリー内のいずれかのディレクトリ、例え
ば、Ｘに別のディスク装置Ｂで管理されるネームツリー
を組み込むという操作によって、複数のディスク装置を
１つのネームツリー内に見せるという方法が知られてい
る。この方法によれば、ユーザは、ディレクトリＸにア
クセスすればディスク装置Ｂ内のファイルにアクセスす
ることができる。この方法は、マウント処理と呼ばれて
いるものである。ファイルサーバは、起動時にある特定
のディスク装置（ルートデバイス）を起点として前述し
たマウント処理を次々に行い、ユーザには複数のディス
ク装置を１つのネームツリーとして見せるようにしてい
る。この起動時におけるマウント処理を行うためのディ
スク装置とネームツリー上のディレクトリ名（マウント
ポイント）との対応関係を記述した情報は、ルートデバ
イスにマウント構成ファイルとして記録されており、フ
ァイルサーバは、起動時にこのマウント構成ファイルに
記載された情報に従ってマウント処理を行う。
【０００５】マウント構成ファイルには、ディスク装置
を特定する情報として、そのディスク装置にアクセスす
るためのＩＯパスの情報が記載されている。ファイルサ
ーバは、マウント処理の実行時に、マウント構成ファイ
ルに記載されたＩＯパスとマウントポイントとの対応関
係をメモリ上のマウント構成情報に読み込む。そして、
ファイルサーバは、ユーザがファイル名を指定してファ
イルをオープンするとき、前述のマウント構成情報を元
にファイルが格納されている物理ディスク装置にアクセ
スするためのＩＯパスを求め、ファイル管理テーブルを
作成する。従って、システム管理者は、システムに新し
いディスク装置を接続するなどしてシステムの構成を変
更したとき、マウント構成ファイルを書き換えることに
よって、新しい構成情報を計算機システムに設定する必
要がある。
【０００６】一方、計算機システムの信頼性を向上させ
るため、異なる２つのノードを１つのディスク装置に物
理的に接続し、異なる２通りのＩＯパスからディスク装
置にアクセスすることができる構成にしておき、通常の
運用時に一方のＩＯパスを使用し、ノード障害が発生し
て使用中のＩＯパスが使用できなくなったとき、もう一
方のＩＯパスを用いて別のノードからディスク装置にア
クセスするようにすることによって、障害発生時におい
てもディスク装置の可用性（アベイラビリティ）を保つ
方法が、例えば、特開平１０−２７５０９０号公報等に
記載されて知られている。
【０００７】また、ディスク装置の信頼性を向上するた
めに、ファイルを複数のディスクに多重化して記録する
方法（ミラーリング）がよく知られている。ミラーリン
グを行う場合、一般に、論理ボリュームという概念が用
いられる。ミラーリングは、複数の物理ディスク装置
を、１つの論理ボリュームとしてユーザに見せる仕組み
である。ユーザは、予め複数の物理ディスク装置の情報
を登録した「論理ボリューム」を作成しておく。そし
て、ユーザがこの論理ボリュームに対して、物理ディス
ク装置と同様にアクセスすると、複数の物理ディスクへ
のファイルのミラーリングが行われる。論理ボリューム
を使用することにより、ファイルを複数のディスク装置
に分散記録するストライピングを行うことも可能とな
る。
【０００８】
【発明が解決しようとする課題】前述で説明した使用中
のＩＯパスが使用不可能になったとき、物理ディスク装
置にアクセスするためのＩＯパスを別のＩＯパスに切り
替える処理を、従来のＵＮＩＸのファイルシステムに適
用して動的に行おうとすると、ファイル管理テーブル及
びマウント構成情報を検索し、使用できなくなったＩＯ
パス名を新しいＩＯパス名に書き換える操作を行う必要
がある。前述のファイル管理テーブルのエントリを書き
換える処理は、オープンされているファイルの個数だけ
全てについて行わなければならない。この結果、従来の
ＵＮＩＸのファイルシステムに、前述したＩＯパスの切
り替えの技術を適用した場合、ファイル管理テーブルの
エントリを書き換える処理に時間がかかり、その間その
物理ディスク装置にＩＯ処理を行うことができないとい
う問題点を生じることになる。
【０００９】また、ＩＯパスに障害が発生したときに、
単純にＩＯパスを切り替えるだけでは、障害発生前に物
理ディスク装置にアクセスを行っていたノードが持って
いたバッファキャッシュ（物理ディスク装置にリード・
ライトするときにデータを一時的に蓄えておき、メモリ
に比べて処理速度の遅い物理ディスク装置への入出力回
数を削減するためのメモリ領域）やファイル管理テーブ
ル、及び、ディスク装置上のディスクキャッシュ（バッ
ファキャッシュと同様の目的のために物理ディスク装置
が備えるキャッシュメモリ）の内容が正常に物理ディス
ク装置に書き戻されず、大切なデータが消えてしまうと
いう問題点をも生じる。しかも、これが原因でファイル
システムの整合性が異常となるため、物理ディスク装置
に冗長に記録されたファイルシステムの情報を元にファ
イルシステムの整合性を正常状態に戻す操作が必要とな
る。この操作は、ディスク装置全体をチェックする必要
があるため、長い時間を要する。この結果、この間、そ
の物理ディスク装置に対するＩＯ処理を行うことはでき
ないという問題点を生じさせてしまう。
【００１０】さらに、ＩＯパス切り替え後、新しいＩＯ
パスを用いてディスク装置にアクセスを行うので、ＩＯ
パス切り替え後にシステムを再起動したときにマウント
処理が正常に行われるようにするには、システム管理者
がマウント構成ファイルを更新し、ディスク装置への新
しいＩＯパスとマウントポイントとの対応関係をマウン
ト構成ファイルに登録しなおす必要がある。また、ファ
イルのミラーリングを行う場合、論理ボリュームを作成
する必要があるが、論理ボリュームの管理は、システム
管理者に対して煩雑な作業を行わせることになる。
【００１１】本発明の第１の目的は、ＩＯパスの切り替
え処理のために要する時間を短縮し、一般ユーザからＩ
Ｏパス切り替え処理をできるだけ隠蔽することができる
ファイルシステムを提供することにある。また、本発明
の第２の目的は、ＩＯパスの切り替え時に、バッファキ
ャッシュやファイル管理テーブル及びディスク装置上の
ディスクキャッシュに保存されたデータを失うことなく
ＩＯパスの切り替え処理を行い、ファイルの整合性のチ
ェックを不要とすることができるファイルシステムを提
供することにある。また、本発明の第３の目的は、ＩＯ
パスを切り替えたとき自動的にマウント構成ファイルを
更新し、システム管理者の負担を軽減することのできる
ファイルシステムを提供することある。さらに、本発明
の第４の目的は、ユーザに論理ボリュームを意識させず
にファイルのミラーリングを行う方法を備えたファイル
システムを提供することにある。
【００１２】
【課題を解決するための手段】本発明によれば前記目的
は、ファイル毎にファイルＩＤが定義されており、複数
の物理ディスク装置に分散管理されたファイルの処理を
行う１または複数のファイルサーバを有するファイルシ
ステムにおいて、ファイルＩＤ及び該ファイルＩＤに対
応するファイルが格納されている論理ディスクの論理デ
ィスクＩＤを含むファイル管理テーブルと、論理ディス
クＩＤ及び前記論理ディスクに対応する１つ以上の物理
ディスク装置にアクセスするための１つ以上のＩＯパス
を含む論理ディスク管理テーブルとを備え、ユーザから
のファイルＩＤを指定したファイルへのアクセス要求を
受信したファイルサーバは、ファイル管理テーブルを参
照し、前記ファイルＩＤから前記ファイルが格納されて
いる論理ディスクの論理ディスクＩＤを決定し、論理デ
ィスク管理テーブルを参照して前記論理ディスクＩＤか
ら前記論理ディスクに対応する物理ディスク装置にアク
セスするためのＩＯパス（ＩＯパスを決定する情報は、
ノード番号、ＩＯインターフェイス番号、ディスクコン
トローラ番号である）を決定し、決定したＩＯパスを使
用して物理ディスク装置にアクセスすることにより達成
される。
【００１３】前述において、論理ディスク管理テーブル
は、該論理ディスク管理テーブルに登録されているＩＯ
パス毎に稼働状態（「使用中」、「待機中」、「使用不
可」）を保持する状態フラグを含み、通常運用時、ファ
イルサーバは状態フラグが「使用中」状態のＩＯパス
（運用系ＩＯパス）を用いて物理ディスク装置にアクセ
スする。前記運用系ＩＯパスの障害発生時、障害を検出
したノードのファイルサーバは、前記ノードの論理ディ
スク管理テーブルを更新し、前記障害発生ＩＯパスの状
態フラグを「使用不可」とし、状態フラグが「待機中」
状態であるＩＯパスの状態フラグを「使用中」として新
運用系ＩＯパスとした後、全リモートノードのファイル
サーバと通信を行い、前記論理ディスク管理テーブルの
内容を全ノードの論理ディスク管理テーブルに複写する
ことによって、前記物理ディスク装置にアクセスするた
めのＩＯパスを旧運用系ＩＯパスから新運用系ＩＯパス
に切り替える。
【００１４】このＩＯパス切り替え処理の間、前記障害
発生ＩＯパスに含まれるノードのファイルサーバは、旧
運用系ＩＯパスへのアクセス要求を保留し、ＩＯパス切
り替え処理終了時、保留していたアクセス要求を前記新
運用系ＩＯパスが含むノードに送信する。これによっ
て、ＩＯパス切り替え処理を動的に行うことが可能とな
り、ＩＯパス切り替え時ファイル管理テーブルを検索・
更新する必要をなくし、ＩＯパス切り替え処理に要する
時間を短縮することができる。
【００１５】また、前述において、ＩＯパスの切り替え
処理時、使用できなくなった旧運用系ＩＯパスを使って
アクセスしていた物理ディスク装置内に設けられたディ
スクコントローラが有するディスクキャッシュに格納さ
れたデータのうち、前記物理ディスク装置に書き戻す必
要のあるデータを、前記物理ディスク装置内に設けられ
た別のディスクコントローラを使用して前記物理ディス
ク装置に書き戻し、前記旧運用系ＩＯパスに含まれるノ
ードのファイルサーバと新運用系ＩＯパスに含まれるノ
ードのファイルサーバが通信を行うことによって、前記
旧運用系ＩＯパスに含まれるノードの主記憶内に存在
し、前記物理ディスク装置に書き戻す必要があるバッフ
ァキャッシュ及びファイル管理テーブルを前記新運用系
ＩＯパスに含まれるノードに転送する。本発明は、これ
によって、ディスク装置上のディスクキャッシュに存在
していたデータや、バッファキャッシュや、ファイル管
理テーブルが消失するのを防ぎ、ファイルシステムの整
合性のチェックを不要とすることができる。
【００１６】また、前述において、マウント構成ファイ
ルは、ＩＯパス毎にそのＩＯパスが使用できるか否かを
登録する使用可否情報を含み、ファイルサーバは、シス
テム起動時に前記マウント構成ファイルを読み込み、前
記使用可否情報に「使用可」と記載されたＩＯパスにつ
いて、対応する論理ディスク管理テーブルの状態フラグ
を「使用中」または「待機中」と登録し、前記使用可否
情報に「使用不可」と記載されたＩＯパスについて、対
応する論理ディスク管理テーブルの状態フラグを「使用
不可」と登録することにより、マウント構成ファイルに
「使用可」と記載されたＩＯパスだけを使用して物理デ
ィスク装置にアクセスをする設定を行っている。ＩＯパ
ス切り替え・切り離し処理終了後、ファイルサーバは、
前記マウント構成ファイルを更新し、使用できなくなっ
た旧運用系ＩＯパスの使用可否情報を「使用不可」に書
き換える。また、使用不可能となったＩＯパスが再び使
用できるようになったとき、ファイルサーバは、マウン
ト構成ファイルを更新し、使用可能になった前記ＩＯパ
スの使用可否情報を「使用可」に書き換える。このよう
に、本発明は、ＩＯパスが切り替わったときや復旧した
ときのマウント構成ファイルの書き換え処理を自動化す
ることにより、システム管理者の負担を軽減することが
できる。
【００１７】また、本発明は、マウント構成ファイルの
１つのエントリに書かれた複数のＩＯパスからアクセス
される複数のディスク装置に対して、ファイルのミラー
リングを行うことができ、これにより、ユーザが論理ボ
リュームを使用することなくファイルのミラーリングを
行うことができる。
【００１８】
【発明の実施の形態】以下、本発明によるファイルシス
テムの実施形態を図面により詳細に説明する。
【００１９】図１は本発明の第１の実施形態によるファ
イルシステムの構成を示すブロック図、図２はシステム
内に設けられる各種のテーブルの具対的な構成例を説明
する図、図３はマウント構成ファイルの具体的な構成例
を説明する図である。図１〜図３において、１はネット
ワーク、１０、２０、３０は物理ディスク装置、１１、
１２、２１、２２はディスクコントローラ、２４はマウ
ント構成ファイル、１００、２００、３００はノード、
１１０、２１０、３１０はＣＰＵ、１２０、２２０、３
２０はメモリ、１３０、２３０はユーザアプリケーショ
ン（ＵＡＰ）、１４０、２４０はファイルサーバ（Ｆ
Ｓ）、２５０はディスクドライバ、１６０、２６０はフ
ァイル管理テーブル、１７０、２７０は論理ディスク管
理テーブル、１８０、２８０はバッファキャッシュ、２
９０、３９０はＩＯインタフェースである。
【００２０】本発明の第１の実施形態によるファイルシ
ステムは、図１に示すように、超並列計算機システムを
構成するノード１００、２００、３００（図１では３つ
のノードのみを示しているが、ノードは多数設けられ
る）がネットワーク１によって相互に接続されて構成さ
れている。ノード２００とノード３００とには、両ノー
ドからアクセス可能な共用物理ディスク装置１０、２０
が接続されている。物理ディスク装置１０、２０は、そ
れらのディスク装置内に設けられたディスクコントロー
ラ１１、１２及びノード２００内に設けられたＩＯイン
ターフェイス２９０によってノード２００と接続される
と共に、ディスクコントローラ１２、２２及びノード３
００内に設けられたＩＯインターフェイス３９０によっ
てノード３００と接続されている。ノード１００に接続
されている物理ディスク装置３０は、物理ディスク装置
１０、２０と比べて障害発生率が極めて低い高信頼ディ
スク装置である。
【００２１】ノード２００は、ＣＰＵ２１０とメモリ２
２０とから構成される。メモリ２２０は、ユーザアプリ
ケーション２３０と、ファイル制御を行うファイルサー
バ２４０と、ディスクＩＯ処理を行うディスクドライバ
２５０と、ファイル管理テーブル２６０と、論理ディス
クを定義している論理ディスク管理テーブル２７０と、
バッファキャッシュ２８０とを含む。ノード１００及び
ノード３００は、ノード２００と同様に構成されてい
る。
【００２２】物理ディスク装置にアクセスするための入
出力経路をＩＯパスと呼び、このＩＯパスは、ノード番
号、ＩＯインターフェイス番号、ディスクコントローラ
番号の３つの情報で決定され、ＩＯパスを決めると物理
ディスク装置を一意に決めることができる。例えば、
（ノード番号、ＩＯインターフェイス番号、コントロー
ラ番号）＝（２００，２９０，１１）というＩＯパスか
らは、物理ディスク装置１０にアクセスされる。以後の
説明において、ＩＯパスは、前述のような形式で記載す
ることとする。
【００２３】論理ディスクは、１つ以上の物理ディスク
装置を組み合わせたものとして構成される。その物理デ
ィスクの組み合わせは、ＩＯパスを指定することによっ
て行われる。例えば、（２００，２９０，１１）、（３
００，３９０，２２）という２つのＩＯパスを組み合わ
せると、物理ディスク装置１０、２０を纏めた論理ディ
スクを構成することができる。その際、物理ディスク装
置１０、２０に同一の内容を記録するようにすれば、論
理ディスクをミラー化することができる。また、（２０
０，２９０，１１）、（３００，３９０，１２）という
２つのＩＯパスを組み合わせると、これらのＩＯパスか
らは共に物理ディスク装置１０にアクセスされるため、
物理ディスク装置１０に対応する論理ディスクが構成さ
れる。但し、この場合、物理ディスク装置１０にアクセ
スするためのＩＯパスが２通り存在するので、片方のＩ
Ｏパスに障害が発生した場合でも、別のＩＯパスから物
理ディスク装置１０にアクセスすることができ、これに
よって、ディスク装置の信頼性の向上を図ることができ
る。説明する本発明の第１の実施形態は、論理ディスク
が１つの物理ディスク装置に対応する後者の場合を例と
して取り扱う。
【００２４】論理ディスク管理テーブル２７０は、図２
（ｂ）に示すように、論理ディスクＩＤ２７１と、ノー
ド番号２７２、２７６と、ＩＯインターフェイス番号２
７３、２７７と、ディスクコントローラ番号２７４、２
７８と、状態フラグ２７５、２７９とから構成される。
２７２〜２７４は、論理ディスクＩＤ２７１に対応する
物理ディスク装置にアクセスするための第１のＩＯパス
を決定し、状態フラグ２７５には、このＩＯパスの稼働
状態（「使用中」、「待機中」、「使用不可」のいずれ
か）が登録される。２７６〜２７８は、物理ディスク装
置にアクセスするための第２のＩＯパスを決定し、この
ＩＯパスの稼働状態が状態フラグ２７９に登録される。
このように論理ディスク管理テーブル２７０には、１つ
の論理ディスクＩＤに対して２通りのＩＯパスとそれぞ
れのＩＯパスの状態フラグを登録できるようになってい
る。
【００２５】本発明の第１の実施形態において、前述の
２つのＩＯパスからアクセスされる物理ディスク装置は
同一のものであり、通常運用時は２つのＩＯパスのうち
１つを使用し（状態フラグが「使用中」状態になってい
る）、もう一方のＩＯパスを「待機中」状態としてお
き、ディスクコントローラやＩＯインターフェイスの障
害等の原因により、使用中のＩＯパスが使用できなくな
ったとき、ファイルサーバが物理ディスク装置にアクセ
スするためのＩＯパスを「待機中」状態のＩＯパスに切
り替える。このように、論理ディスク管理テーブルは、
論理ディスクＩＤと物理ディスク装置にアクセスするた
めのＩＯパスとを対応付けることによって、仮想的なデ
ィスク装置として論理ディスクを定義している。論理デ
ィスクＩＤはこの論理ディスクを識別するための番号で
ある。
【００２６】また、システムを構成する各ノードが持つ
論理ディスク管理テーブルの内容は常に同一となってい
る。例えば、図１において、ノード１００が持つ論理デ
ィスク管理テーブル１７０と、ノード２００が持つ論理
ディスク管理テーブル２７０と、ノード３００が持つ論
理ディスク管理テーブル３７０は常に同一の内容を有す
る。
【００２７】ファイル管理テーブル２６０は、図２
（ａ）に示すように、ファイルＩＤ２６１と論理ディス
クＩＤ２６２とファイル管理情報２６３とにより構成さ
れる。ファイルＩＤ２６１には、現在オープンされてい
るファイルのファイルＩＤが登録され、論理ディスクＩ
Ｄ２６２には、前述のファイルが格納されている論理デ
ィスクの論理ディスクＩＤが登録される。ファイル管理
情報２６３には、前述のファイルのファイルサイズや更
新日付等の情報が登録される。このファイル管理テーブ
ル２６０の各エントリは、ノード２００上で動作するプ
ログラムがファイルをオープンする度に、物理ディスク
装置上から各ファイル固有の情報として読み出される。
従って、ファイル管理テーブル２６０のエントリは、少
なくともオープンされているファイルの個数分存在す
る。
【００２８】バッファキャッシュ２８０は、物理ディス
ク装置にアクセスを行うときにリード・ライトするデー
タを一時的に蓄えておき、メモリに比べて処理速度の遅
い物理ディスク装置への入出力処理回数を削減するため
に使用される。バッファキャッシュ２８０は、図２
（ｃ）に示すように、論理ディスクＩＤ２８１とブロッ
ク番号２８２とキャッシュデータ２８３とから構成され
る。キャッシュデータ２８３には、論理ディスクＩＤ２
８１のブロック番号２８２で指定されるディスク領域の
データの内容が格納される。
【００２９】高信頼な物理ディスク装置３０内には、マ
ウント構成ファイル２４が格納されている。マウント構
成ファイル２４のエントリは、図３に示すように、シス
テムに接続される物理ディスク装置にアクセスするため
のＩＯパス名５１、５３と、そのＩＯパスが使用可能か
否かを示す使用可否情報５２、５４と、前述の物理ディ
スク装置に対応する論理ディスクをマウントするマウン
トポイント５５との３つの情報を含んでいる。マウント
構成ファイル２４には、ＩＯパス名が“（ノード番号，
ＩＯインターフェイス番号，ディスクコントローラ番
号）＝（２００，２９０，１１）”のような形式で記述
され、そのＩＯパスが使用可能な場合、マウント構成フ
ァイル２４の対応するＩＯパスの使用可否情報に“avai
lable” と記述され、そのＩＯパスが使用不可能な場
合、使用可否情報に“unavailable”と記述される。図
３に示した例では、ＩＯパス（２００，２９０，１１）
と（３００，３９０，１２）との両者がマウントポイン
ト ／mntに対応付けされており、共に使用可能となって
いる。この記述によって、ユーザが ／mntディレクトリ
以下のディレクトリツリー内のファイルにアクセスした
とき、物理ディスク装置１０にアクセスできるようにな
る。このとき、物理ディスク装置１０にアクセスするた
めのＩＯパスは、前述のいずれかのＩＯパスが使用され
る。使用していない方のＩＯパスは「待機中」状態とし
てスタンバイしている。
【００３０】前述のように、物理ディスク装置にアクセ
スするためのＩＯパスが２つ存在する場合、その２つの
ＩＯパスを同じエントリに記載することにより、２つの
ＩＯパスを１つのマウントポイントに対応付けることが
できる。マウント構成ファイル２４は、通常のエディタ
などで編集することが可能であり、システム管理者は、
システムの構成を変更したとき、マウント構成ファイル
２４の内容が新しいシステム構成と一致するように、マ
ウント構成ファイル２４を編集し、システムをリブート
させる。システムの起動時、ファイルサーバ１４０は、
修正後のマウント構成ファイル２４に従ってマウント処
理を行うので、リブート後、新しいシステム構成が使用
可能となる。例えば、図１に示した物理ディスク装置装
置２０をシステムに追加したとき、システム管理者は
“（（２００，２９０，２１） available） （（３０
０，３９０，２２） available） ／mnt1”という行を
マウント構成ファイル２４に追加してシステムをリブー
トする。この記述によって、ユーザが ／mnt1 ディレク
トリにアクセスしたとき、前述の追加行に記載したいず
れかのＩＯパスから物理ディスク装置２０にアクセスで
きるようになる。
【００３１】図４はシステムの起動時のファイルサーバ
の処理動作を説明するフローチャート、図５はシステム
全体のノードの論理ディスク管理テーブルを更新する処
理動作を説明するフローチャートであり、次に、これら
のフローを参照して、システムの起動時にファイルサー
バ１４０がマウント構成ファイル２４を読み込み、論理
ディスク管理テーブルを設定してマウント処理を行うま
での処理手順及び全ノードでの論理ディスク管理テーブ
ルの更新の処理手順を説明する。
【００３２】（１）システムの起動時、ノード１００内
のファイルサーバ１４０は、高信頼ディスク装置３０上
に格納されているマウント構成ファイル２４の１つのエ
ントリを読み込む（ステップ４０１、４０２）。
【００３３】（２）ファイルサーバ１４０は、マウント
構成ファイル２４に記載されたＩＯパス名に対して論理
ディスクＩＤを自動的に設定する。マウント構成ファイ
ル２４の１つのエントリに複数のＩＯパス名が記載され
ていた場合、ファイルサーバ１４０は、その複数のＩＯ
パスに対して１つの論理ディスクＩＤを設定する。例え
ば、図３に示した例の場合、ファイルサーバ１４０は、
ＩＯパス名５１“（２００，２９０，１１）”及びＩＯ
パス名５３“（３００，３９０，１２）”に対して論理
ディスクＩＤ“１２３”を設定する。ファイルサーバ１
４０は、これにより、設定した論理ディスクＩＤを論理
ディスク管理テーブル１７０の論理ディスクＩＤ１７１
に登録する（ステップ４０３）。
【００３４】（３）前述の第１のＩＯパス名をノード番
号１７２、ＩＯインターフェイス番号１７３、ディスク
コントローラ番号１７４に登録し、第２のＩＯパス名を
ノード番号１７６、ＩＯインターフェイス番号１７７、
ディスクコントローラ番号１７８に登録する。図３に示
した例の場合、論理ディスクＩＤ１７１には“１２
３”、ノード番号１７２には“２００”、ＩＯインター
フェイス番号１７３には“２９０”、ディスクコントロ
ーラ番号１７４には“１１”、ノード番号１７６には
“３００”、ＩＯインターフェイス番号１７７には“３
９０”、ディスクコントローラ番号１７８には“１２”
が登録される（ステップ４０４）。
【００３５】（４）そして、ファイルサーバ１４０は、
マウント構成ファイル２４の使用可否情報に “availab
le”と記載されている最初のＩＯパス“（２００，３９
０，１１）”について、論理ディスク管理テーブル１７
０の対応する状態フラグを「使用中」状態と登録し、
“available” と記載されている残りのＩＯパス“（３
００，３９０，１２）”について、対応する状態フラグ
を「待機中」状態と登録する。また、ファイルサーバ１
４０は、マウント構成ファイル２４の使用可否情報に、
“unavailable” と記載されているＩＯパスについては
対応する状態フラグを「使用不可」状態と登録する。こ
の結果、論理ディスク管理テーブル１７０の内容は、図
２に示したようなものとなる（ステップ４０５）。
【００３６】（５）ファイルサーバ１４０は、マウント
構成ファイル２４に記載された全てのエントリについ
て、論理ディスク管理テーブル１７０への登録が終了し
たか否かをチェックし、終了していない場合、ステップ
４０２からの処理を繰り返し実行して論理ディスク管理
テーブルへの登録を続ける（ステップ４０６）。
【００３７】（６）ステップ４０６で、マウント構成フ
ァイル２４に記載された全てのエントリについて、論理
ディスク管理テーブル１７０への登録が終了していた場
合、ファイルサーバ１４０は、全ての他のノード２０
０、３００であるリモートノードのファイルサーバと通
信を行い、システムを構成する全ノードの論理ディスク
管理テーブルの更新を行わせる（ステップ４０７）。
【００３８】（７）ファイルサーバ１４０は、全リモー
トノードから論理ディスク管理テーブルの更新完了の通
知を受信したら、マウント構成ファイル２４に記載され
ているＩＯパス名（“（２００，２９０，１１）”及び
“（３００，３９０，１２）”）とマウントポイント /
mnt との対応関係、及び、論理ディスク管理テーブル１
７０に登録した上記ＩＯパス名と論理ディスクＩＤ“１
２３”との対応関係から、マウントポイント /mnt と上
記論理ディスクＩＤ“１２３”との対応関係を作り、論
理ディスクＩＤ“１２３”に対応する論理ディスクをマ
ウントポイント /mnt にマウントする（ステップ４０
８）。
【００３９】次に、図５に示すフローを参照して前述し
たステップ４０７の処理時のファイルサーバ１４０及び
リモートノードのファイルサーバの処理動作を説明す
る。
【００４０】（１）ファイルサーバ１４０は、自ノード
１００の論理ディスク管理テーブルの設定を終了した
後、全リモートノードのファイルサーバに論理ディスク
管理テーブル１４０の内容を送信し、論理ディスク管理
テーブルを更新するように要求する（ステップ９０１、
９０２）。
【００４１】（２）この通知を受けたリモートノードの
ファイルサーバは、送信されてきた論理ディスク管理テ
ーブル１７０の内容を、そのノードの論理ディスク管理
テーブルに複写して論理ディスク管理テーブルの更新を
行い、ファイルサーバ１４０に論理ディスク管理テーブ
ルの更新終了を通知する（ステップ９０５〜９０７）。
【００４２】（３）ファイルサーバ１４０は、全リモー
トノードからそれぞれのノードの論理ディスク管理テー
ブルの更新完了通知を受信するのを待ち、図４により説
明したステップ４０８のマウント処理を実行して処理を
終了する（ステップ９０３、９０４）。
【００４３】図６は通常運用時のファイルサーバの処理
動作を説明するフローチャートであり、次に、このフロ
ーを参照して、通常運用時のファイルアクセスの手順に
ついて説明する。ここでは、ファイル管理テーブル１６
０、２６０及び論理ディスク管理テーブル１７０、２７
０の設定が図２に示すようになっているとして、ローカ
ルノードとしてのノード２００に接続された物理ディス
ク装置にアクセスする場合について、ノード２００上で
動作するユーザアプリケーション２３０が、ファイルＩ
Ｄ“１００”を指定したファイルアクセス要求をファイ
ルサーバ２４０に発行した場合を例に説明する。
【００４４】（１）ファイルサーバ２４０は、ユーザア
プリケーション２３０からの要求を受信すると、この要
求が他のノードであるリモートノードからの要求である
か否かを判定する（ステップ５０１、５０２）。
【００４５】（２）説明している例では、自ノードであ
るローカルノードのユーザアプリケーションからのアク
セスであるとしているので、ファイルサーバ２４０は、
ファイル管理テーブル２６０を検索し、ファイルＩＤ
“１００”からそのファイルＩＤで定義されるファイル
が格納されている論理ディスクの論理ディスクＩＤ“１
２３”を求める（ステップ５０３）。
【００４６】（３）そして、ファイルサーバ２４０は、
論理ディスク管理テーブル２７０を検索し、論理ディス
クＩＤから状態フラグが「使用中」状態のＩＯパス名
“（２００，２９０，１１）”を求め、そのＩＯパス名
に含まれるノード番号“２００”がローカルノードであ
るか否かを判定する（ステップ５０４、５０５）。
【００４７】（４）前述のＩＯパス名に含まれるノード
番号“２００”がローカルノードであるとして説明して
いるので、ステップ５０５で、前述のＩＯパス名に含ま
れるノード番号“２００”がローカルノードであると判
定され、ファイルサーバ２４０は、自ローカルノードの
ディスクドライバ２５０にＩＯパスを指定したＩＯアク
セス要求を送る。この要求を受けたディスクドライバ２
５０は、ＩＯインターフェイス２９０を介してディスク
コントローラ１１に制御信号を送る（ステップ５０
７）。
【００４８】次に、他のノードであるリモートノードに
接続された物理ディスク装置にアクセスする場合につい
て説明する。ここで説明する例は、ノード１００上で動
作するユーザアプリケーション１３０が、ファイルＩＤ
“１００”を指定したファイルアクセス要求をファイル
サーバ１４０に発行した場合であるとする。
【００４９】（１）ファイルサーバ１４０は、ユーザア
プリケーション１３０からの要求を受信すると、ローカ
ルノードに接続された物理ディスク装置にアクセスする
場合と同様に、ファイル管理テーブルを１６０を検索し
ファイルＩＤ“１００”から論理ディスクＩＤ“１２
３”を求め、論理ディスク管理テーブル１７０を検索し
て論理ディスクＩＤ“１２３”からＩＯパス名“（２０
０，２９０，１１）”を求める（ステップ５０１〜５０
４）。
【００５０】（２）ファイルサーバ１４０は、上記ＩＯ
パス名に含まれるノード番号“２００”がリモートノー
ドであることを確認すると、そのノード（ノード２０
０）のファイルサーバ２４０に上記論理ディスクＩＤを
指定したＩＯアクセス要求を送る（ステップ５０５、５
０６）。
【００５１】（３）この要求を受けたファイルサーバ２
４０は、論理ディスク管理テーブル２７０を検索し論理
ディスクＩＤ“１２３”から状態フラグが「使用中」状
態のＩＯパス名“（２００，２９０，１１）”を求める
（ステップ５０１、５０２、５０４）。
【００５２】（４）ファイルサーバ２４０は、ＩＯパス
に含まれるノード番号“２００”が自ノードであるロー
カルノードであることを確認して、ディスクドライバ２
５０にＩＯパスを指定したＩＯアクセス要求を送る。こ
の要求を受けたディスクドライバ２５０は、ＩＯインタ
ーフェイス２９０を介してディスクコントローラ１１に
制御信号を送る（ステップ５０５、５０７）。
【００５３】前述した処理動作の説明から判るように、
ファイルサーバが自ノードであるローカルノードからア
クセス要求を受ける場合、その要求は、全てユーザアプ
リケーションからの要求であり、他のノードであるリモ
ートノードからの要求を受ける場合、その要求は、全て
リモートノードのファイルサーバからの要求である。
【００５４】実際のファイルアクセス処理は、バッファ
キャッシュを経由して行われる。ファイルサーバ２４０
は、論理ディスクＩＤを指定したＩＯアクセス要求に対
する処理を、バッファキャッシュ２８０に対するリード
・ライト処理と、バッファキャッシュ２８０と物理ディ
スク装置１０との間でのリード・ライト処理とに分けて
行う。ファイルサーバ２４０は、バッファキャッシュ２
８０と物理ディスク装置１０との間のリード・ライトア
クセス処理との実行時に、論理ディスクＩＤからＩＯパ
ス名への変換を行う。ノード１００で動作するプログラ
ムが、リモートノードに接続された物理ディスク装置１
０にアクセスする場合、ノード１００上のバッファキャ
ッシュ１８０とノード２００上のバッファキャッシュ２
８０とを経由してアクセスが行われる。すなわち、ライ
ト処理を行う場合のデータの流れは、バッファキャッシ
ュ１８０→バッファキャッシュ２８０→物理ディスク装
置１０となる。リード処理の場合、この逆の順序とな
る。
【００５５】ユーザアプリケーションがファイルを更新
し、ファイルの更新日付が変わるなどして、ファイル管
理テーブルの内容が変更されたとき、ファイル管理テー
ブルの変更を物理ディスク装置に書き戻す必要がある。
次に、この書き戻し処理について説明する。
【００５６】ファイル管理テーブルの内容が変更され、
その内容をローカルノードに接続された物理ディスク装
置に書き戻す場合、ローカルノードのファイルサーバが
ローカルノードのファイル管理テーブルの内容を直接そ
の物理ディスク装置に書き戻す。また、リモートノード
に接続された物理ディスク装置に書き戻す場合、ローカ
ルノードのファイルサーバは、物理ディスク装置が接続
されたノードにローカルノードのファイル管理テーブル
の内容を一旦転送する。その後、物理ディスク装置が接
続されたノードのファイルサーバが物理ディスク装置に
その内容を書き戻す。例えば、ノード１００のファイル
サーバ１４０がファイル管理テーブル１６０の内容を物
理ディスク装置１０に書き戻す場合、まず、ファイルサ
ーバ１４０は、物理ディスク装置への書き戻し処理を行
いたいファイル管理テーブル１６０のエントリ中の、論
理ディスクＩＤ１６２（“１２３”）を参照して、書き
戻す先の論理ディスクＩＤを求める。そして、論理ディ
スク管理テーブル１７０を検索して上記論理ディスクＩ
Ｄに対応する物理ディスク装置にアクセスするためのＩ
Ｏパス（“２００，２９０，１１”）を求め、そのＩＯ
パス名に含まれるノード番号（“２００”）に対応する
ノード（ノード２００）のファイルサーバ２４０に書き
戻しを行いたいファイル管理テーブルのエントリを送信
する。ファイルサーバ２４０は、受信したデータを一旦
ファイル管理テーブル２６０に書き込む。その後、ファ
イルサーバ２４０は、ファイル管理テーブルに保存され
ている他のデータと纏めて、ファイル管理テーブル２６
０の更新内容を物理ディスク装置１０に書き込む。ファ
イルサーバ２４０が物理ディスク装置１０にアクセスす
るためのＩＯパスは、論理ディスク管理テーブル２７０
を検索し、論理ディスクＩＤ２６２をＩＯパス名に変換
することによって求められる。
【００５７】前述したように、最終的な物理ディスク装
置へのデータの書き戻しは、物理ディスク装置が接続さ
れたノードに存在するファイル管理テーブル及びバッフ
ァキャッシュから行っており、物理ディスク装置が接続
されたノードのファイル管理テーブル及びバッファキャ
ッシュには、ローカルノードのユーザアプリケーション
に関係するもの以外にリモートノードのユーザアプリケ
ーションに関係するものが存在する。
【００５８】図７はＩＯパスの切り替えの処理動作を説
明するフローチャート、図８〜図１０はＩＯパスに障害
が発生しＩＯパスの切り替えを行う処理について説明す
る図である。図８〜図１０において、１３はディスクキ
ャッシュ、３４０はファイルサーバ、３５０はディスク
ドライバ、３６０はバッファキャッシュであり、他の符
号は図１の場合と同一である。以下、これらの図を参照
して、ディスクコントローラ１１で障害が発生し、通常
使用しているＩＯパス“（２００，２９０，１１）”が
使用不可能になったとき、物理ディスク装置１０にアク
セスするためのＩＯパスを“（２００，２９０，１
１）”から“（３００，３９０，１２）”に切り替える
処理について説明する。
【００５９】図９において、ディスクキャッシュ１３
は、ディスク装置１０が備えるディスクコントローラ１
１の内部に設けられたディスクキャッシュであり、ディ
スクコントローラ１１に対してリード・ライト処理要求
が発行されたときに使用される。そして、実際のリード
・ライト処理は、このディスクキャッシュ１３を経由し
て行われる。また、ディスクコントローラ１２は、ディ
スクコントローラ１１に障害が発生したときに、ディス
クキャッシュ１３がディスク媒体に書き戻す必要のある
データを保持している場合、そのデータをディスク媒体
に書き戻し、ディスクコントローラ１１をディスク装置
から切り放す機能を持つ。
【００６０】図８は図７により説明するステップ１００
３でのリクエストの保留の処理を行うときの各ノードの
動作を示し、図９は図７により説明するステップ１００
４でのディスクキャッシュの書き戻しの処理と、ステッ
プ１００５でのバッファキャッシュの転送の処理を行う
ときの各ノードの動作を示し、図１０は図７により説明
するステップ１００６でのリクエストの保留解除及び転
送の処理を行うときの各ノードの動作を示している。
【００６１】以下、ディスクコントローラ１１で障害が
発生した時、物理ディスク装置１０にアクセスするため
のＩＯパスを“（２００，２９０，１１）”から“（３
００，３９０，１２）”に切り替える処理を図８〜図１
０を併用しながら図７に示すフローを参照して説明す
る。なお、論理ディスク管理テーブル２７０の設定は図
２に示すようになっているものとする。
【００６２】障害検出の処理（ステップ１００１） ディスクコントローラ１１に障害が発生すると、ディス
クドライバ２５０は、ＩＯパス（２００，２９０，１
１）を使って物理ディスク装置１０にアクセスを行うこ
とができなくなる。これをもって障害検出とし、ディス
クドライバ２５０は、ＩＯパス（２００，２９０，１
１）の障害発生をファイルサーバ２４０に通知する。ま
た、ディスクドライバ２５０がローカルノードとしての
ノード２００のノード番号を含むＩＯパスのうち、論理
ディスク管理テーブル２７０の状態フラグが、「使用
中」状態及び「待機中」状態のＩＯパスを定期的に監視
することによって障害を検出してもよい。これによっ
て、「待機中」状態のＩＯパスの障害検出が可能とな
る。
【００６３】切り替え対象ＩＯパスの検索の処理（ステ
ップ１００２） 障害発生通知を受けたファイルサーバ２４０は、図２に
示した論理ディスク管理テーブル２７０を参照し、障害
発生ＩＯパス“（２００，２９０，１１）”を含むエン
トリを検索する。そして、障害発生ＩＯパスの状態フラ
グが「待機中」状態であるか否かをチェックし（ステッ
プ１０１０）、もし、障害発生ＩＯパスの状態フラグが
「待機中」状態であれば、ＩＯパスの切り替え処理は必
要なく、ステップ１０１１の処理に進む。そうでない場
合、ＩＯパスの切り替えが必要になりステップ１１０３
の処理に進む。前述の検索によって見つかったエントリ
には、障害発生ＩＯパス以外に、状態フラグ２７９（２
７５）が「待機中」状態のＩＯパス“（３００，３９
０，１２）”と論理ディスクＩＤ“１２３”が登録され
ている。この「待機中」状態のＩＯパス“（３００，３
９０，１２）”が切り替え先のＩＯパスとなる。ファイ
ルサーバ２４０は、障害発生ＩＯパス名と切り替え先の
ＩＯパス名とそれらに対応する論理ディスクＩＤ（以
後、ＩＯパス切り替え処理を行う論理ディスクＩＤと呼
ぶ）を、ファイルサーバ２４０が管理するメモリ内に保
存し、ファイルサーバ２４０が論理ディスク管理テーブ
ル２７０を検索することなくいつでも得られるようにし
ておく。
【００６４】リクエストの保留の処理（ステップ１００
３） この処理について、図８を参照して説明する。ファイル
サーバ２４０は、現在処理中あるいは今後受理するＩＯ
アクセス要求の中で、ＩＯパスの切り替え処理を行う論
理ディスクＩＤ“１２３”あるいは障害発生ＩＯパス
“（２００，２９０，１１）”を指定したＩＯアクセス
要求を保留し、その内容を後で取り出すことができるよ
うにファイルサーバ２４０が管理するメモリ上に記録す
る。図８に示す例では、ファイルサーバ１４０は、ディ
スクコントローラ１１で障害が発生したことを知らず
に、論理ディスク“１２３”を指定したライト要求をフ
ァイルサーバ２４０に送信している。ファイルサーバ２
４０は、このライト要求と、現在処理中のＩＯパス名
“（２００，２９０，１１）”を指定したリード要求を
保留している。
【００６５】次に、ファイルサーバ２４０は、切り替え
先のＩＯパス“（３００，３９０，１２）”に含まれる
ノード番号“３００”に対応するノード（以後、切り替
え先のノードと呼ぶ）のファイルサーバ３４０に、障害
発生ＩＯパス名“（２００，２９０，１１）”と切り替
え先のＩＯパス名“（３００，３９０，１２）”と対応
する論理ディスクＩＤ“１２３”とを送信し、論理ディ
スクＩＤを指定したＩＯアクセス要求を保留するように
要求する。この要求を受信したファイルサーバ３４０
は、前述の２つのＩＯパス名と論理ディスクＩＤとをフ
ァイルサーバ３４０が管理するメモリ上に保存し、これ
らの情報をいつでも得られるようにした後、論理ディス
クＩＤ“１２３”を指定したＩＯアクセス要求を保留
し、その内容を後で取り出せるようにファイルサーバ３
４０が管理するメモリ上に保存する。図８に示す例で
は、ファイルサーバ３４０は、論理ディスクＩＤ“１２
３”を指定したリード要求を保留している。
【００６６】ディスクキャッシュの書き戻しの処理（ス
テップ１００４） この処理について、図９を参照して説明する。ファイル
サーバ３４０は、リクエストの保留の設定を行った後、
障害発生ＩＯパスが含むディスクコントローラ番号“１
１”に対応するディスクコントローラ１１が備えるディ
スクキャッシュ１３を、切り替え先のＩＯパスが含むデ
ィスクコントローラ番号“１２”に対応するディスクコ
ントローラ１２を使ってディスク装置に書き戻すように
ディスクドライバ３５０に要求する。この要求を受けた
ディスクドライバ３５０は、ＩＯインターフェイス３９
０を介してディスクコントローラ１２に制御信号を送り
ディスクキャッシュ１３に保存されているｄｉｒｔｙな
データをディスク領域に書き戻し、ディスクコントロー
ラ１１をディスク装置１０から切り放す。これらの処理
の終了後、ディスクドライバ３５０は、ファイルサーバ
３４０に終了通知を送る。
【００６７】バッファキャッシュの転送の処理（ステッ
プ１００５） この処理について、図９を用いて説明する。ファイルサ
ーバ３４０は、ディスクドライバ３５０からの終了通知
を受けると、障害発生ＩＯパス“（２００，２９０，１
１）”に含まれるノード番号“２００”に対応するノー
ド（以後、障害発生ノードと呼ぶ）のファイルサーバ２
４０にファイル管理テーブル２６０及びバッファキャッ
シュ２８０の転送を要求する。ファイルサーバ３４０か
らの要求を受信したファイルサーバ２４０は、ｄｉｒｔ
ｙな（物理ディスク装置に書き戻す必要のある）ファイ
ル管理テーブル２６０とｄｉｒｔｙなバッファキャッシ
ュ２８０の中で、論理ディスクＩＤ２６２や論理ディス
クＩＤ２８１が、ＩＯパス切り替え処理を行う論理ディ
スクＩＤ“１２３”であるデータを、ファイルサーバ３
４０に送信する。この送信が成功したら、ファイルサー
バ２４０は、ノード２００内に存在する前述のデータを
消去可能とし、バッファキャッシュ２８０をしばらくの
間、読み出し用のキャッシュとして使用するが、バッフ
ァキャッシュ２８０やファイル管理テーブル２６０のた
めのメモリ領域が不足してきたらこれらを消去する。フ
ァイルサーバ３４０は、受け取ったデータを、ノード３
００上のファイル管理テーブル３６０及びバッファキャ
ッシュ３８０にマージする。ノード３００上のこれらの
データはｄｉｒｔｙであるので、ＩＯパスの切り替え処
理が終了し通常運用状態となったら、ファイルサーバ３
４０が切り替え先のＩＯパス“（３００，３９０，１
２）”を使用して物理ディスク装置１０に書き込む。ま
た、前述の上記データは、読み出し用のキャッシュとし
て使用される可能性もある。
【００６８】論理ディスク管理テーブルの更新の処理
（ステップ１００６） この処理は、図５により説明したフローの手順で実行さ
れる。図５に示したローカルノードは、ここでは障害発
生ノード２００である。ファイル管理テーブル２６０及
びバッファキャッシュ２８０の転送が終了すると、ファ
イルサーバ２４０は、論理ディスク管理テーブル２７０
に登録されている障害発生ＩＯパス“（２００，２９
０，１１）”の状態フラグ２７５を「使用中」状態から
「使用不可」状態に、切り替え先のＩＯパス“（３０
０，３９０，１２）”の状態フラグ２７９を「待機中」
状態から「使用中」状態に更新する。ファイルサーバ２
４０は、論理ディスク管理テーブル２７０の更新の終了
後（図５のステップ９０１）、全リモートノードのファ
イルサーバに論理ディスク管理テーブル２７０の更新情
報を送り、論理ディスク管理テーブルの更新を要求し
（図５のステップ９０２）、リプライを待つ。例えば、
ファイルサーバ２４０からの要求を受信したノード１０
０のファイルサーバ１４０は、受信した論理ディスク管
理テーブル２７０の更新情報に基づいて、ノード１００
の論理ディスク管理テーブル１７０のＩＯパス“（２０
０，２９０，１１）”に対応する状態フラグ１７５を
「使用不可」状態に、ＩＯパス“（３００，３９０，１
２）”に対応する状態フラグ１７９を「使用中」状態に
更新する（図５のステップ９０６）。この更新の後、フ
ァイルサーバ１４０は、ファイルサーバ２４０に論理デ
ィスク管理テーブル３７０の更新終了の通知を送る（図
５のステップ９０７）。ファイルサーバ２４０が、全リ
モートノードのファイルサーバから論理ディスク管理テ
ーブルの更新終了の通知を受信すれば（図５のステップ
９０３）、システムを構成するすべてのノードの論理デ
ィスク管理テーブルの更新が完了したことになる。
【００６９】リクエストの保留解除及び転送の処理（ス
テップ１００７） この処理について、図１０を参照して説明する。ファイ
ルサーバ２４０は、切り替え先のノードのファイルサー
バ３４０にリクエストの保留を解除する要求を送る。こ
の要求を受けたファイルサーバ３４０は、ステップ１０
０３で行ったＩＯアクセス要求の保留を解除し、保留し
ていたＩＯアクセス要求の処理を行い、通常運用時の処
理を開始する。また、ファイルサーバ２４０は、ステッ
プ１００３で行ったＩＯアクセス要求の保留を解除し、
保留していたＩＯアクセス要求のうち、障害発生ＩＯパ
スを指定したＩＯアクセス要求を、切り替え先のＩＯパ
スを指定したＩＯアクセス要求に変換した後、保留中の
すべてのＩＯアクセス要求を、切り替え先のノードのフ
ァイルサーバ３４０に転送する。図１０に示す例では、
ファイルサーバ２４０は、ＩＯパス“（２００，２９
０，１１）”を指定したリード要求を、ＩＯパス“（３
００，３９０，１２）”を指定したリード要求に変換
し、前述の要求と論理ディスクＩＤ“１２３”を指定し
たライト要求とをノード３００のファイルサーバ３４０
に転送している。転送されたＩＯアクセス要求は、ファ
イルサーバ３４０によって処理される。
【００７０】マウント構成ファイルの更新の処理（ステ
ップ１００８） 最後に、ファイルサーバ２４０は、高信頼ディスク装置
３０が接続されているノード１００のファイルサーバ１
４０に障害発生ＩＯパス“（２００，２９０，１１）”
が「使用不可」状態になったことをマウント構成ファイ
ル２４に記載するように要求し、通常運用時の処理を開
始する。この要求を受けたファイルサーバ１４０は、高
信頼ディスク装置３０上のマウント構成ファイル２４を
参照し、障害発生ＩＯパス“（２００，２９０，１
１）”の使用可否情報５２を“unavailable”（使用不
可）に書き換える。以上により、ＩＯパスの切り替え処
理が終了する。
【００７１】論理ディスク管理テーブルの更新の処理
（ステップ１０１１） ステップ１０１０のチェックで、ＩＯパスの切り替え処
理を行う必要がなかった場合、障害発生ノードのファイ
ルサーバ２４０は、ステップ１００６の処理と同様の手
順でシステム全体の論理ディスク管理テーブルを更新す
る。但し、障害発生ＩＯパス“（２００，２９０，１
１）”の状態フラグを「待機中」から「使用不可」に書
き換える処理だけを行う。システム全体の論理ディスク
管理テーブルの更新が終了した後前述したステップ１０
０８の処理に進む。
【００７２】図１１はＩＯパスが障害から復旧したと
き、ＩＯパスをシステムに復旧させる処理手順を説明す
るフローチャートであり、これについて説明する。ここ
では、物理ディスク装置１０のディスクコントローラ１
１の障害などの原因により「使用不可」状態になってい
たＩＯパス“（２００，２９０，１１）”がディスクコ
ントローラ１１の交換などによって再び使用可能になっ
たとき、システムに上記のＩＯパスを復旧させる方法を
例に説明する。また、ここでは、ＩＯパスの復旧処理中
に使用中のＩＯパスに障害が発生することはないと仮定
する。
【００７３】（１）障害が発生したディスクコントロー
ラの交換等により、今まで使用不可能となっていたＩＯ
パス“（２００，２９０，１１）”が使用可能な状態に
なると、システム管理者は、管理用のプログラムを使っ
て、このＩＯパスをシステムに復旧させる要求を、高信
頼ディスク装置が接続されているノード１００のファイ
ルサーバ１４０に送信する。ファイルサーバ１４０は、
この要求を受信する（ステップ６０１）。
【００７４】（２）復旧要求を自したファイルサーバ１
４０は、論理ディスク管理テーブル１７０を参照して、
前述のＩＯパス“（２００，２９０，１１）”の状態フ
ラグ１７５を「使用不可」状態から「待機中」状態に更
新する。また、ファイルサーバ１４０は、論理ディスク
管理テーブル１７０の更新が終了したら、全ての稼働中
のノードのファイルサーバと通信を行い、全ノードの論
理ディスク管理テーブルを論理ディスク管理テーブル１
７０と同じ内容にする。この処理は、図７によるＩＯパ
スの切り替えのフローにより説明したステップ１００６
での処理と同様な処理により行われる（ステップ６０
２）。
【００７５】（３）そして、ファイルサーバ１４０は、
高信頼ディスク装置３０上のマウント構成ファイル２４
を参照し、前述のＩＯパス“（２００，２９０，１
１）”の使用可否情報５２を“unavailable”（使用不
可）から“available”（使用可）に変更する。前述の
処理により、ＩＯパス“（２００，２９０，１１）”を
「待機中」状態としてシステムに復旧させることができ
る（ステップ６０３）。
【００７６】前述した本発明の実施形態は、ファイル管
理テーブル２６０及びバッファキャッシュ２７０をノー
ド２００からノード３００に転送するとして説明した
（図７のステップ１００５）が、これは次のような理由
による。すなわち、物理ディスク装置へのアクセスは、
ローカルノードからのアクセスでもリモートノードから
のアクセスでも、最終的に、その物理ディスク装置が接
続されたノードのファイル管理テーブル及びバッファキ
ャッシュを経由して行われる。従って、物理ディスク装
置が接続されたノードは、そのノード（ローカルノー
ド）で動作するプログラムに関係するファイル管理テー
ブル及びバッファキャッシュの他に、リモートノードで
動作するプログラムに関係するファイル管理テーブル及
びバッファキャッシュを持つ。前述した本発明の実施形
態に示したようなＩＯパス切り替え処理は、物理ディス
ク装置が接続されているノードがノード２００からノー
ド３００に切り替わるので、ノード３００がノード２０
０に代わって、ノード２００が保持していたファイル管
理テーブル２６０及びバッファキャッシュ２８０を持つ
必要がある。そこで、ＩＯパス切り替え処理時にファイ
ル管理テーブルやバッファキャッシュをノード３００に
転送するようにしている。このとき、ｄｉｒｔｙなデー
タのみを転送するようにして、データの転送量をなるべ
く少なく済むようにしている。
【００７７】また、前述した本発明の実施形態は、物理
ディスク装置１０、２０を共にノード２００から使用し
ているときに、ＩＯインターフェイス２９０に障害が発
生した場合、ＩＯパス（２００，２９０，１１）及び
（２００，２９０，２１）の両方が使用できなくなる
が、この場合、ディスクドライバ２５０が、各々のＩＯ
パスに対して障害検出を行い、各々のＩＯパスに対して
前述の各ステップで示されるＩＯパスの切り替え処理を
行うようにすればよい。また、ディスクドライバ２５０
がＩＯインターフェイス２９０で障害が起こったことを
検出する機能を持つ場合、ステップ１００１で、ディス
クドライバ２５０がファイルサーバ２４０にＩＯインタ
ーフェイス２９０の障害を通知し、ステップ１００２
で、ファイルサーバ２４０が論理ディスク管理テーブル
２７０を検索し、障害発生ＩＯインターフェイス番号
“２９０”から、障害発生ＩＯパス（２００，２９０，
１１）、（２００，２９０，２１）と対応する切り替え
先のＩＯパスと論理ディスクＩＤを探し出し、これら２
組のＩＯパスについて、前述の各ステップで示される切
り替え処理を同時に行うようにしてもよい。
【００７８】前述した本発明の実施形態において、ノー
ド２００が２つのＩＯインターフェイスを有し、物理デ
ィスク装置１０がこれら２つのＩＯインターフェイスに
よってノード２００と接続されており、物理ディスク装
置１０とノード２００との間のＩＯパスが２つ存在し、
通常運用時これらのＩＯパスのうち１つを利用している
ような場合、ディスクコントローラやＩＯインターフェ
イスの障害発生により、今まで使用していたＩＯパスが
使用できなくなったとき、物理ディスク装置１０にアク
セスするためのＩＯパスをもう片方のＩＯパスに前述し
たの方法で切り替えることができる。この場合、ステッ
プ１００３でノード３００のファイルサーバ３４０がＩ
Ｏアクセス要求を保留する処理と、ステップ１００５で
ノード２００が持つバッファキャッシュ２８０及びファ
イル管理テーブル２６０をＩＯパス切り替え先のノード
３００に転送する処理が不要となる。
【００７９】また、本発明は、物理ディスク装置にアク
セスするためのＩＯパスが３つ以上存在する場合にも適
用することができる。この場合、論理ディスク管理テー
ブル及びマウント構成ファイル２４の各エントリに３つ
以上のＩＯパスの組を登録できるようにし、システムの
起動時にファイルサーバ１４０がマウント構成ファイル
２４に記載されたＩＯパスの組に対して、１つの論理デ
ィスクＩＤを設定し、ＩＯパスと論理ディスクＩＤとの
対応関係を論理ディスク管理テーブルに登録するように
すればよい。そして、この場合、通常運用時、複数のＩ
Ｏパスが「待機中」状態としてスタンバイするため、障
害発生時のＩＯパスの切り替え処理を行う際に、複数の
「待機中」状態のＩＯパスの中から切り替え先のＩＯパ
スを選択する必要がある。この切り替え先のＩＯパスの
決定は、前述した実施形態におけるステップ１００２で
障害を検出したノードのファイルサーバがそのノードの
論理ディスク管理テーブルを検索し、障害発生ＩＯパス
名を含むエントリを見つけたときに、そのエントリのな
るべく最初の方のフィールドに登録されている「待機
中」状態のＩＯパスを切り替え先のＩＯパスとして選び
出すことによって行うようにすればよい。また、論理デ
ィスク管理テーブルに登録されている各ＩＯパス毎に使
用時間（状態フラグが「使用中」状態となっていた時
間）を上記論理ディスク管理テーブルに登録できるよう
にし、ＩＯパスの切り替え処理時、使用時間の短いＩＯ
パスに切り替えるようにしてもよい。これによって、複
数のＩＯパスをまんべんなく使用することができる。
【００８０】さらに、本発明は、ＬＡＮ等のネットワー
クにより接続された疎結合計算機システムによるファイ
ルシステムに対しても適用することができる。この場
合、前述のノード番号の代わりにネットワークアドレス
を使用すればよい。
【００８１】また、前述した本発明の実施形態におい
て、ディスクキャッシュ１３をディスクコントローラ１
２から制御し、ディスク装置１０に書き戻す機能を物理
ディスク装置１０が持たない場合、ノード２００のディ
スクドライバ２５０が、ディスクキャッシュ１３に保存
されたｄｉｒｔｙなキャッシュを少なくとも含むデータ
を予め保持しておいて、障害発生時、前述のステップ１
００４でディスクドライバ２５０がディスクドライバ３
５０と通信を行い、ｄｉｒｔｙなディスクキャッシュを
少なくとも含むようなデータをノード２００からノード
３００に転送し、ディスクコントローラ１２を通してデ
ィスク装置１０に書き戻すようにしてもよい。
【００８２】前述した本発明の実施形態は、ＩＯパス切
り替え処理中、障害発生ノード及び切り替え先のノード
に送信されてきたＩＯアクセス要求は、保留するように
していたが、ＩＯアクセス要求を保留しないようにする
こともできる。以下、この場合のファイルサーバの動作
について図面により説明する。
【００８３】図１２はＩＯパス切り替え時の障害発生ノ
ードの処理動作の他の例について説明するフローチャー
ト、図１３は障害発生ノード以外のノードの処理動作の
他の例を説明するフローチャートである。以下、障害発
生ノードがノード２００、切り替え先のノードがノード
３００の場合を例として、図１２、図１３に示すフロー
を参照して、ＩＯパス切り替え処理中に各ノードに送信
されてきたＩＯアクセス要求の処理の方法を説明する。
まず、障害発生ノードのファイルサーバの動作を図１２
のフローにより説明する。
【００８４】（１）障害発生ノードのファイルサーバ２
４０は、ＩＯパス切り替え処理中に、ＩＯアクセス要求
を受信すると、その要求が他のノードであるリモートノ
ードからの要求が否かを判定する（ステップ７０１、７
０２）。
【００８５】（２）ステップ７０２の判定で、受信した
ＩＯアクセス要求がローカルノード（自ノード）のユー
ザアプリケーション２３０からのものであると判定する
と、ファイルサーバ２４０は、前述した実施形態で説明
したと同様に、ＩＯパス切り替え処理の間、その要求を
保留する。この要求は、ＩＯパスの切り替え処理終了時
に、切り替え先のノードに送信される（ステップ７０
３）。
【００８６】（３）ステップ７０２の判定で、受信した
ＩＯアクセス要求がリモートノードからのものであると
判定すると、ファイルサーバ２４０は、その要求に対し
てリプライを返さずに無視する（ステップ７０４）。
【００８７】次に、障害発生ノード以外のノードのファ
イルサーバの動作を図１３に示すフローを参照して説明
する。障害発生ノード以外のファイルサーバは、基本的
に図４により説明した通常運用時と同様の動作をするの
で、ここでは図４の処理と重なる部分については説明を
省略する。
【００８８】（１）障害発生ノード以外のファイルサー
バがＩＯパス切り替え中に障害発生ノード（ノード２０
０）に送信したＩＯアクセス要求はタイムアウトとなる
（ステップ８０８）。
【００８９】（２）ＩＯアクセス要求がタイムアウトに
なったら、ＩＯアクセス要求を送信したファイルサーバ
は、一定時間（例えば１秒）待った後、論理ディスク管
理テーブルを参照して、論理ディスクＩＤからＩＯパス
名を求める処理から処理をやり直す。このとき、ＩＯパ
スの切り替え処理が終了していれば、全ノードの論理デ
ィスク管理テーブルが更新されているので、ステップ８
０４の処理によって切り替え先のＩＯパスが求まる（ス
テップ８０４）。
【００９０】（３）ＩＯアクセス要求を送信しようとし
ているファイルサーバは、求められたＩＯパス名が含む
ノードがローカルノードであるか否かを判定し、切り替
え先のＩＯパス名が含むノードがローカルノードでなか
った場合、ＩＯアクセス要求を切り替え先のノード（ノ
ード３００）に送信する（ステップ８０５、８０６）。
【００９１】（４）ステップ８０５の判定で、切り替え
先のＩＯパスがローカルノードであれば、ＩＯアクセス
要求を送信しようとしているファイルサーバは、ＩＯア
クセス要求をローカルノードのディスクドライバに送信
する（ステップ８０７）。
【００９２】前述したステップ８０４の処理において、
もし、論理ディスクＩＤからＩＯパス名を求めなおした
ときに、ＩＯパスの切り替え処理が終了していない場
合、ＩＯアクセス要求は、障害発生ノード（ノード２０
０）に送信され、上記ＩＯアクセス要求は再びタイムア
ウトとなり、ＩＯアクセス要求が成功するまで前述した
処理が繰り返される。
【００９３】この方法を使用することにより、図７によ
り説明したステップ１００３のリクエストの保留処理で
リモートノードからのアクセス要求を保留する必要がな
くなるので、ＩＯアクセス要求を保留するためのメモリ
を節約することができる。また、ＩＯアクセス要求の再
送回数に制限（例えば５回）を設け、もし制限回数だけ
再送を行ってもタイムアウトになり続ければ、そのＩＯ
アクセス要求をエラーとしてもよい。また、ＩＯパス切
り替え処理中、障害発生ノードのファイルサーバ２４０
は、リモートノードからのＩＯアクセス要求を無視する
かわりに、「ＩＯパス切り替え処理中なので、ＩＯアク
セス要求を処理できない」という意味の通知をアクセス
要求を送信したリモートノードのファイルサーバに送信
するようにしてもよい。これにより、リモートノードの
ファイルサーバは、ＩＯパスで障害が発生した場合とノ
ード２００で障害が発生した場合とを区別することがで
きるようになる。
【００９４】前述までに説明した本発明の第１の実施形
態によるＩＯパス切り替え方法は、ノード２００でＯＳ
の障害が発生したとき、ネットワーク１を通じてバッフ
ァキャッシュ２８０やファイル管理テーブル２６０をノ
ード３００に転送することができなくなるため、同じ方
法でＩＯパスの切り替えを行うことは不可能である。
【００９５】これを解決するため、本発明は、バッファ
キャッシュ２８０やファイル管理テーブル２６０をノー
ド３００に転送するための専用のハードウェアを使う方
法を取ることができる。以下、これを第２の実施形態と
して説明する。
【００９６】図１４は本発明の第２の実施形態によるデ
ィスクキャッシュの書き戻しの処理とバッファキャッシ
ュの転送の処理とを説明する図である。
【００９７】本発明の実施形態におけるＩＯパス切り替
え処理の手順は、前述までに説明した第１の実施形態の
場合の図７に示すフローと同様に行われる。但し、第２
の実施形態では、ステップ１００３及びステップ１００
７の処理は行わない。そして、図１４には、ステップ１
００４でのディスクキャッシュの書き戻しの処理とステ
ップ１００５でのバッファキャッシュの転送の処理につ
いてしめしている。
【００９８】図１４において、メモリアクセス手段２９
９（３９９）は、ノード２００（３００）に付属してお
り、メモリアクセス手段２９９とメモリアクセス手段３
９９とは専用通信線２によって互いに接続されている。
メモリアクセス手段２９９は、ノード２００でＯＳの障
害が発生しノード２００上で動作するプログラムの全て
が停止した場合にも、メモリ２２０にアクセスし、その
内容を専用通信線２を使用してメモリアクセス手段３９
９との通信によりノード３００に送信することが可能な
ハードウェアである。
【００９９】通常運用時、図１４に示す各ノードのファ
イルサーバは、図１３により説明した動作を行う。ここ
で例えば、ノード２００でＯＳの障害が発生したとする
と、あるファイルサーバがノード２００に送信したＩＯ
アクセス要求のリプライが戻ってこないので、ＩＯアク
セスを送信したファイルサーバは、上記ＩＯアクセス要
求をタイムアウトにする（ステップ８０８）。ファイル
サーバは、一定時間待った後、ローカルノードの論理デ
ィスク管理テーブルを参照し、論理ディスクＩＤからＩ
Ｏパスを求める処理から処理の再実行を行うことになる
（ステップ８０４）。ＩＯパス切り替え処理中、前述の
要求は、障害発生ノード（ノード２００）に送信されタ
イムアウトとなるが、ＩＯパス切り替え終了後、要求は
切り替え先のノードに送信される。
【０１００】以下、ノード２００で障害が発生しノード
２００で動作する全てのプログラムが停止した場合に、
物理ディスク装置１０にアクセスするためのＩＯパスを
（２００，２９０，１１）から（３００，３９０，１
２）に切り替えるものとして、その処理を図１、図２、
図１４を併用しながら図７に示すフローを参照して説明
する。
【０１０１】障害検出の処理（ステップ１００１） ノード２００で障害が発生すると、ノード２００は、リ
クエストを一切受け付けなくなる。従って、ノード２０
０にＩＯアクセス要求を送信したリモートノードのファ
イルサーバは、ＩＯアクセス要求をタイムアウトとす
る。ＩＯアクセス要求を送信したファイルサーバは、こ
のタイムアウトによってノード２００で障害が発生した
ことを検出する。前述したように、ＩＯアクセス要求を
送信したファイルサーバは、ＩＯ処理要求がタイムアウ
トになったらその要求を再送するので、何度も障害発生
ノード（ノード２００）に上記要求を再送し、そのたび
に要求をタイムアウトにする可能性がある。上記ファイ
ルサーバは、あるノードへの要求が最初にタイムアウト
になったとき、次のステップ１００２の処理に進み、２
回目以降、ステップ１００２以降の処理は行わない。
【０１０２】切り替え対象ＩＯパスの検索の処理（ステ
ップ１００２） ＩＯアクセス要求を送信したファイルサーバは、ローカ
ルノードの論理ディスク管理テーブルを参照し、障害が
発生したノードのノード番号“２００”から障害発生Ｉ
Ｏパス名と切り替え先のＩＯパス名とを探し出し、切り
替え先のＩＯパスが含むノード番号に対応するノード
（切り替え先のノード）のファイルサーバに、障害発生
ＩＯパスから切り替え先のＩＯパスにＩＯパスを切り替
えるように要求する。切り替え先のノードがローカルノ
ード（自ノード）であれば、ＩＯアクセスを送信したフ
ァイルサーバは、直ちにＩＯパスの切り替えの処理を開
始する。但し、障害発生ＩＯパスの状態フラグが「待機
中」状態の場合（ステップ１０１０）、ＩＯパスの切り
替え処理は必要なくステップ１０１１の処理に進む。例
えば、ノード１００のファイルサーバ１４０がノード２
００のファイルサーバ２４０に送信したＩＯ処理要求が
タイムアウトとなった場合、ファイルサーバ１４０は、
図２に示した論理ディスク管理テーブル１７０を検索
し、ノード番号“２００”を含むエントリを探す。見つ
かったエントリには複数のＩＯパスが記載されている
が、ノード番号“２００”を含むＩＯパス“（２００，
２９０，１１）”が障害発生ＩＯパスであり、状態フラ
グが「待機中」状態でノード番号“２００”を含まない
ＩＯパス“（３００，３９０，１２）”が切り替え先の
ＩＯパスである。障害発生ＩＯパスの状態フラグ２７５
が「使用中」状態であるので、ファイルサーバ１４０
は、切り替え先のノード３００のファイルサーバ３４０
に“（２００，２９０，１１）”から“（３００，３９
０，１２）”にＩＯパスを切り替えるように要求する。
もし、上記障害発生ＩＯパスの状態フラグが「待機中」
状態であれば、ＩＯパスの切り替え処理は必要なく、ス
テップ１０１１の処理に進む。
【０１０３】前述した検索処理で、切り替え処理を行う
ＩＯパスの組が複数個見つかった場合、障害を検出した
ファイルサーバは、ＩＯパス毎に対応する切り替え先の
ノードのファイルサーバにＩＯパスの切り替え要求を送
信する。但し、複数のＩＯパスの切り替え要求を１つの
ノードに送る必要がある場合、それらのＩＯパスの切り
替え要求を一括して送り、切り替え先のノードのファイ
ルサーバが、それらのＩＯパスの切り替え処理を同時に
行う。例えば、物理ディスク装置１０と物理ディスク装
置２０とをノード２００から使用していた場合、ノード
２００の障害を検出したファイルサーバは、ノード３０
０のファイルサーバ３４０に上記２つの物理ディスク装
置にアクセスするための２組のＩＯパスを切り替える要
求を発行し、ファイルサーバ３４０は、前述した２組の
ＩＯパスの切り替え処理を同時に行う（ステップ１００
４〜１００８）。
【０１０４】ディスクキャッシュの書き戻しの処理（ス
テップ１００４） 障害発生ＩＯパス“（２００，２９０，１１）”から切
り替え先のＩＯパス“（３００，３９０，１２）”にＩ
Ｏパスを切り替えるように要求されたファイルサーバ３
４０は、ＩＯパスの切り替えモードに入り、その後再び
同じＩＯパス切り替え要求が送られてきても受理しな
い。これによって、ＩＯパスの切り替え処理が二重に行
われることを防止する。このステップの処理の後の処理
内容は、第１の実施形態の場合と同様に行われる。ファ
イルサーバ３４０は、図１４に示すように、ディスクド
ライバ３５０にディスクキャッシュの書き戻し要求を送
信することにより、ディスクキャッシュ１３の内容をデ
ィスク領域に書き戻して、ディスクコントローラ１１を
物理ディスク装置から切り放す。
【０１０５】バッファキャッシュの移動の処理（ステッ
プ１００５） ファイルサーバ３４０は、次に、図１４に示すように、
メモリアクセス手段３９９に、障害が発生したノード２
００のファイル管理テーブル２６０とバッファキャッシ
ュ２８０との内容をローカルノード（ノード３００）に
転送するように要求する。メモリアクセス手段３９９
は、メモリアクセス手段２９９と通信を行い、専用通信
線２を介して、ｄｉｒｔｙなバッファキャッシュ２８０
及びｄｉｒｔｙなファイル管理テーブル２６０の内容を
ノード３００のファイルサーバ３４０に転送する。ファ
イルサーバ３４０は、ノード３００上のファイル管理テ
ーブル３６０及びバッファキャッシュ３８０にメモリア
クセス手段３９９から送られてきたデータをマージす
る。マージされたデータは、ＩＯパスの切り替え終了
後、ファイルサーバ３４０によって切り替え先のＩＯパ
スから物理ディスク装置１０に書き込まれる。また、こ
れらデータは、読み出し用のキャッシュとしても使われ
る可能性もある。
【０１０６】論理ディスク管理テーブルの更新の処理
（ステップ１００６） データの転送処理が終了した後、ファイルサーバ３４０
は、論理ディスク管理テーブル３７０に登録されている
ＩＯパスの状態フラグを、障害発生ＩＯパス“（２０
０，２９０，１１）”について、「使用不可」状態に、
切り替え先のＩＯパス“（３００，３９０，１２）”に
ついて、「使用中」状態に登録し直す。ファイルサーバ
３４０は、論理ディスク管理テーブル３７０の更新の終
了後、第１の実施形態の場合と同様な方法により、全て
の稼働中のノードのファイルサーバと通信を行うことに
より、全ての稼働中のノードの論理ディスク管理テーブ
ルに登録されている、障害発生ＩＯパスの状態フラグを
「使用不可」状態に、切り替え先のＩＯパスの状態フラ
グを「使用中」状態に更新する。
【０１０７】マウント構成ファイルの更新の処理（ステ
ップ１００８） ファイルサーバ３４０は、全ての稼働中のノードの論理
ディスク管理テーブルの更新が終了した後、高信頼ディ
スク装置３０が接続されているノード１００のファイル
サーバ１４０に、ＩＯパス“（２００，２９０，１
１）”が「使用不可」状態になったことをマウント構成
ファイル２４に記載するように要求し、ＩＯパスの切り
替えモードから抜け、通常運用時の処理を開始する。前
述の要求を受けたファイルサーバ１４０は、「使用不
可」状態となったＩＯパス“（２００，２９０，１
１）”の使用可否情報５２を“available”（使用可）
から“unavailable”（使用不可）に更新する。以上に
よりＩＯパスの切り替え処理が終了する。
【０１０８】論理ディスク管理テーブルの更新の処理
（ステップ１０１１） ステップ１０１０で、障害発生パスが「待機中」状態に
あると判定され、ＩＯパスの切り替え処理を行う必要が
ない場合、ステップ１００１の処理で障害を検出したフ
ァイルサーバは、ステップ１００６の処理と同様の手順
でシステム全体の論理ディスク管理テーブルを更新す
る。但し、障害発生ＩＯパスの状態フラグを「使用不
可」に書き換える処理だけを行う。システム全体の論理
ディスク管理テーブルの更新が終了した後、前述のファ
イルサーバがファイルサーバ１４０に対してマウント構
成ファイルの更新を要求し、この要求を受けたファイル
サーバ１４０は、ステップ１００８の処理を行う。
【０１０９】図１５は本発明の第３の実施形態によるフ
ァイルシステムの構成を示すブロック図、図１６は本発
明の第３の実施形態におけるマウント構成ファイルの具
体的な構成例を説明する図であり、図１５における符号
は図１の場合と同一である。図１５に示す本発明の第３
の実施形態は、同一のファイルを物理ディスク装置１０
と物理ディスク装置２０とに二重化（ミラーリング）し
て記録する例である。
【０１１０】図示本発明第３の実施形態において、マウ
ント構成ファイルの１つのエントリには、図１６に示す
ように、物理ディスクにアクセスするためのＩＯパス名
５１、５３、各ＩＯパスの使用可否情報５２、５４、マ
ウントポイント５５が記載されている。この第３の実施
形態は、マウントポイントの１つのエントリに記載され
たＩＯパスからアクセスされる物理ディスク装置にファ
イルが多重化して記録される。従って、前述のＩＯパス
からアクセスされる物理ディスク装置は異なるものであ
る必要がある。図１６に示す例では、／mnt ディレクト
リ以下のディレクトリに格納されたファイルは、ＩＯパ
ス“（２００，２９０，１１）”、“（３００，３９
０，２２）”からアクセスされる物理ディスク装置（物
理ディスク装置１０、２０）にミラーリングされる。こ
のような指定方法を採用することにより、システム管理
者が論理ボリュームの設定を行う必要がなくなる。
【０１１１】システム立ち上げ時、ファイルサーバ１４
０は、マウント構成ファイル２４を読み込んで、第１の
実施形態の場合と同様の手順で、全てのノードの論理デ
ィスク管理テーブルを設定する。但し、第３の実施形態
では、ファイルサーバ１４０は、マウント構成ファイル
２４の使用可否情報に“available”（使用可）と記載
されているすべてのＩＯパスについて、論理ディスク管
理テーブルの対応する状態フラグに「使用中」と登録す
る。
【０１１２】次に、通常運用時のファイルサーバの動作
を、ノード１００のユーザアプリケーション１３０がフ
ァイルＩＤ“１００”を指定したファイルアクセス要求
をファイルサーバ１４０に発行した場合を例に、図１
５、図１６を参照し、図６に示すフローに基づいて説明
する。なお、ファイル管理テーブルの設定は図２、論理
ディスク管理テーブルの設定は図１６に示すようになっ
ているものとする。
【０１１３】（１）ファイルサーバ１４０は、ユーザア
プリケーション１３０からファイルＩＤを指定したアク
セス要求を受けると、その要求がリモートノードからの
要求であるか否かを判定し、自ノードからの要求である
場合、ファイル管理テーブル１６０を検索し、ファイル
ＩＤ“１００”から論理ディスクＩＤ“１２３”を求め
る（ステップ５０１〜５０３）。
【０１１４】（２）そして、ファイルサーバ１４０は、
論理ディスク管理テーブル１７０を検索し、論理ディス
クＩＤ“１２３”から状態フラグが「使用中」状態のＩ
Ｏパス名“（２００，２９０，１１）”、“（３００，
３９０，２２）”を求める（ステップ５０４）。
【０１１５】（３）アクセス要求がライト要求の場合
は、前述の両方のＩＯパスに対して同一内容の書き込み
を行う。このため、ファイルサーバ１４０は、前記２つ
のＩＯパス名が含むノードがローカルノードか否かを判
定し、ローカルノードでない場合、すなわちリモートノ
ードである場合、２つのＩＯパスが含むノード番号に対
応するノード（ノード２００、ノード３００）のファイ
ルサーバ２４０、３４０にＩＯパス名を指定したライト
要求を送信する（ステップ５０５、５０６）。
【０１１６】（４）ステップ５０５での判定が、ノード
がローカルノードであった場合、ローカルノードのディ
スクドライバにＩＯパスを指定したライト要求を送信す
る（ステップ５０７）。
【０１１７】図１５に示す例の場合、前述の処理で、フ
ァイルサーバ１４０は、ファイルサーバ２４０にＩＯパ
ス“（２００，２９０，１１）”を指定したライト要求
を送信し、ファイルサーバ３４０にＩＯパス“（３０
０，３９０，２２）”を指定したライト要求を送信す
る。これらのライト要求を受信したファイルサーバ２４
０、３４０は、それぞれのノードのディスクドライバに
ＩＯパスを指定したライト要求を送信する。
【０１１８】受信したアクセス要求がリード要求の場
合、ファイルサーバ１４０は、前述したＩＯパスのうち
で、論理ディスク管理テーブルの最も最初のフィールド
に登録されていたＩＯパス“（２００，２９０，１
１）”を使用してアクセスを行う。もし、ＩＯパスの障
害などの理由により、このＩＯパスを使用してアクセス
することができない場合、順に次のフィールドに登録さ
れているＩＯパスを使用してアクセスを試みる。また、
前述のＩＯパスの中で、ローカルノードのノード番号を
含むものがあれば、そのＩＯパスを最初に使うようにし
てもよい。このように、なるべくリモートアクセスを減
らすことによって、ネットワークの負荷を減らすことが
できる。リード処理に使用するＩＯパスが決定した後の
処理は、ライト要求の場合と同様である。
【０１１９】次に、障害発生時、障害が発生したＩＯパ
スを切り放す処理を説明する。ここでは、ディスクコン
トローラやＩＯインターフェイスの障害により、ノード
２００に接続されていた物理ディスク装置２０にアクセ
スするためのＩＯパス“（２００，２９０，１１）”が
使用不可能になったものとして説明する。
【０１２０】障害の発生により、ＩＯパス“（２００，
２９０，１１）”が使用できなくなった場合、ノード２
００のデバイスドライバ２５０は、このＩＯパスの障害
を検出し、障害発生をファイルサーバ２４０に通知す
る。
【０１２１】この通知を受けたファイルサーバ２４０
は、論理ディスク管理テーブル２７０を更新し、障害発
生ＩＯパスの状態フラグを「使用不可」状態にする。フ
ァイルサーバ２４０は、図５に示したフローによる方法
により、全てのリモートノードのファイルサーバと通信
を行い、全てのノードの論理ディスク管理テーブルを論
理ディスク管理テーブル２７０と同一の内容に更新す
る。
【０１２２】最後に、ファイルサーバ２４０は、高信頼
ディスク装置３０が接続されたノード１００のファイル
サーバ１４０に、障害発生ＩＯパス“（２００，２９
０，１１）”が「使用不可」状態になったことを、マウ
ント構成ファイル２４に記載するように要求する。この
要求を受けたファイルサーバは、マウント構成ファイル
２４を更新し、上記障害発生ＩＯパスの使用可否情報を
“unavailable”(使用不可）に書き換える。以上により
ＩＯパスの切り離しが終了する。
【０１２３】ＩＯパスの切り離し処理中に、あるノード
のファイルサーバ（例えば、ファイルサーバ１４０）
が、ファイルサーバ２４０に前述の障害発生ＩＯパスを
指定したアクセス要求を送るとその要求は失敗する。し
かし、ライト処理の場合、データは、同時に複数の物理
ディスク装置に書き込まれるので、アクセス可能な物理
ディスク装置（物理ディスク装置２０）の方に無事に記
録されている。また、リード処理の場合、アクセス要求
を行ったファイルサーバは、アクセスに失敗したら別の
ＩＯパス“（３００，３９０，２２）”を指定したＩＯ
アクセス要求をファイルサーバ３４０に送信する。この
ため、データは、アクセス可能な物理ディスク装置から
無事に読み込まれる。従って、ＩＯパス切り替え中もユ
ーザは、それを意識することなくファイルにアクセスす
ることができる。
【０１２４】前述した本発明の実施形態において、ノー
ド２００で障害が発生したことにより、ＩＯパス“（２
００，２９０，１１）”が使用できなくなった場合、ノ
ード２００にＩＯアクセス要求を送信したリモートノー
ドのファイルサーバが、送信したアクセス要求のタイム
アウトによってノード２００の障害を検出し、障害を検
出したこのファイルサーバが上記のＩＯパスの切り離し
処理を行うようにすればよい。
【０１２５】また、前述した本発明の実施形態におい
て、論理ディスク管理テーブルに、論理ディスクの使用
方法（切り替え、ミラーリングなど）を指定するための
ディスクタイプ情報を論理ディスクＩＤ毎に登録できる
ようにし、マウント構成ファイル２４に上記ディスクタ
イプ情報を登録できるようにし、システム起動時にファ
イルサーバ１４０がマウント構成情報２４に記載された
ディスクタイプ情報を、論理ディスク管理テーブルのデ
ィスクタイプ情報に登録し、通常運用時及び障害発生
時、ファイルサーバが論理ディスク管理テーブルのディ
スクタイプ情報によって、ディスクタイプを判別し各デ
ィスクタイプ毎の処理を行うようにすることもできる。
例えば、図１５に示す例の場合、マウント構成ファイル
２４には“（（２００，２９０，１１） available）
（（３００，３９０，２２） available） /mnt mirro
r”と記載する。“mirror”は、前述２つのＩＯパスか
らアクセスされる物理ディスク装置に対して、ミラーリ
ングを行うことを示す。ファイルサーバ１４０は、起動
時に前述のエントリを読み込んで、ディスクタイプが
「ミラーリング」であることを判別し、論理ディスク管
理テーブルの対応するディスクタイプ情報に、「ミラー
リング」であることを登録する。通常運用時、ファイル
サーバは、論理ディスク管理テーブルのディスクタイプ
情報を参照して、前述のＩＯパスの組が「ミラーリン
グ」を行うものであることを判別すると、前述した実施
形態により説明した「ミラーリング」の処理を行う。デ
ィスクタイプが「切り替え」の場合も同様である。これ
により、ＩＯパスの切り替えとミラーリングをシステム
で共存させることができる。
【０１２６】前述した本発明の第３の実施形態は、ファ
イルのミラーリングを行うものとして説明したが、論理
ディスク管理テーブルの１つのエントリに登録されたＩ
Ｏパスからアクセスされる物理ディスク装置に、ファイ
ルを分散して記録するようにすれば、ファイルのストラ
イピングを行うことができる。
【０１２７】
【発明の効果】以上説明したように本発明によれば、Ｉ
Ｏパス切り替え・復旧処理のためにかかる時間を短縮す
ることができ、また、ＩＯパス切り替え時にファイルの
整合性のチェックを不要にすることができる。また、本
発明によれば、ＩＯパスの切り替え・切り離し処理が発
生しても、一般ユーザはそれを意識することなく作業を
続けることができる。さらに、本発明によれば、ＩＯパ
ス切り替え・切り離し処理後あるいは障害発生ＩＯパス
復旧後、システムを再起動する際にシステム管理者がマ
ウント構成ファイルを設定しなおす必要をなくすことが
でき、システム管理者の負担を軽減することができる。
【図面の簡単な説明】
【図１】本発明の第１の実施形態によるファイルシステ
ムの構成を示すブロック図である。
【図２】システム内に設けられる各種のテーブルの具対
的な構成例を説明する図である。
【図３】マウント構成ファイルの具体的な構成例を説明
する図である。
【図４】システムの起動時のファイルサーバの処理動作
を説明するフローチャートである。
【図５】システム全体のノードの論理ディスク管理テー
ブルを更新する処理動作を説明するフローチャートであ
る。
【図６】通常運用時のファイルサーバの処理動作を説明
するフローチャートである。
【図７】ＩＯパスの切り替えの処理動作を説明するフロ
ーチャートである。
【図８】ＩＯパスに障害が発生しＩＯパスの切り替えを
行う処理について説明する図（その１）である。
【図９】ＩＯパスに障害が発生しＩＯパスの切り替えを
行う処理について説明する図（その２）である。
【図１０】ＩＯパスに障害が発生しＩＯパスの切り替え
を行う処理について説明する図（その３）である。
【図１１】ＩＯパスが障害から復旧したとき、ＩＯパス
をシステムに復旧させる処理手順を説明するフローチャ
ートである。
【図１２】ＩＯパス切り替え時の障害発生ノードの処理
動作の他の例について説明するフローチャートである。
【図１３】障害発生ノード以外のノードの処理動作の他
の例を説明するフローチャートである。
【図１４】本発明の第２の実施形態によるディスクキャ
ッシュの書き戻しの処理とバッファキャッシュの転送の
処理とを説明する図である。
【図１５】本発明の第３の実施形態によるファイルシス
テムの構成を示すブロック図である。
【図１６】本発明の第３の実施形態におけるマウント構
成ファイルの具体的な構成例を説明する図である。
【符号の説明】
１ ネットワーク １０、２０、３０ 物理ディスク装置 １１、１２、２１、２２ ディスクコントローラ １３ ディスクキャッシュ ２４ マウント構成ファイル １００、２００、３００ ノード １１０、２１０、３１０ ＣＰＵ １２０、２２０、３２０ メモリ １３０、２３０ ユーザアプリケーション（ＵＡＰ） １４０、２４０、３４０ ファイルサーバ（ＦＳ） １６０、２６０ ファイル管理テーブ １７０、２７０ 論理ディスク管理テーブル １８０、２８０、３６０ バッファキャッシュ ２５０、３５０ ディスクドライバ ２９０、３９０ ＩＯインタフェース
───────────────────────────────────────────────────── フロントページの続き (72)発明者 薗田 浩二 神奈川県川崎市麻生区王禅寺1099番地 株 式会社日立製作所システム開発研究所内 (72)発明者 熊▲崎▼ 裕之 神奈川県横浜市戸塚区戸塚町5030番地 株 式会社日立製作所ソフトウェア事業部内 Ｆターム(参考） 5B014 HA09 HA13 HB01 HB26 5B018 GA10 HA40 KA11 MA12 QA01 5B065 CC01 EA12 5B082 EA01 FA05 5B083 AA08 BB03 CC04 CD11 EE08

Claims (20)

    【特許請求の範囲】
  1. 【請求項１】 ファイル毎にファイルＩＤが定義されて
    おり、複数の物理ディスク装置に分散管理されたファイ
    ルの処理を行う１または複数のファイルサーバを有する
    ファイルシステムにおいて、ファイルＩＤ及び該ファイ
    ルＩＤに対応するファイルが格納されている論理ディス
    クの論理ディスクＩＤを含むファイル管理テーブルと、
    論理ディスクＩＤ及び前記論理ディスクに対応する１つ
    以上の物理ディスク装置にアクセスするための１つ以上
    のＩＯパスを含む論理ディスク管理テーブルとを備え、
    ユーザからのファイルＩＤを指定したファイルへのアク
    セス要求を受信したファイルサーバは、ファイル管理テ
    ーブルを参照し、前記ファイルＩＤから前記ファイルが
    格納されている論理ディスクの論理ディスクＩＤを決定
    し、論理ディスク管理テーブルを参照して前記論理ディ
    スクＩＤから前記論理ディスクに対応する物理ディスク
    装置にアクセスするためのＩＯパスを決定し、決定した
    ＩＯパスを使用して物理ディスク装置にアクセスするこ
    とを特徴とするファイルシステム。
  2. 【請求項２】 ネットワークに接続されたそれぞれの内
    部にファイルサーバが構成された複数のノードと、複数
    のノードの少なくとも２つのノードに共通に接続された
    物理ディスク装置とを備え、ファイル毎にファイルＩＤ
    が定義されており、前記複数の物理ディスク装置に分散
    管理されたファイルの処理を行うファイルシステムにお
    いて、複数のノードのそれぞれは、ファイルＩＤ及び前
    記ファイルＩＤに対応するファイルが格納されている論
    理ディスクの論理ディスクＩＤを含むファイル管理テー
    ブルと、論理ディスクＩＤ及び前記論理ディスクに対応
    する１つ以上の物理ディスク装置にアクセスするための
    １つ以上のＩＯパスを含む論理ディスク管理テーブルと
    を備え、ユーザからのファイルＩＤを指定したファイル
    へのアクセス要求を受信したファイルサーバは、ファイ
    ル管理テーブルを参照し、前記ファイルＩＤから前記フ
    ァイルが格納されている論理ディスクの論理ディスクＩ
    Ｄを決定し、論理ディスク管理テーブルを参照して前記
    論理ディスクＩＤから前記論理ディスクに対応する物理
    ディスク装置にアクセスするためのＩＯパスを決定し、
    決定したＩＯパスを使用して物理ディスク装置にアクセ
    スすることを特徴とするファイルシステム。
  3. 【請求項３】 前記ＩＯパスを特定する情報は、ノード
    番号、ＩＯインターフェイス番号及びディスクコントロ
    ーラ番号からなることを特徴とする請求項２記載のファ
    イルシステム。
  4. 【請求項４】 前記ファイルＩＤから決定した論理ディ
    スクＩＤに対応する物理ディスク装置が、他のノードで
    あるリモートノードに接続されている場合、自ノードの
    ファイルサーバは、前記リモートノードにアクセス要求
    を送信し、前記アクセス要求を受信した前記リモートノ
    ードのファイルサーバが前記物理ディスク装置に格納さ
    れた該当ファイルにアクセスすることを特徴とする請求
    項３記載のファイルシステム。
  5. 【請求項５】 ネットワークに接続されたそれぞれの内
    部にファイルサーバが構成された複数のノードと、複数
    のノードの少なくとも２つのノードに共通に接続された
    物理ディスク装置とを備え、ファイル毎にファイルＩＤ
    が定義されており、前記複数の物理ディスク装置に分散
    管理されたファイルの処理を行うファイルシステムにお
    いて、前記物理ディスク装置の少なくとも１つは、１つ
    のマウントポイントに対して物理ディスク装置にアクセ
    スするための１つ以上のＩＯパスを対応づける情報を１
    つのエントリに含むマウント構成ファイルを格納してお
    り、システム立ち上げ時、前記マウント構成ファイルを
    格納するディスク装置が接続されたノードのファイルサ
    ーバは、前記マウント構成ファイルを読み出し、前記マ
    ウント構成ファイルの１つのエントリに記載された１つ
    以上のＩＯパスに対して１つの論理ディスクＩＤを自動
    設定し、前記論理ディスクＩＤと前記ＩＯパスとの対応
    関係を論理ディスク管理テーブルに登録し、他の全ての
    ノードのファイルサーバと通信を行うことによって、前
    記論理ディスク管理テーブルの内容を全てのノードの論
    理ディスク管理テーブルに複写し、前記マウント構成フ
    ァイルによって前記ＩＯパスに対応づけられたマウント
    ポイントに前記論理ディスクＩＤに対応する論理ディス
    クをマウントし、複数のノードのそれぞれは、ファイル
    ＩＤ及び前記ファイルＩＤに対応するファイルが格納さ
    れている論理ディスクの論理ディスクＩＤを含むファイ
    ル管理テーブルと、論理ディスクＩＤ及び前記論理ディ
    スクに対応する１つ以上の物理ディスク装置にアクセス
    するための１つ以上のＩＯパスを含む論理ディスク管理
    テーブルとを備え、ユーザからのファイルＩＤを指定し
    たファイルへのアクセス要求を受信したファイルサーバ
    は、ファイル管理テーブルを参照し、前記ファイルＩＤ
    から前記ファイルが格納されている論理ディスクの論理
    ディスクＩＤを決定し、論理ディスク管理テーブルを参
    照して前記論理ディスクＩＤから前記論理ディスクに対
    応する物理ディスク装置にアクセスするためのＩＯパス
    を決定し、決定したＩＯパスを使用して物理ディスク装
    置にアクセスすることを特徴とするファイルシステム。
  6. 【請求項６】 前記マウント構成ファイルは、ＩＯパス
    毎に前記ＩＯパスが使用できるか否かを登録する使用可
    否情報を含み、論理ディスク管理テーブルは、前記論理
    ディスク管理テーブルに登録されているＩＯパス毎に稼
    働状態を保持する状態フラグを含み、マウント処理を行
    うファイルサーバは、システム立ち上げ時に、前記マウ
    ント構成ファイルの１つのエントリに記載された複数の
    ＩＯパスのうち、前記マウント構成ファイルの使用可否
    情報に「使用可」と登録されたＩＯパスの１つについ
    て、論理ディスク管理テーブルの前記ＩＯパスに対応す
    る状態フラグに「使用中」状態と登録し、前記マウント
    構成ファイルの使用可否情報に「使用可」と登録された
    残りのＩＯパスについて、前記論理ディスク管理テーブ
    ルの前記ＩＯパスに対応する状態フラグに「待機中」状
    態と登録し、前記マウント構成ファイルの使用可否情報
    に「使用不可」と登録されたＩＯパスについて、前記論
    理ディスク管理テーブルの前記ＩＯパスに対応する状態
    フラグに「使用不可」状態と登録し、各ノードのファイ
    ルサーバは、通常運用時、前記論理ディスク管理テーブ
    ルの状態フラグが「使用中」状態となっている運用系の
    ＩＯパスを用いて、物理ディスク装置にアクセスするこ
    とを特徴とする請求項５記載のファイルシステム。
  7. 【請求項７】 前記物理ディスク装置のディスクコント
    ローラ、前記物理ディスク装置が接続されたノードのＩ
    Ｏインターフェイスなどの障害によって、運用系ＩＯパ
    スが使用不可能になったとき、前記障害を検出したノー
    ドのファイルサーバは、前記ノードの論理ディスク管理
    テーブルを更新し、前記使用不可能になったＩＯパスの
    状態フラグを「使用不可」とし、前記使用不可能になっ
    たＩＯパスと同じ論理ディスクＩＤに対応付けられてい
    るＩＯパスのうち状態フラグが「待機中」である１つの
    ＩＯパスの状態フラグを「使用中」として新運用系ＩＯ
    パスとした後、全ての他のリモートノードのファイルサ
    ーバと通信を行い、前記論理ディスク管理テーブルの内
    容を全ノードの論理ディスク管理テーブルに複写するこ
    とによって、前記物理ディスク装置へアクセスするため
    のＩＯパスを前記使用不可能となったＩＯパスから前記
    新運用系ＩＯパスに切り替えることを特徴とする請求項
    ６記載のファイルシステム。
  8. 【請求項８】 前記ＩＯパスの切り替え処理の間、使用
    不可能となったＩＯパスに含まれるノードのファイルサ
    ーバは、使用不可能になったＩＯパスへのアクセス要求
    を保留し、ＩＯパスの切り替え処理終了時、保留してい
    た前記アクセス要求を新運用系ＩＯパスに含まれるノー
    ドに転送することを特徴とする請求項７記載のファイル
    システム。
  9. 【請求項９】 前記ＩＯパスの切り替え処理の間、使用
    不可能となったＩＯパスに含まれるノードにアクセス要
    求を発行したファイルサーバは、前記アクセス要求がタ
    イムアウトになった場合、論理ディスク管理テーブルを
    参照し論理ディスクＩＤからＩＯパスを求め直し、新し
    く求め直したＩＯパスを使用して、物理ディスク装置に
    アクセスし直すことを特徴とする請求項７記載のファイ
    ルシステム。
  10. 【請求項１０】 前記複数のノードのそれぞれは、物理
    ディスク装置との間に転送されるデータを一時的に保持
    するバッファキャッシュを備え、ＩＯパスの切り替え処
    理時、使用不可能になったＩＯパスに含まれるノードの
    ファイルサーバと、新運用系ＩＯパスに含まれるノード
    のファイルサーバとが通信を行い、前記使用不可能にな
    ったＩＯパスに含まれるノードの主記憶内に存在し、物
    理ディスク装置に書き戻す必要があるバッファキャッシ
    ュ及びファイル管理テーブルを前記新運用系ＩＯパスに
    含まれるノードに転送することを特徴とする請求項７記
    載のファイルシステム。
  11. 【請求項１１】 前記物理ディスク装置内のディスクコ
    ントローラは、ディスク領域との間で転送されるデータ
    を一時的に保持するディスクキャッシュを備え、前記物
    理ディスク装置内の別のディスクコントローラが備える
    ディスクキャッシュに格納されたデータをディスク領域
    に書き戻す機能を有し、ＩＯパスの切り替え処理時、前
    記使用不可能になったＩＯパスを使ってアクセスしてい
    た物理ディスク装置内に設けられた前記使用不可能にな
    ったＩＯパスに含まれるディスクコントローラが備える
    ディスクキャッシュに格納されたデータのうち、前記物
    理ディスク装置に書き戻す必要のあるデータを、前記物
    理ディスク装置内に存在し、新運用系ＩＯパスに含まれ
    るディスクコントローラを使用して、前記物理ディスク
    装置に書き戻すことを特徴とする請求項７記載のファイ
    ルシステム。
  12. 【請求項１２】 ＩＯパスの切り替え終了時、マウント
    構成ファイルを格納するディスク装置が接続されたノー
    ドのファイルサーバが前記マウント構成ファイルを更新
    し、前記使用不可能となったＩＯパスの使用可否情報を
    「使用不可」に書き換えることを特徴とする請求項７記
    載のファイルシステム。
  13. 【請求項１３】 使用不可能となっていたＩＯパスが再
    び使用できるようになったとき、前記複数のノードのあ
    る１つのノードのファイルサーバが、自ノードの論理デ
    ィスク管理テーブルに登録された前記ＩＯパスの状態フ
    ラグを「使用不可」状態から「待機中」状態に更新し、
    前記ファイルサーバが他の全てのノードのファイルサー
    バと通信を行うことにより、全てのノードの論理ディス
    ク管理テーブルに前記更新内容を複写した後、マウント
    構成ファイルを格納するディスク装置が接続されたノー
    ドのファイルサーバが、前記マウント構成ファイルに登
    録された前記ＩＯパスの使用可否情報を「使用可」に書
    き換えることにより、前記ＩＯパスを待機系ＩＯパスと
    してシステムに復旧させることを特徴とする請求項７記
    載のファイルシステム。
  14. 【請求項１４】 物理ディスク装置が接続されたノード
    に障害が発生したとき、前記ノードの障害を検出した他
    のノードのファイルサーバは、自ノードの論理ディスク
    管理テーブルを検索し、障害発生ノード番号から障害発
    生ＩＯパス及び前記障害発生ＩＯパスと同じ論理ディス
    クＩＤに対応付けられているＩＯパスのうち状態フラグ
    が「待機中」であるＩＯパスの１つを新運用系ＩＯパス
    として求め、この新運用系ＩＯパスに含まれるノードの
    ファイルサーバにＩＯパスの切り替え処理を行うように
    要求し、前記要求を受けた前記ファイルサーバは、自ノ
    ードの論理ディスク管理テーブルを更新し、前記障害発
    生ＩＯパスの状態フラグを「使用不可」とし、前記新運
    用系ＩＯパスの状態フラグを「使用中」とした後、他の
    全てのノードのファイルサーバと通信を行い、前記論理
    ディスク管理テーブルの内容を全ノードの論理ディスク
    管理テーブルに複写することによって、前記物理ディス
    ク装置へアクセスするためのＩＯパスを前記障害発生Ｉ
    Ｏパスから前記新運用系ＩＯパスに切り替えることを特
    徴とする請求項６記載のファイルシステム。
  15. 【請求項１５】 ＩＯパスの切り替え処理の間、前記障
    害発生ＩＯパスに含まれるノードにアクセス要求を発行
    したファイルサーバは、前記アクセス要求がタイムアウ
    トになった場合、論理ディスク管理テーブルを参照し論
    理ディスクＩＤからＩＯパスを求め直し、新しく求め直
    したＩＯパスを使用して、物理ディスク装置にアクセス
    し直すことを特徴とする請求項１４記載のファイルシス
    テム。
  16. 【請求項１６】 前記物理ディスク装置が接続されてい
    るノードは、自ノードの状態にかかわりなく自ノードが
    備えるメモリ内のデータを読み出し、読み出したデータ
    を他のノードに転送する機能を持ったハードウェアを有
    し、ＩＯパスの切り替え処理時、前記ハードウェアを用
    いて、前記障害発生ＩＯパスに含まれるノードの主記憶
    内に存在し、物理ディスク装置に書き戻す必要があるバ
    ッファキャッシュ及びファイル管理テーブルを前記新運
    用系ＩＯパスに含まれるノードに転送することを特徴と
    する請求項１４記載のファイルシステム。
  17. 【請求項１７】 前記物理ディスク装置内のディスクコ
    ントローラは、ディスク領域との間で転送されるデータ
    を一時的に保持するディスクキャッシュを備え、前記物
    理ディスク装置内の別のディスクコントローラが備える
    ディスクキャッシュに格納されたデータをディスク領域
    に書き戻す機能を有し、ＩＯパスの切り替え処理時、前
    記障害発生ＩＯパスを使ってアクセスしていた物理ディ
    スク装置内に設けられた前記障害発生ＩＯパスに含まれ
    るディスクコントローラが備えるディスクキャッシュに
    格納されたデータのうち、前記物理ディスク装置に書き
    戻す必要のあるデータを、前記物理ディスク装置内に存
    在し、新運用系ＩＯパスに含まれるディスクコントロー
    ラを使用して、前記物理ディスク装置に書き戻すことを
    特徴とする請求項１４記載のファイルシステム。
  18. 【請求項１８】 ＩＯパスの切り替え終了時、マウント
    構成ファイルを格納するディスク装置が接続されたノー
    ドのファイルサーバが前記マウント構成ファイルを更新
    し、使用できなくなった運用系ＩＯパスの使用可否情報
    を「使用不可」に書き換えることを特徴とする請求項１
    ４記載のファイルシステム。
  19. 【請求項１９】 前記マウント構成ファイルは、ＩＯパ
    ス毎に前記ＩＯパスが使用できるか否かを登録する使用
    可否情報を含み、前記論理ディスク管理テーブルは、該
    論理ディスク管理テーブルに登録されているＩＯパス毎
    に稼働状態を保持する状態フラグを含み、前記マウント
    処理を行うファイルサーバは、システム立ち上げ時に、
    前記マウント構成ファイルの使用可否情報に「使用可」
    と登録されたＩＯパスについて、論理ディスク管理テー
    ブルの前記ＩＯパスに対応する状態フラグに「使用中」
    状態と登録し、前記マウント構成ファイルの使用可否情
    報に「使用不可」と登録されたＩＯパスについて、論理
    ディスク管理テーブルの前記ＩＯパスに対応する状態フ
    ラグに「使用不可」状態と登録し、通常運用時、ファイ
    ルサーバは、前記論理ディスク管理テーブルの状態フラ
    グが「使用中」状態のＩＯパスからアクセスされる物理
    ディスク装置にファイルをミラーリングすることを特徴
    とする請求項５記載のファイルシステム。
  20. 【請求項２０】 前記使用中ＩＯパスの１つに障害が発
    生したとき、この障害を検出したノードのファイルサー
    バは、自ノードの論理ディスク管理テーブルを更新し、
    障害が発生した前記ＩＯパスの状態フラグを「使用不
    可」とした後、他の全てのノードのファイルサーバと通
    信を行い、前記論理ディスク管理テーブルの内容を全ノ
    ードの論理ディスク管理テーブルに複写し、マウント構
    成ファイルを格納するディスク装置が接続されたノード
    のファイルサーバが、前記マウント構成ファイルを更新
    し、前記障害が発生したＩＯパスの使用可否情報を「使
    用不可」に書き換えることによって、障害が発生したＩ
    Ｏパスを切り放すことを特徴とする請求項１９記載のフ
    ァイルシステム。
JP2000233291A 2000-08-01 2000-08-01 ファイルシステム Expired - Fee Related JP3992427B2 (ja)

Priority Applications (5)

Application Number Priority Date Filing Date Title
JP2000233291A JP3992427B2 (ja) 2000-08-01 2000-08-01 ファイルシステム
EP00127995A EP1179770B1 (en) 2000-08-01 2000-12-20 File system
US09/746,608 US6654769B2 (en) 2000-08-01 2000-12-20 File system for creating switched logical I/O paths for fault recovery
US10/695,149 US7130868B2 (en) 2000-08-01 2003-10-27 File system for creating switched logical I/O paths for fault recovery
US11/527,363 US20070016751A1 (en) 2000-08-01 2006-09-25 File system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2000233291A JP3992427B2 (ja) 2000-08-01 2000-08-01 ファイルシステム

Publications (2)

Publication Number Publication Date
JP2002049575A true JP2002049575A (ja) 2002-02-15
JP3992427B2 JP3992427B2 (ja) 2007-10-17

Family

ID=18725830

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2000233291A Expired - Fee Related JP3992427B2 (ja) 2000-08-01 2000-08-01 ファイルシステム

Country Status (3)

Country Link
US (3) US6654769B2 (ja)
EP (1) EP1179770B1 (ja)
JP (1) JP3992427B2 (ja)

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003256147A (ja) * 2002-02-28 2003-09-10 Hitachi Ltd クラスタ型ディスクアレイ装置およびクラスタ型ディスクアレイ装置の運用方法
US7093155B2 (en) 2003-11-18 2006-08-15 Hitachi, Ltd. Information processing system and method for path failover
JP2008065616A (ja) * 2006-09-07 2008-03-21 Casio Comput Co Ltd コンピュータ、周辺機器接続管理方法及びプログラム
WO2008139521A1 (ja) * 2007-04-27 2008-11-20 Fujitsu Limited リモートファイルシステム、端末装置およびサーバ装置
JP2009223702A (ja) * 2008-03-17 2009-10-01 Fujitsu Ltd 入出力制御方法、制御装置及びプログラム
JP2010003061A (ja) * 2008-06-19 2010-01-07 Hitachi Ltd 計算機システム及びそのｉ／ｏ構成変更方法
JP2010146087A (ja) * 2008-12-16 2010-07-01 Hitachi Ltd 系切替計算機システムの管理方法
JP2012208896A (ja) * 2011-03-30 2012-10-25 Nec Corp ディスクアレイ装置、接続経路制御方法、及び接続経路制御プログラム
JP2014519100A (ja) * 2011-05-18 2014-08-07 アリババ・グループ・ホールディング・リミテッド 分散キャッシングおよびキャッシュ分析
JP2019507409A (ja) * 2015-12-30 2019-03-14 アリババ グループ ホウルディング リミテッド 従来のファイルシステムインターフェースを使用することによってクラウドストレージサービスにアクセスする方法及び装置

Families Citing this family (57)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100424481B1 (ko) * 2000-06-24 2004-03-22 엘지전자 주식회사 디지털 방송 부가서비스 정보의 기록 재생장치 및 방법과그에 따른 기록매체
KR100910972B1 (ko) * 2002-12-07 2009-08-05 엘지전자 주식회사 대화형 광디스크 장치에서의 재생 제어방법
US6725393B1 (en) * 2000-11-06 2004-04-20 Hewlett-Packard Development Company, L.P. System, machine, and method for maintenance of mirrored datasets through surrogate writes during storage-area network transients
US7512635B1 (en) * 2000-12-18 2009-03-31 Bmc Software, Inc. System and method for updating information on a computer system using a limited amount of space
US7028079B2 (en) * 2001-05-25 2006-04-11 Lenovo (Singapore) Pte, Ltd. Method and apparatus for the automatic migration of applications and their associated data and configuration files
US6976039B2 (en) 2001-05-25 2005-12-13 International Business Machines Corporation Method and system for processing backup data associated with application, querying metadata files describing files accessed by the application
US7016920B2 (en) * 2001-05-25 2006-03-21 International Business Machines Corporation Method for tracking relationships between specified file name and particular program used for subsequent access in a database
US20030033354A1 (en) * 2001-08-08 2003-02-13 Schulz Kenneth Joseph System and method for caching entitlement sets
US6832297B2 (en) * 2001-08-09 2004-12-14 International Business Machines Corporation Method and apparatus for managing data in a distributed buffer system
JP2003296290A (ja) * 2002-04-02 2003-10-17 Hitachi Ltd 記憶装置システム及びデータ転送方法
KR100930354B1 (ko) * 2002-06-18 2009-12-08 엘지전자 주식회사 대화형 광디스크 장치에서의 콘텐츠 정보 재생방법과,콘텐츠 제공서버에서의 콘텐츠 정보 제공방법
US7107385B2 (en) * 2002-08-09 2006-09-12 Network Appliance, Inc. Storage virtualization by layering virtual disk objects on a file system
KR100920654B1 (ko) * 2002-12-09 2009-10-09 엘지전자 주식회사 대화형 광디스크 장치에서의 재생 제어방법
US20050010610A1 (en) * 2003-07-08 2005-01-13 Konica Minolta Business Technologies, Inc. File management system, file management apparatus and image forming apparatus
JP4291077B2 (ja) * 2003-07-29 2009-07-08 株式会社日立製作所 分散ストレージ装置のファイル管理方法及び分散ストレージシステム
US7457828B2 (en) * 2003-08-29 2008-11-25 Sap Ag System and method for synchronizing distributed buffers when committing data to a database
JP4383132B2 (ja) * 2003-09-02 2009-12-16 株式会社日立製作所 仮想化制御装置及び計算機システム
JP4349871B2 (ja) * 2003-09-09 2009-10-21 株式会社日立製作所 ファイル共有装置及びファイル共有装置間のデータ移行方法
JP4267421B2 (ja) * 2003-10-24 2009-05-27 株式会社日立製作所 リモートサイト及び／又はローカルサイトのストレージシステム及びリモートサイトストレージシステムのファイル参照方法
US7313719B1 (en) * 2004-02-06 2007-12-25 Symantec Operating Corporation Restore of backup to computer system with filesystem/volume attribute modification
US7322010B1 (en) 2004-02-06 2008-01-22 Symantec Operating Corporation Graphical user interface for mapping computer resources
JP4859348B2 (ja) * 2004-02-18 2012-01-25 大日本印刷株式会社 コンピュータシステム
US20050262296A1 (en) * 2004-05-20 2005-11-24 International Business Machines (Ibm) Corporation Selective dual copy control of data storage and copying in a peer-to-peer virtual tape server system
US8131674B2 (en) * 2004-06-25 2012-03-06 Apple Inc. Methods and systems for managing data
US7991783B2 (en) * 2004-10-05 2011-08-02 International Business Machines Corporation Apparatus, system, and method for supporting storage functions using an embedded database management system
JP4448005B2 (ja) * 2004-10-22 2010-04-07 株式会社日立製作所 記憶システム
JP2006134207A (ja) * 2004-11-09 2006-05-25 Fujitsu Ltd ストレージ仮想化装置およびそれを用いたコンピュータシステム
US20060117008A1 (en) * 2004-11-17 2006-06-01 Kabushiki Kaisha Toshiba File management apparatus and file management program
JP4451293B2 (ja) * 2004-12-10 2010-04-14 株式会社日立製作所 名前空間を共有するクラスタ構成のネットワークストレージシステム及びその制御方法
US7543305B2 (en) * 2005-03-24 2009-06-02 International Business Machines Corporation Selective event registration
US20070106700A1 (en) * 2005-11-04 2007-05-10 Sun Microsystems, Inc. Hierarchical file system naming
JP4472646B2 (ja) * 2006-02-10 2010-06-02 エヌイーシーコンピュータテクノ株式会社 システム制御装置、システム制御方法及びシステム制御プログラム
JP4585463B2 (ja) * 2006-02-15 2010-11-24 富士通株式会社 仮想計算機システムを機能させるためのプログラム
US7882539B2 (en) * 2006-06-02 2011-02-01 Microsoft Corporation Abstracting security policy from, and transforming to, native representations of access check mechanisms
US8132186B1 (en) 2007-03-23 2012-03-06 Symantec Corporation Automatic detection of hardware and device drivers during restore operations
US7886185B1 (en) 2007-03-23 2011-02-08 Symantec Corporation Creation of a device database and synthesis of device driver information during dissimilar system restore
US7769990B1 (en) 2007-03-23 2010-08-03 Symantec Corporation Using a monitoring process to update system configuration settings during restore operations
US9075809B1 (en) * 2007-09-29 2015-07-07 Symantec Corporation Methods and systems for application cluster virtual nodes
US9152817B1 (en) 2007-10-31 2015-10-06 Symantec Corporation Methods and systems for performing data protection operations
US7844757B2 (en) * 2008-06-12 2010-11-30 International Machines Business Corporation Method and system for providing multiple paths to user data stored on a SCSI disk
JP4743282B2 (ja) * 2009-01-26 2011-08-10 横河電機株式会社 冗長化入出力モジュール
US8326802B2 (en) 2009-06-11 2012-12-04 International Business Machines Corporation File system location verification using a sentinel
US8346721B2 (en) * 2009-07-15 2013-01-01 International Business Machines Corporation Apparatus and method to replicate remote virtual volumes to local physical volumes
US8554994B2 (en) * 2009-09-29 2013-10-08 Cleversafe, Inc. Distributed storage network utilizing memory stripes
US8484256B2 (en) * 2010-01-13 2013-07-09 International Business Machines Corporation Transformation of logical data objects for storage
US9122711B1 (en) 2012-05-24 2015-09-01 Symantec Corporation Simplified system backup protection and recovery
JP6005446B2 (ja) * 2012-08-31 2016-10-12 富士通株式会社 ストレージシステム、仮想化制御装置、情報処理装置、および、ストレージシステムの制御方法
KR101718254B1 (ko) * 2012-09-05 2017-03-20 미쓰비시덴키 가부시키가이샤 입출력 응답 제어 설정 장치
US9430545B2 (en) * 2013-10-21 2016-08-30 International Business Machines Corporation Mechanism for communication in a distributed database
US9992237B1 (en) 2014-03-28 2018-06-05 Amazon Technologies, Inc. Determining feature unavailability
WO2016174764A1 (ja) * 2015-04-30 2016-11-03 株式会社日立製作所 管理装置および管理方法
US11223537B1 (en) 2016-08-17 2022-01-11 Veritas Technologies Llc Executing custom scripts from the host during disaster recovery
US20180095788A1 (en) * 2016-10-04 2018-04-05 Pure Storage, Inc. Scheduling operations for a storage device
CN106708445B (zh) * 2017-01-19 2019-09-17 北京腾凌科技有限公司 链路选择方法及装置
US11003372B2 (en) * 2018-05-31 2021-05-11 Portworx, Inc. Protecting volume namespaces from corruption in a distributed container orchestrator
CN110914796B (zh) * 2018-07-17 2021-11-19 华为技术有限公司 处理i/o请求的方法及设备
US10802717B2 (en) * 2018-08-20 2020-10-13 Dell Products L.P. Systems and methods for efficient firmware inventory of storage devices in an information handling system

Family Cites Families (35)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0680492B2 (ja) * 1984-09-29 1994-10-12 株式会社日立製作所 エラー回復方法
US5197069A (en) * 1989-10-20 1993-03-23 International Business Machines Corp. Method and system for detecting and recovering from switching errors
JPH0792733B2 (ja) 1990-07-10 1995-10-09 富士通株式会社 磁気ディスクシステム
JP3300399B2 (ja) 1992-02-28 2002-07-08 株式会社東芝 計算機システムおよびファイル管理方法
JP2953639B2 (ja) 1992-12-02 1999-09-27 株式会社日立製作所 バックアップ装置及びその方法
US5548724A (en) * 1993-03-22 1996-08-20 Hitachi, Ltd. File server system and file access control method of the same
JPH06332782A (ja) 1993-03-22 1994-12-02 Hitachi Ltd ファイルサーバシステム及びそのファイルアクセス制御方法
US5367669A (en) * 1993-03-23 1994-11-22 Eclipse Technologies, Inc. Fault tolerant hard disk array controller
JPH086839A (ja) 1994-06-20 1996-01-12 Nec Corp 分散ファイルシステム
US5941955A (en) * 1994-08-12 1999-08-24 British Telecommunications Public Limited Company Recovery of distributed hierarchical data access routing system upon detected failure of communication between nodes
US5845061A (en) * 1994-10-31 1998-12-01 Hitachi, Ltd. Redundant client server system
DE69521101T2 (de) * 1994-10-31 2001-10-18 Ibm Gemeinsam genutzte virtuelle Platten mit anwendungstransparenter Wiedergewinnung
JPH08314843A (ja) 1995-05-22 1996-11-29 Hitachi Ltd 計算機システム
US5680640A (en) * 1995-09-01 1997-10-21 Emc Corporation System for migrating data by selecting a first or second transfer means based on the status of a data element map initialized to a predetermined state
JP2912221B2 (ja) 1996-03-27 1999-06-28 日本電気通信システム株式会社 分散ネットワーク化ストライプド・ファイルシステム
US6044367A (en) * 1996-08-02 2000-03-28 Hewlett-Packard Company Distributed I/O store
US6185601B1 (en) * 1996-08-02 2001-02-06 Hewlett-Packard Company Dynamic load balancing of a network of client and server computers
US5845081A (en) * 1996-09-03 1998-12-01 Sun Microsystems, Inc. Using objects to discover network information about a remote network having a different network protocol
US5922077A (en) * 1996-11-14 1999-07-13 Data General Corporation Fail-over switching system
JPH10187516A (ja) 1996-12-24 1998-07-21 Canon Inc 電子ファイリング方法及び装置並びに記憶媒体
JP3085239B2 (ja) 1997-03-28 2000-09-04 日本電気株式会社 基本処理装置の二重化方式
US6151684A (en) * 1997-03-28 2000-11-21 Tandem Computers Incorporated High availability access to input/output devices in a distributed system
US5944838A (en) * 1997-03-31 1999-08-31 Lsi Logic Corporation Method for fast queue restart after redundant I/O path failover
US6366988B1 (en) * 1997-07-18 2002-04-02 Storactive, Inc. Systems and methods for electronic data storage management
US6219693B1 (en) * 1997-11-04 2001-04-17 Adaptec, Inc. File array storage architecture having file system distributed across a data processing platform
US6145028A (en) * 1997-12-11 2000-11-07 Ncr Corporation Enhanced multi-pathing to an array of storage devices
US6105122A (en) * 1998-02-06 2000-08-15 Ncr Corporation I/O protocol for highly configurable multi-node processing system
US6317844B1 (en) * 1998-03-10 2001-11-13 Network Appliance, Inc. File server storage arrangement
US6324654B1 (en) * 1998-03-30 2001-11-27 Legato Systems, Inc. Computer network remote data mirroring system
JP3726484B2 (ja) * 1998-04-10 2005-12-14 株式会社日立製作所 記憶サブシステム
US5964886A (en) 1998-05-12 1999-10-12 Sun Microsystems, Inc. Highly available cluster virtual disk system
US6353878B1 (en) * 1998-08-13 2002-03-05 Emc Corporation Remote control of backup media in a secondary storage subsystem through access to a primary storage subsystem
JP3918394B2 (ja) * 2000-03-03 2007-05-23 株式会社日立製作所 データ移行方法
US6629189B1 (en) * 2000-03-09 2003-09-30 Emc Corporation Method and apparatus for managing target devices in a multi-path computer system
US6643795B1 (en) * 2000-03-30 2003-11-04 Hewlett-Packard Development Company, L.P. Controller-based bi-directional remote copy system with storage site failover capability

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003256147A (ja) * 2002-02-28 2003-09-10 Hitachi Ltd クラスタ型ディスクアレイ装置およびクラスタ型ディスクアレイ装置の運用方法
US7093155B2 (en) 2003-11-18 2006-08-15 Hitachi, Ltd. Information processing system and method for path failover
JP2008065616A (ja) * 2006-09-07 2008-03-21 Casio Comput Co Ltd コンピュータ、周辺機器接続管理方法及びプログラム
WO2008139521A1 (ja) * 2007-04-27 2008-11-20 Fujitsu Limited リモートファイルシステム、端末装置およびサーバ装置
JPWO2008139521A1 (ja) * 2007-04-27 2010-07-29 富士通株式会社 リモートファイルシステム、端末装置およびサーバ装置
JP2009223702A (ja) * 2008-03-17 2009-10-01 Fujitsu Ltd 入出力制御方法、制御装置及びプログラム
JP2010003061A (ja) * 2008-06-19 2010-01-07 Hitachi Ltd 計算機システム及びそのｉ／ｏ構成変更方法
JP2010146087A (ja) * 2008-12-16 2010-07-01 Hitachi Ltd 系切替計算機システムの管理方法
JP2012208896A (ja) * 2011-03-30 2012-10-25 Nec Corp ディスクアレイ装置、接続経路制御方法、及び接続経路制御プログラム
JP2014519100A (ja) * 2011-05-18 2014-08-07 アリババ・グループ・ホールディング・リミテッド 分散キャッシングおよびキャッシュ分析
JP2017168143A (ja) * 2011-05-18 2017-09-21 アリババ・グループ・ホールディング・リミテッドＡｌｉｂａｂａ Ｇｒｏｕｐ Ｈｏｌｄｉｎｇ Ｌｉｍｉｔｅｄ 分散キャッシングおよびキャッシュ分析
JP2019507409A (ja) * 2015-12-30 2019-03-14 アリババ グループ ホウルディング リミテッド 従来のファイルシステムインターフェースを使用することによってクラウドストレージサービスにアクセスする方法及び装置

Also Published As

Publication number Publication date
EP1179770A3 (en) 2007-03-14
US20070016751A1 (en) 2007-01-18
US6654769B2 (en) 2003-11-25
JP3992427B2 (ja) 2007-10-17
EP1179770A2 (en) 2002-02-13
US20020016792A1 (en) 2002-02-07
EP1179770B1 (en) 2012-08-29
US7130868B2 (en) 2006-10-31
US20040093358A1 (en) 2004-05-13

Similar Documents

Publication Publication Date Title
JP3992427B2 (ja) ファイルシステム
US6862632B1 (en) Dynamic RDF system for transferring initial data between source and destination volume wherein data maybe restored to either volume at same time other data is written
US9037816B1 (en) Reversing a communication path between storage devices
US7519851B2 (en) Apparatus for replicating volumes between heterogenous storage systems
US6789122B1 (en) Mechanism for reliable update of virtual disk device mappings without corrupting data
US7404051B2 (en) Method for replicating snapshot volumes between storage systems
US7386598B2 (en) Computer system with virtualization function
US7836162B2 (en) Transaction processing system and transaction processing method
US20040123068A1 (en) Computer systems, disk systems, and method for controlling disk cache
JP2005537530A (ja) 仮想記憶装置
US20080005288A1 (en) Storage system and data replication method
JP2005004719A (ja) ロールバックによるデータレプリケーション方式
JP4278452B2 (ja) 計算機システム
JP2002244817A (ja) ミラーリング・エージェント
US8745342B2 (en) Computer system for controlling backups using wide area network
JP2003162439A (ja) ストレージシステム及びその制御方法
JP2007133471A (ja) ストレージ装置及びスナップショットのリストア方法
US6029231A (en) Retrieval of data stored on redundant disks across a network using remote procedure calls
US6810447B2 (en) Hierarchical approach to identifying changing device characteristics
JP2008084264A (ja) ネットワークストレージコンピュータシステム、ネットワークストレージ管理方法、管理サーバ、およびそのためのプログラム
EP1507207B1 (en) Hierarchical approach to identifying changing device characteristics

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20050915

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20051122

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20060120

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20061003

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20061204

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20070130

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20070717

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20070724

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20100803

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110803

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120803

Year of fee payment: 5

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130803

Year of fee payment: 6

LAPS Cancellation because of no payment of annual fees