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

Abstract

(57)【要約】 【目的】 信頼性の高いファイルシステムを提供するこ
と。 【構成】 バッファ１Ｄ内の一部または全部のデータに
よるディスク１Ｅの複数のブロックの更新が必要となっ
た場合に、バッファ管理手段１Ｃは、バッファ１Ｄ内の
将来的に更新必要性のある全てのデータによってディス
ク１Ｅを更新する。ファイル記憶装置１Ｓのバッファ管
理手段１Ｃによってフラッシュ処理を実行しようとする
際に、他のファイル記憶装置２Ｓが「調査中」または
「更新中（実行中）」である場合には、フラッシュ逐次
化手段１Ａは、バッファ管理手段１Ｃのフラッシュ処理
開始を制止し、このバッファ管理手段１Ｃを一時的に待
機させる。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、ファイルなどのデータ
を格納するファイルシステムの改良に関するものであ
り、特に、信頼性に優れたファイルシステムに係る。

【０００２】

【従来の技術】大多数のコンピュータは、内部記憶装置
と外部記憶装置を持つ。内部記憶装置は、外部からの継
続的電力供給によって情報を保つ。代表的な内部記憶装
置はＲＡＭで構成された主メモリ(main memory) であ
る。外部記憶装置は、原理や種類にかかわらず、何等か
の記録媒体（例えば、磁気ディスクや光磁気ディスク）
を持つ。記録媒体が着脱可能か否かにかかわらず、単一
の外部記憶装置はドライブと呼ばれる。ドライブの媒体
には、通常、多数のブロックが形成されている。このブ
ロックはアクセスの単位である。

【０００３】例えば、ある規格のフロッピーディスクは
２つのサーフェス(surfaces)を持ち、各サーフェスはそ
れぞれ、同心円状に配置された８０のトラックを持ち、
各トラックは１６セクタに区分される。この各セクタ又
はいくつかの連続したセクタが前記ブロックに相当す
る。固定ディスク装置では、記録媒体は、円筒状に積層
された堅い円盤である。このため、固定ディスク装置は
サーフェスを多数有する。また、トラックの代りにシリ
ンダという用語が使われる。

【０００４】ほとんどの場合、ディスク上の情報を更新
する単一の操作は、媒体上の複数のブロックを更新す
る。その第１の理由は、ブロックのサイズ（例えば２５
６バイト）は、通常、単一の操作の情報量よりはるかに
小さいからである。例えば、コンピュータ上で編集され
たわずか数頁に過ぎない文書も、何十ものブロックやセ
クタを費やして保存される。第２の理由は、媒体上のデ
ータが一般にファイル単位でアクセスされ、かつ、ファ
イルの管理情報は後述のＦＡＴやディレクトリの様に分
かれて配置（記憶）されているからである。

【０００５】ファイルシステムは、外部記憶装置とこの
外部記憶装置のデータをファイル単位でアクセスするた
めの制御手順を総称する概念である。ファイルシステム
は、管理情報（例えば、ＦＡＴ(File Allocation Tabl
e) とディレクトリ）を必要とする。このため、ファイ
ルを更新する場合、ファイルをわずか１セクタ延長する
だけでも、ファイルの内容となるデータのほかに、ＦＡ
Ｔやディレクトリも更新する必要がある。この結果、し
ばしば単一の操作が複数のブロックの内容を更新する。

【０００６】ファイルシステムでは、通常、バッファ(b
uffer)が用いられる。バッファとは、媒体へ書き込むべ
きデータを一時的に蓄積するメモリ上の所定の領域であ
る。バッファは、主メモリを用いてもよいし、ドライブ
駆動用のサブコンピュータ上に設けることも考えられ
る。例えば、ディスクとバッファを組み合わせたシステ
ムでは、ディスク上のデータを変更する操作の際に、変
更するブロックの内容を直接ディスクに書き込まず、バ
ッファに一時的に格納する。バッファに書かれたブロッ
クのデータ（以下、「バッファブロック」と呼ぶ）は、
少なくともシステムを止める前には、媒体に書き込むべ
きものである。このようなバッファブロックがある程度
たまってから実際のディスクアクセスを行えば、ディス
クアクセスの回数を減らし、処理を効率化することがで
きる。

【０００７】バッファがまだディスクに書いていないデ
ータによって一杯になり、新たなデータがバッファに書
き込めない場合は、不足する分のバッファブロックによ
って媒体を更新し、バッファのうち更新済みの領域に新
たなデータを書き込む。

【０００８】

【発明が解決しようとする課題】上記のバッファを用い
るファイルシステムは一般的であるが、このようなファ
イルシステムを用いる場合でも、かつては、単一のコン
ピュータの単一の論理的ドライブを実現するハードウェ
アとしては、実際に単一のドライブのみが接続された。
単一のドライブしか有しないコンピュータは、しばしば
ドライブの故障によるデータの喪失を生じる。ドライブ
の故障は、電源の遮断、ヘッドクラッシュ、制御回路の
故障など多様である。故障による最も不運な結果は、故
障がデータ書き込み中に発生し、媒体がいわば「書きか
け」の状態になることである。

【０００９】ここで、「書きかけ」は同時に更新される
べき複数のブロックのうち、一部のみが更新され、残り
は旧い内容になっている状態を表す。例えば、一般に、
ファイル内のデータと、このファイルのＦＡＴ、ディレ
クトリの情報は、相互に矛盾してはならない。しかし、
これらのうちいずれかが更新されていない状態でドライ
ブが故障すると、相互に整合性を失い、ファイルのデー
タは失われるか、復元困難になる。また、「書きかけ」
の他の例として、例えばＦＡＴのみディスクに書き込み
済で、ディレクトリを書き込んでいない状態では、管理
情報それ自体に矛盾が生じる。さらに、連続したブロッ
クが単一のファイルの一部を構成している場合におい
て、あるブロックの内容は更新されており、次のブロッ
クの内容は旧いままという状態も、「書きかけ」の例で
ある。旧いデータと新しいデータとの間では、当然、整
合性が失われている。

【００１０】新しい内容と旧い内容が混じって整合性を
失ったファイルのデータの復旧は、全体が旧い内容のま
まのファイルのデータの復旧よりも、はるかに困難であ
る。この困難さの一つの原因は、旧い部分と新しい部分
の特定が困難なことである。また、もう一つの原因は、
（特に、ドライブが磁気ディスクの場合に生じるが）、
動作不全に陥ったヘッドによる媒体上のデータの破壊で
ある。これは、ヘッドから発生している書込用の磁界が
故障の瞬間から不正常になったり、ヘッドが磁気面を損
傷するからである。さらに、ファイルの管理情報を失う
ことによってファイル全体を失う事態も生じ得る。

【００１１】特に、不運にもコンピュータのシステム・
ファイルを喪失すると、コンピュータ・システムを起動
できなくなり、故障の診断や復旧自体も不可能になる。

【００１２】このようなデータの喪失に対する許容性
は、分野によって異なる。例えば、帳票計算や実験デー
タの整理あるいは文書作成の分野では、旧いデータから
のやり直しが利く。このような分野では耐障害性をあま
り要求されない。一方、大型プラントの制御や交通シス
テムの制御あるいは銀行の口座管理などの分野では、デ
ータの消滅は許されず、やり直しが利かない。後者の分
野では、データの喪失は、ただちに危険や権利義務関係
の混乱を招くので、耐障害性が高度に要求される。

【００１３】近年では、計算機システムのダウンサイジ
ングに伴って、従来は耐障害性を要求されないような分
野にしか使用されていなかった各種のシステムが、高度
の耐障害性が要求される分野においても利用されるよう
になってきている。例えば、小型計算機に多く利用され
ているＵＮＩＸのファイルシステムなどは、耐障害性を
考慮していないファイル記憶装置であるが、高度の耐障
害性が要求される分野でも利用されるようになってきて
いる。このため、耐障害性の向上は重要な課題である。

【００１４】ファイルの喪失を防ぎ、耐障害性を向上さ
せる手法の代表的なものは、ミラーリングと分散ファイ
ルシステム(Distributed File System) である。ミラー
リングは、単一のコンピュータに複数のドライブを接続
し、各ドライブに全く同じデータを書き込む技術であ
る。また、分散ファイルシステムは、コンピュータに３
台以上のドライブを接続し、同一内容のファイルを常に
２台以上のドライブ上に格納しておくシステムである。
このように、同一内容のデータを複数のドライブに格納
してファイルを多重化しておけば、一部のドライブが故
障しても、残りのドライブに残ったファイルを用いて業
務やファイルの復旧が可能である。

【００１５】しかし、ファイルの多重化にも次のような
問題点が残る。その問題点は、複数のドライブでデータ
が「書きかけ」の状態が同時に発生し得ることである。
なぜならば、従来は、複数のドライブへの書き込みが同
時に起こり得たからである。また、従来、ドライブのブ
ロックを更新するバッファブロックの単位は、ドライブ
のファイルへの操作の単位とは無関係に行われていたか
らである。

【００１６】例えば、単一の操作で、２つのドライブに
おいて、それぞれ２つずつのバッファブロックを操作す
る場合、双方のドライブで１つのブロックのみが更新さ
れ、他方のブロックが更新されていない状態がしばしば
発生した。特に不運な状態は、同じファイルがある全て
のドライブにおいて「書きかけ」での故障が起きること
である。この場合は、同一内容の複数のファイル全てが
失われる。このため、全てのファイルの喪失の危険性を
なくし、ファイルシステムの信頼性を向上させることが
必要であった。

【００１７】本発明は、上記のような従来技術の問題点
を解決するために提案されたものであり、その目的は、
信頼性の高いファイルシステムを提供することである。
さらに具体的な目的は、「書きかけ」によるブロック間
の矛盾が生じにくいファイルシステムを提供することで
ある。また、他の具体的な目的は、ドライブの故障の場
合でも、同一内容の複数のファイルのうち少なくとも１
つは失われないファイルシステムを提供することであ
る。

【００１８】また、本発明の他の目的は、効率的にデー
タを処理するファイルシステムを提供することである。
また、本発明の他の目的は、単純な構成のファイルシス
テムを提供することである。また、本発明の他の目的
は、故障の影響が局限され他の部分に及びにくいファイ
ルシステムを提供することである。また、本発明の他の
目的は、信頼性が高く、かつ、従来のファイルシステム
に導入が容易なファイルシステムを提供することであ
る。

【００１９】

【課題を解決するための手段】上記の目的を達成するた
め、請求項１のファイルシステムは、不揮発性の記憶装
置のドライブを１又は２以上有し、各ドライブの記録媒
体上にアクセス単位であるブロックが複数設けられ、揮
発性メモリ上のバッファに前記各ブロックに書き込むべ
きデータであるバッファブロックを一時的に格納するバ
ッファ手段と、バッファブロックによる記録媒体の更新
の必要性を判断する判断手段と、前記更新が必要と判断
されたときに、全てのバッファブロックによってドライ
ブのブロックを連続して更新する更新手段と、を有する
ことを特徴とする。

【００２０】また、請求項２，１８の発明は、それぞれ
請求項１，１５記載のファイルシステムにおいて、前記
判断手段は、単一の操作に基づく新たなデータをバッフ
ァに書き込もうとする場合に、新たなデータのための余
地がバッファ上に存在するか否かを調査し、余地が存在
しない場合に、前記更新が必要と判断するように構成さ
れたことを特徴とする。

【００２１】また、請求項３，１９の発明は、それぞれ
請求項１，１５記載のファイルシステムにおいて、各ド
ライブにおける前記更新の時間的重複を回避して更新を
逐次化する逐次化手段を有することを特徴とする。

【００２２】また、請求項４，２０の発明は、それぞれ
請求項３，１９記載のファイルシステムにおいて、前記
逐次化手段は、一のドライブにおいて前記更新をしよう
とする際に他の更新中のドライブが存在するか否かを調
査し、他の更新中のドライブが存在する場合は前記一の
ドライブにおける更新を抑止し、他の更新中のドライブ
が存在しない場合は前記位置のドライブにおける更新を
行うように構成されたことを特徴とする。

【００２３】また、請求項５，２１の発明は、それぞれ
請求項４，２０記載のファイルシステムにおいて、前記
逐次化手段は、更新中のドライブが存在した場合は所定
時間待機後に再度調査を行い、更新中のドライブが存在
しなくなった場合に更新を行うように構成されたことを
特徴とする。

【００２４】また、請求項６，２２の発明は、それぞれ
請求項５，２１記載のファイルシステムにおいて、前記
逐次化手段は、前記調査中のドライブを検出した場合に
も所定時間待機し、更新中の待機の時間と調査中の待機
の時間とは各々別個独立に設定できるように構成された
ことを特徴とする。

【００２５】また、請求項７，２３の発明は、それぞれ
請求項４，２０記載のファイルシステムにおいて、前記
逐次化手段は、各ドライブの状態を示すフラグをドライ
ブの状態に応じて「更新中」、「調査中」及びそれ以外
の状態にセットし、更新しようとするときに他のドライ
ブのフラグを調査するように構成されたことを特徴とす
る。

【００２６】また、請求項８，２４の発明は、それぞれ
請求項３，１９記載のファイルシステムにおいて、前記
逐次化手段は、各ドライブの各々に個別に設けられたこ
とを特徴とする。

【００２７】また、請求項９，２５の発明は、それぞれ
請求項８，２４記載のファイルシステムにおいて、前記
各逐次化手段は、通信回線を経由して他のドライブの状
態に関する情報を収集することによって前記調査を行う
ように構成されたことを特徴とする。

【００２８】また、請求項１０，２６の発明は、それぞ
れ請求項８，２４記載のファイルシステムにおいて、前
記逐次化手段は、各ドライブのフラグを他の全てのドラ
イブに控えとして転送・コピーし、他のドライブではこ
の控えのフラグを参照することによって前記調査を行う
ように構成されたことを特徴とする。

【００２９】また、請求項１１，２７の発明は、それぞ
れ請求項３，１９記載のファイルシステムにおいて、前
記逐次化手段は、各ドライブの更新を所定のクロックに
基づいて所定の各時間的サイクル内に制限することによ
って前記逐次化を行うように構成されたことを特徴とす
る。

【００３０】また、請求項１２，２８の発明は、それぞ
れ請求項３，１９記載のファイルシステムにおいて、複
数のドライブを有し、各ファイルが複数のドライブ上に
記録されたことを特徴とする。

【００３１】また、請求項１３，２９の発明は、それぞ
れ請求項１，１５記載のファイルシステムにおいて、前
記各ドライブがそれぞれ別個独立のディスク装置であ
り、各媒体が各ディスク装置の記録ディスクであること
を特徴とする。

【００３２】また、請求項１４，３０の発明は、それぞ
れ請求項１，１５記載のファイルシステムにおいて、前
記各ドライブが単一のディスク装置内に設けられた各パ
ーティションであることを特徴とする。

【００３３】また、請求項１５のファイルシステムは、
不揮発性の記憶装置のドライブを１又は２以上有し、各
ドライブの記録媒体上にアクセス単位であるブロックが
複数設けられ、揮発性メモリ上のバッファに前記各ブロ
ックに書き込むべきデータであるバッファブロックをド
ライブへの単一の操作ごとに、一時的に格納するバッフ
ァ手段と、バッファブロックによる記録媒体の更新の必
要性を判断する判断手段と、前記更新が必要と判断され
たときに、少なくとも前記単一の操作ごとの１または２
以上のバッファブロックによってドライブのブロックを
連続して更新する更新手段と、を有することを特徴とす
る。

【００３４】また、請求項１６の発明は、請求項１５記
載のファイルシステムにおいて、前記バッファ手段は、
操作と、各操作が対象とする各バッファブロックを識別
情報を用いて記録するように構成され、前記更新手段
は、前記識別情報に基づいて、単一の操作に対応する全
てのバッファブロックを単位として前記更新を行うよう
に構成されたことを特徴とする。

【００３５】また、請求項１７の発明は、請求項１６記
載のファイルシステムにおいて、前記更新手段は、複数
の操作の対象に同一のバッファブロックが含まれる場
合、それら複数の操作に係る全てのバッファブロックを
連続して更新するように構成されたことを特徴とする。

【００３６】

【作用】請求項１の発明では、媒体の更新の際に、全て
のバッファブロックによる更新が連続して行われるの
で、「書きかけ」の状態が更新最中のみに限定され、更
新と更新の間にはファイルのブロック間の不整合が発生
しない。このため、更新中以外の瞬間にドライブが故障
してもファイル内の各ブロック間の整合性は失われな
い。また、請求項１の発明では、バッファ上の更新を全
てのバッファブロックによって行うので、操作ごとのバ
ッファブロックを峻別して扱う繁雑な処理が不要にな
る。また、請求項１の発明では、全てのバッファブロッ
クによる更新を一度に行うことから、更新をＣＰＵの負
荷が低い時に行っておけば、ＣＰＵの負荷が高いときに
更新が必要となる可能性を低減させることができる。

【００３７】請求項２，１８の発明では、新たなデータ
の書き込み前に余地の有無を判断するので、単一の操作
に係る複数のバッファブロックの途中までで更新がされ
る状態が回避できる。すなわち、ブロックの書き込みご
とに順次余地を判断すると、操作に対応する複数のブロ
ックの一部のみがバッファに存在する状態で更新が行わ
れ、書きかけの状態になるが、請求項２の発明ではこの
事態が避けられる。

【００３８】請求項３，１９の発明では、逐次化手段が
更新のタイミングをずらすので、複数のドライブで「書
きかけ」の状態が同時に発生することがない。このた
め、複数のドライブのデータが同時に失われることがな
く、少なくとも１つのドライブにデータが残る。

【００３９】請求項４，２０の発明では、逐次化手段
が、更新ごとに毎回調査し他の更新中のドライブを検出
することによって更新の時間的重複を避けるので、確実
な逐次化を行うことができる。また、請求項４の発明は
更新開始の制御を逐次化手段に与えることによって実現
でき、更新自体を行うハードウェアや手順は従来通りの
ものが利用できるので従来の設備が有効活用できる。

【００４０】請求項５，２１の発明では、逐次化手段が
所定時間待機することによって逐次化を実現するので、
更新のタイミングを割り振るスーパーバイザは不必要で
ある。

【００４１】請求項６，２２の発明では、更新中の待機
の時間と調査中の待機の時間とをドライブの特性に合わ
せて自由に設定できるので、全体の処理を効率化でき
る。

【００４２】請求項７，２３の発明では、各ドライブの
ハードウェアが異なっても逐次化手段は他のドライブの
フラグさえ参照すれば更新中や調査中のドライブを検出
することができる。また、各ドライブに逐次化手段を備
える場合は更新しようとする側がフラグを参照する。こ
のため、各ドライブを制御する上位のスーパーバイザを
備える必要がない。

【００４３】請求項８，２４の発明では、逐次化手段が
各ドライブに分散しているので、故障したドライブがあ
っても他のドライブは影響を受けない。また、逐次化手
段がドライブを制御する上位のスーパーバイザとして構
成されている場合は逐次化手段の故障によって各ドライ
ブでの処理が停止するが、請求項８の発明によれば、こ
のような停止を回避することができる。

【００４４】請求項９，２５の発明では、通信回線さえ
あれば逐次化手段がこの通信回線を用いて調査を行うの
で、フラグやスーパーバイザは不要となる。

【００４５】請求項１０，２６の発明では、各ドライブ
の逐次化手段は、調査の度に他のドライブの状態や他の
ドライブに設けられたフラグを通信回線で参照する必要
がなくなるので、更新時の処理が高速化される。

【００４６】請求項１１，２７の発明では、各ドライブ
での更新の機会が所定のサイクルで確実に与えられ、特
定のドライブでの更新が他のドライブでの更新の連続に
よって遅延する場合がなくなる。

【００４７】請求項１２，２８の発明は、いわゆる分散
ファイルシステムであり、この発明では、通常、各ドラ
イブごとにどのファイルが存在するかが異なる。このた
め、各ドライブのバッファが一杯になるタイミングが分
散し、ドライブ更新のための待ち時間が減少する。すな
わち、ミラーリングのように、全てのドライブの内容が
同一の場合は、複数のドライブに対する書き込みのタイ
ミングが時間的に競合するので、無駄な待ち時間が発生
するが、本発明ではそのような待ち時間の発生が減少す
る。

【００４８】請求項１３，２９の発明では、単一のディ
スクを論理的な複数のドライブとみなすパーティション
と比べ、単一のドライブの故障によって複数のファイル
が失われる可能性を一層低減できる。

【００４９】請求項１４，３０の発明では、物理的には
複数のドライブが不要であるから信頼性に優れたファイ
ルシステムが単純なハードウェア構成で廉価に実現でき
る。

【００５０】請求項１５の発明では、媒体の更新の際
に、ドライブへの単一の操作が対象とする１又は２以上
のバッファブロックによる更新が連続して行われるの
で、「書きかけ」の状態が更新最中のみに限定され、更
新と更新の間にはファイルのブロック間の不整合が発生
しない。このため、更新中以外の瞬間にドライブが故障
してもファイル内の各ブロック間の整合性は失われな
い。

【００５１】また、更新を常に全てのバッファブロック
で行う場合と比べ、１回当たりの更新所要時間が短縮さ
れるので、更新のために他の処理を待たせる可能性が軽
減される。

【００５２】請求項１６の発明では、各操作とバッファ
ブロックについて、コード番号のような識別情報を記録
しておくことによって容易に対応関係を特定できるの
で、特殊なデータ構造を用いずに、単純な構成で操作単
位の更新が実現できる。

【００５３】請求項１７の発明では、複数の操作が同一
のブロックを対象とした場合、そのうち一部の操作の内
容のみによって当該ブロックが更新されることがないの
で、他の操作の対象としてのブロック間の整合性を喪失
することがない。

【００５４】

【実施例】次に、本発明の実施例について図面に従って
具体的に説明する。なお、後述する実施例はコンピュー
タ上に実現され、実施例の各機能は所定の手順（プログ
ラム）がこのコンピュータを制御することで実現され
る。

【００５５】本明細書における各「手段」は実施例の各
機能に対応する概念的なもので、必ずしも特定のハード
ウェアやソフトウェア・ルーチンに１対１には対応しな
い。同一のハードウェア要素が場合によって異なった手
段を構成する。例えば、コンピュータはある命令を実行
するときにある手段となり別の命令を実行するときは別
の手段となりうる。また、一つの手段がわずか１命令に
よって実現される場合もあれば多数の命令によって実現
される場合もある。

【００５６】したがって、本明細書では、以下、実施例
の各機能を有する仮想的回路ブロック（手段）を想定し
て実施例を説明する。但し、コンピュータの使用は一例
であり、本発明の機能の全部又は一部は、可能ならば、
カスタムチップ（専用の集積回路）のような電子回路上
に実現してもよい。

【００５７】実施例に用いられるコンピュータは、一般
には、ＣＰＵ（中央演算処理装置）と、ＲＡＭ（随時書
込読出型記憶素子）からなる主記憶装置とを有する。ま
た、前記コンピュータの規模は自由であり、マイクロコ
ンピュータ・パーソナルコンピュータ・スモールコンピ
ュータ・ワークステーション・メインフレームなど、い
かなる規模のものを用いてもよい。

【００５８】また、前記コンピュータのハードウェア
は、典型的には、キーボードやマウスなどの入力装置
と、ハードディスク装置などの外部記憶装置と、ＣＲＴ
表示装置やプリンタ印字装置などの出力装置と、必要な
入出力制御回路を含む。

【００５９】但し、前記コンピュータのハードウェア構
成は自由であり、本発明が実施できる限り、上記の構成
要素の一部を追加・変更・除外してもよい。例えば、実
施例は、複数のコンピュータを接続したコンピュータネ
ットワーク上に実現してもよい。また、ＣＰＵの種類は
自由であり、ＣＰＵを複数同時に用いたり、単一のＣＰ
Ｕをタイムシェアリング（時分割）で使用し、複数の処
理を同時平行的に行ってもよい。

【００６０】また、他の入力装置（例えば、タッチパネ
ル・ライトペン・トラックボールなどのポインティング
デバイスや、デジタイザ・イメージ読取装置やビデオカ
メラなどの画像入力装置・音声識別装置・各種センサな
ど）を用いてもよい。また、他の外部記憶装置（例え
ば、フロッピーディスク装置・ＲＡＭカード装置・磁気
テープ装置・光学ディスク装置・光磁気ディスク装置・
バブルメモリ装置・フラッシュメモリなど）を用いても
よい。また、他の出力装置（例えば、液晶表示装置・プ
ラズマディスプレイ装置・ビデオプロジェクター・ＬＥ
Ｄ表示装置・音響発生回路・音声合成回路など）を用い
てもよい。

【００６１】また、前記コンピュータにおいて実施例を
実現するためのソフトウェアの構成としては、典型的に
は、実施例の各機能を実現するためのアプリケーション
プログラムが、ＯＳ（オペレーティングシステム）上で
実行される態様が考えられる。また、実施例を実現する
ためのプログラムの態様としては、典型的には、高級言
語やアセンブラからコンパイル（翻訳）された機械語が
考えられる。但し、前記コンピュータのソフトウェア構
成も自由であり、本発明が実施できる限り、ソフトウェ
ア構成を変更してもよい。例えば、必ずしもＯＳを用い
る必要はなく、また、プログラムの表現形式も自由であ
り、ＢＡＳＩＣのようなインタプリタ（逐次解釈実行
型）言語を用いてもよい。

【００６２】また、プログラムの格納態様も自由であ
り、ＲＯＭ（読出し専用メモリ）に格納しておいてもよ
く、また、ハードディスク装置のような外部記憶装置に
格納しておき、コンピュータの起動時や処理の開始時に
主メモリ上にロード（読み込み）してもよい。また、プ
ログラムを複数の部分に分割して外部記憶装置に格納し
ておき、処理内容に応じて必要なモジュールのみを随時
主メモリ上にロード（読み込み）してもよい。さらに、
プログラムの部分ごとに異なった態様で格納してもよ
い。

【００６３】また、本実施例における各手順の各ステッ
プは、その性質に反しない限り、実行順序を変更し、複
数同時に実行し、また、実行ごとに異なった順序で実行
してもよい。このような順序の変更は、例えば、ユーザ
が実行可能な処理を選択するなどメニュー形式のインタ
ーフェース手法によって実現することができる。

【００６４】また、本明細書における「入力」は、本来
の情報の入力のみならず、情報の入力と密接に関連する
他の処理を含む。このような処理は、例えば、入力内容
のエコーバックや修正・編集である。また、本明細書に
おける「出力」は、本来の情報の出力のみならず、情報
の出力と密接に関連する他の処理を含む。このような処
理は、例えば、出力すべき範囲の入力や、画面スクロー
ルの指示である。なお、対話的入出力手順によって入力
と出力を一体的操作によって実現してもよく、このよう
な一体的操作によって、選択・指定・特定などの処理を
行ってもよい。

【００６５】また、本明細書におけるデータ（情報）や
データの格納手段は前記コンピュータ上においていかな
る態様で存在してもよい。例えば、データのハードウェ
ア上の所在部分は、主記憶装置・外部記憶装置・ＣＰＵ
のレジスタやキャッシュメモリなどいかなる部分でもよ
い。また、データの保持態様も自由である。例えば、デ
ータは、ファイル形式で保持されるのみならず、メモリ
やディスクなどの記憶装置を物理的アドレスで直接アク
セスすることによって実現してもよい。また、データの
表現形式も自由で、例えば、文字列を表すコードの単位
は、文字単位でも単語単位でもよい。また、データは必
要とされる一定時間だけ保持されれば十分で、その後消
滅してもよく、保持時間の長短は自由である。また、辞
書データのように当面変更されない情報は、ＲＯＭに格
納してもよい。

【００６６】また、本明細書において、特定の情報への
言及は確認的で、言及されない情報の存在を否定するも
のではない。すなわち、本発明の動作では、動作に必要
な一般的な情報、例えば、各種ポインタ、カウンタ、フ
ラグ、パラメータ、バッファなどが適宜用いられる。

【００６７】実施例の各部分が処理に要する情報は、特
に記載がない場合、当該情報を保持している他の部分か
ら獲得される。このような情報の獲得は、例えば、当該
情報を格納している変数やメモリをアクセスすることに
よって実現することができる。なお、情報の消去・抹消
は、当該情報の内容自体を必ずしも記憶領域から現実に
削除せず、消去を表すフラグを設定するなど、情報の意
味付けの変更によって行うことができる。

【００６８】１．第１実施例の構成 第１実施例は請求項１〜８，１２，１３に対応する分散
ファイルシステムで、図１は第１実施例の構成要素を示
す構成図である。この場合、図１に示すシステムは、複
数のファイル記憶装置１Ｓ，２Ｓ，…，ｎＳ（ｎは２以
上の任意の整数）と、これらの複数のファイル記憶装置
１Ｓ，２Ｓ，…，ｎＳを連結する共通のシステムバス１
０とによって構成されている。なお、各ファイル記憶装
置１Ｓ，２Ｓ，…，ｎＳは、請求の範囲にいうドライブ
に相当する。

【００６９】ファイル記憶装置１Ｓは、フラッシュ逐次
化手段１Ａ（請求の範囲にいう逐次化手段に相当す
る）、フラッシュ状態フラグ１Ｂ（請求の範囲にいうフ
ラグに相当する）、バッファ管理手段（バッファフラッ
シュ手段）１Ｃ、ディスクバッファ１Ｄ、およびディス
ク１Ｅを有する。なお、ディスク１Ｅは、請求の範囲に
いう記録媒体に相当する。また、バッファ管理手段１Ｃ
及びディスクバッファ２Ｄは、請求の範囲にいうバッフ
ァ手段を構成する。また、バッファ管理手段１Ｃは、請
求の範囲にいう判断手段及び更新手段としての役割も果
たす。なお、本実施例において「フラッシュ」とは、バ
ッファ上の全てのブロックによってドライブのブロック
を更新する処理である。

【００７０】このうち、フラッシュ逐次化手段１Ａは、
バッファ管理手段１Ｃからのフラッシュ開始要求に応答
して、フラッシュ状態フラグ１Ｂを「調査中」にし、他
のファイル記憶装置のフラッシュ状態フラグを調べる
（請求項４）。そして、このフラッシュ逐次化手段１Ａ
は、他のファイル記憶装置中に「調査中」や「実行中」
のフラグがない場合には、フラッシュ状態フラグ１Ｂを
「更新中（実行中）」にし、要求元のバッファ管理手段
１Ｃにフラッシュ開始許可を返す。また、フラッシュ状
態フラグ１Ｂは、ファイル記憶装置１Ｓのフラッシュ状
態を示すフラグであり、前述のように、フラッシュ逐次
化手段１Ａによる調査時またはフラッシュ管理手段１Ｃ
によるフラッシュ処理時には、フラッシュ逐次化手段１
Ａによって「調査中」または「更新中（実行中）」とさ
れ、それ以外の場合には「通常」とされる。

【００７１】一方、バッファ管理手段１Ｃは、ファイル
記憶装置１Ｓに対する外部からの操作要求に応答して、
フラッシュ逐次化手段１Ａにフラッシュ開始要求を送
る。そして、このバッファ管理手段１Ｃは、前述のよう
に、フラッシュ逐次化手段１Ａからフラッシュ開始許可
を受け取ると、それに応答して、ディスクバッファ１Ｄ
内の将来的に更新必要性のある全データにより、ディス
ク１Ｅを更新する。

【００７２】次に、ファイル記憶装置２Ｓは、フラッシ
ュ逐次化手段２Ａ、フラッシュ状態フラグ２Ｂ、バッフ
ァ管理手段（バッファフラッシュ手段）２Ｃ、ディスク
バッファ２Ｄ、およびディスク２Ｅを有する。これらの
構成要素２Ａ〜２Ｅも、ファイル記憶装置１Ｓの構成要
素１Ａ〜１Ｅと全く同様に構成されている。同様に、第
ｎ番目のファイル記憶装置ｎＳは、フラッシュ逐次化手
段ｎＡ、フラッシュ状態フラグｎＢ、バッファ管理手段
（バッファフラッシュ手段）ｎＣ、ディスクバッファｎ
Ｄ、およびディスクｎＥを有し、これらの構成要素ｎＡ
〜ｎＥも、ファイル記憶装置１Ｓの構成要素１Ａ〜１Ｅ
と全く同様に構成されている。

【００７３】なお、図２は図１のシステムの具体的な構
成の一例を示す概念図であり、ファイル記憶装置１Ｓ
は、ＣＰＵ（１Ｆ）、ＲＯＭ（１Ｇ）、ＲＡＭ（１
Ｈ）、ＳＣＳＩ（１Ｉ）、ディスク１Ｅ、およびローカ
ルバス１Ｊによって構成されており、ＲＯＭ（１Ｇ）お
よびＲＡＭ（１Ｈ）内に、バッファ管理手段１Ｃ、フラ
ッシュ逐次化手段１Ａ、フラッシュ状態フラグ１Ｂ、お
よびディスクバッファ１Ｄが構成されている。同様に、
ファイル記憶装置２Ｓは、ＣＰＵ（２Ｆ）、ＲＯＭ（２
Ｇ）、ＲＡＭ（２Ｈ）、ＳＣＳＩ規格インタフェース回
路（２Ｉ）、ディスク２Ｅ、およびローカルバス２Ｊに
よって構成されており、ＲＯＭ（２Ｇ）およびＲＡＭ
（２Ｈ）内に、バッファ管理手段２Ｃ、フラッシュ逐次
化手段２Ａ、フラッシュ状態フラグ２Ｂ、およびディス
クバッファ２Ｄが構成されている。

【００７４】なお、第１実施例は、３つ以上のドライブ
を有し、各ファイルが２つ以上のドライブ上に記録され
た、いわゆる分散ファイルシステムであり（請求項１
２）、この発明では、通常、各ドライブごとにどのファ
イルが存在するかが異なる。このため、各ドライブのバ
ッファが一杯になるタイミングが分散し、ドライブ更新
のための待ち時間が減少する。ミラーリングのように、
全てのドライブの内容が同一のミラーリングにおいて逐
次化を行う場合は、複数のドライブに対する書き込みの
必要が常に同時に発生するので、無駄な待ち時間が発生
する。

【００７５】また、第１実施例では、前記各ドライブが
それぞれ別個独立のディスク装置であり、各媒体が各デ
ィスク装置の記録ディスクである（請求項１３）。この
ため、第１実施例では、単一のディスクを論理的な複数
のドライブとみなすパーティションと比べ、単一のドラ
イブの故障によって複数のファイルが失われる可能性が
除去できる。

【００７６】逆に、前記各ドライブは、単一のディスク
装置内に設けられた各パーティションでもよい（請求項
１４）。このようにすれば、複数のドライブが不要であ
るから優れたファイルシステムが単純なハードウェア構
成で廉価に実現できる。

【００７７】２．第１実施例の作用及び効果 以上のような構成を有する本実施例の分散ファイルシス
テムの作用について、図３および図４のフローチャート
を参照して以下に説明する。この場合、図３は、バッフ
ァ管理手段がブロックの書き込み要求（更新要求）を受
け取った場合の処理手順を示すフローチャート、図４
は、フラッシュ逐次化手段がフラッシュ開始要求を受け
取った場合の処理手順を示すフローチャートである。

【００７８】なお、ここでは、一例として、図１に示す
ファイル記憶装置１Ｓに対して、図５に示すようなブロ
ックの更新を要求する操作要求が与えられた場合の例を
説明する。そして、説明の便宜上、初期状態において、
全てのファイル記憶装置１Ｓ〜ｎＳの全てのディスク１
Ｅ〜ｎＥは、データの整合性が取れており、全てのファ
イル記憶装置１Ｓ〜ｎＳのフラッシュ状態フラグの全て
のフラッシュ状態フラグ１Ｂ〜ｎＢは、「通常」である
とする。また、ファイル記憶装置１Ｓのディスクバッフ
ァ１Ｄは、図６に示すように、その全領域が「空き」で
あるとする。

【００７９】２−１．他のファイル記憶装置が全て「通
常」である場合の処理 まず、バッファ管理手段１Ｃは、図５に示すブロック
１，２，３の更新を必要とする操作１の要求に応答し
て、図３に示すように、ディスクバッファ１Ｄ内に、書
き込みブロック数である３ブロック分の「空き」領域ま
たは更新必要性「無」の領域が存在するか否かを判断す
る（ステップ３０１／請求項２）。この場合、図６に示
すように、ディスクバッファ１Ｄ内には３ブロック分の
「空き」領域があるため、この３ブロック分の「空き」
領域の各々に、書き込みブロック１，２，３のブロック
アドレスとデータ内容を格納し、更新必要性を「有」に
する（ステップ３０６）。その結果、ディスクバッファ
１Ｄの内容は、図７に示すようになる。この処理の途中
では、ディスク１Ｅの更新は行われないので、ディスク
１Ｅ内のデータの整合性は依然として保たれている。な
お、ディスクバッファ内のブロックごとのデータ内容が
請求の範囲にいうバッファブロックに対応する。

【００８０】次に、バッファ管理手段１Ｃは、図５に示
すブロック４，５，６の更新を必要とする操作２の要求
に応答して、図３に示すように、ディスクバッファ１Ｄ
内に、書き込みブロック数である３ブロック分の「空
き」領域または更新必要性「無」の領域が存在するか否
かを判断する（ステップ３０１）。この場合、図７に示
すように、ディスクバッファ１Ｄ内には３ブロック分の
「空き」領域があるため、この３ブロック分の「空き」
領域の各々に、書き込みブロック４，５，６のブロック
アドレスとデータ内容を格納し、更新必要性を「有」に
する（ステップ３０６）。その結果、ディスクバッファ
１Ｄの内容は、図８に示すようになる。この処理の途中
では、ディスク１Ｅの更新は行われないので、ディスク
１Ｅ内のデータの整合性は依然として保たれている。

【００８１】続いて、バッファ管理手段１Ｃは、図５に
示すブロック７，８，９の更新を必要とする操作３の要
求に応答して、図３に示すように、ディスクバッファ１
Ｄ内に、書き込みブロック数である３ブロック分の「空
き」領域または更新必要性「無」の領域が存在するか否
かを判断する（ステップ３０１）。この場合、図８に示
すように、ディスクバッファ１Ｄ内には３ブロック分の
「空き」領域または更新必要性「無」の領域がないた
め、バッファ管理手段１Ｃは、フラッシュ逐次化手段１
Ａにフラッシュ開始要求を送り（ステップ３０２）、フ
ラッシュ逐次化手段１Ａからのフラッシュ開始許可を待
つ（ステップ３０３）。

【００８２】また、フラッシュ逐次化手段１Ａは、バッ
ファ管理手段１Ｃからのフラッシュ開始要求に応答し
て、図４に示すように、フラッシュ状態フラグ１Ｂを
「調査中」にし（ステップ４０１／請求項７）、他のフ
ァイル記憶装置２Ｓ，…，ｎＳのフラッシュ状態フラグ
２Ｂ，…，ｎＢを調べ（ステップ４０２）、「調査中」
または「更新中（実行中）」のファイル記憶装置が存在
するか否かを判断する（ステップ４０３）。この時、他
のいずれのファイル記憶装置２Ｓ，…，ｎＳも「調査
中」または「更新中（実行中）」でなければ、フラッシ
ュ逐次化手段１Ａは、フラッシュ状態フラグ１Ｂを「更
新中（実行中）」にして、要求元のバッファ管理手段１
Ｃにフラッシュ開始許可を返し（ステップ４０５）、バ
ッファ管理手段１Ｃからのフラッシュ終了通知を待つ
（ステップ４０６）。

【００８３】なお、ここまでの処理で、ファイル記憶装
置１Ｓのディスク１Ｅは初期状態から全く更新されてい
ないため、このディスク１Ｅ上のデータの整合性は依然
として保たれたままである。

【００８４】さらに、バッファ管理手段１Ｃは、フラッ
シュ逐次化手段１Ａからのフラッシュ開始許可に応答し
て、ディスクバッファ１Ｄ内の更新必要性「有」の全領
域の全データにより、ディスクバッファ１Ｄのフラッシ
ュ処理を行う（ステップ３０４）。すなわち、ここで
は、更新必要性「有」の領域に格納されたブロック１，
２，３，４，５，６のブロックアドレスとデータ内容に
よって、ディスク１Ｅを更新して、これらの６ブロック
分の領域をディスク更新必要性「無」に変更する。

【００８５】このフラッシュ処理の途中において、ディ
スク１Ｅのブロック１，２，３の一部、またはブロック
４，５，６の一部のみを更新した状態では、１つの操作
で更新しなくてはならない複数のブロックの全てを更新
した状態でないため、この時点ではディスク１Ｅ上のデ
ータの整合性は取られていないが、この６ブロック分の
全データによってディスク１Ｅの対象ブロック１，２，
３，４，５，６を更新し終わった時点では、再びディス
ク１Ｅ上のデータの整合性が取られている。このフラッ
シュ処理の後、バッファ管理手段１Ｃは、フラッシュ逐
次化手段１Ａにフラッシュ終了通知を送る（ステップ３
０５）。そして、フラッシュ逐次化手段１Ａは、バッフ
ァ管理手段１Ｃからのフラッシュ終了通知を受け取る
と、図４に示すように、フラッシュ状態フラグ１Ｂを
「通常」に戻す（ステップ４０７）。

【００８６】バッファ管理手段１Ｃは引き続き、ディス
クバッファ１Ｄの「空き」または更新必要性が「無」の
領域の３ブロック分の領域の各々に、書き込みブロック
７，８，９のブロックアドレスとデータ内容を格納し、
更新必要性を「有」にする（ステップ３０６）。その結
果、ディスクバッファ１Ｄの内容は、図９に示すように
なる。しかし、この場合にはディスク１Ｅは更新されな
いため、依然としてディスク１Ｅ上のデータの整合性は
保たれている。

【００８７】このように、本実施例のファイル記憶装置
１Ｓにおいて、ディスク１Ｅ上のデータの整合性が崩れ
るのは、ディスクバッファ１Ｄのフラッシュ処理を行っ
ている時、すなわち、フラッシュ状態フラグ１Ｂが「更
新中（実行中）」になっている時のみである。

【００８８】２−２．他のファイル記憶装置のいずれか
が「調査中」または「更新中（実行中）」である場合の
処理 一方、例えば、ファイル記憶装置２Ｓがフラッシュ処理
を行っている最中には、このファイル記憶装置２Ｓのフ
ラッシュ状態フラグ２Ｂは「更新中（実行中）」にな
る。この状態で、ファイル記憶装置１Ｓのフラッシュ逐
次化手段１Ａがフラッシュ開始要求を受け取った場合に
は、このフラッシュ逐次化手段１Ａは、図４に示すよう
に、フラッシュ状態フラグ１Ｂを「調査中」にし（ステ
ップ４０１）、他のファイル記憶装置２Ｓ，…，ｎＳの
フラッシュ状態フラグ２Ｂ，…，ｎＢを調べ（ステップ
４０２）、「調査中」または「更新中（実行中）」のフ
ァイル記憶装置が存在すると判断する（ステップ４０
３）。続いて、フラッシュ逐次化手段１Ａは、フラッシ
ュ状態フラグ１Ｂを「通常」にして一定時間待機する
（ステップ４０４／請求項５，６）。

【００８９】そして、一定時間後、このフラッシュ逐次
化手段１Ａは、再び、図４に示すように、フラッシュ状
態フラグ１Ｂを「調査中」にし（ステップ４０１）、他
のファイル記憶装置２Ｓ，…，ｎＳのフラッシュ状態フ
ラグ２Ｂ，…，ｎＢを調べ（ステップ４０２）、「調査
中」または「更新中（実行中）」のファイル記憶装置が
あるか否かを判断する（ステップ４０３）。この場合、
さらにファイル記憶装置２Ｓが「更新中（実行中）」で
あれば、フラッシュ逐次化手段１Ａは、フラッシュ状態
フラグ１Ｂを「通常」にして、再び、一定時間待機する
ことになる。

【００９０】これに対して、フラッシュ逐次化手段１Ａ
が待機している間に、ファイル記憶装置２Ａでフラッシ
ュ処理が終了し、フラッシュ状態フラグ２Ｂが「通常」
に戻り、「調査中」または「更新中（実行中）」のファ
イル記憶装置がないと判断した場合には、フラッシュ逐
次化手段１Ａは、フラッシュ状態フラグ１Ｂを「更新中
（実行中）」にして、要求元のバッファ管理手段１Ｃに
フラッシュ開始許可を返し（ステップ４０５）、バッフ
ァ管理手段１Ｃからのフラッシュ終了通知を待つ（ステ
ップ４０６）。最終的に、このフラッシュ逐次化手段１
Ａは、バッファ管理手段１Ｃからのフラッシュ終了通知
を受け取った時点で、フラッシュ状態フラグ１Ｂを「通
常」に戻す（ステップ４０７）。

【００９１】このように、第１実施例において、１つの
ファイル記憶装置１Ｓでフラッシュ処理を行おうとする
場合には、フラッシュ逐次化手段１Ａの作用により、他
のファイル記憶装置が、フラッシュ処理のための「調査
中」またはフラッシュ処理の「更新中（実行中）」であ
る場合に、バッファ管理手段１Ｃによるフラッシュ処理
の実行を一定時間の間制止し、「調査中」または「更新
中（実行中）」のファイル記憶装置がなくなった時点で
初めてバッファ管理手段１Ｃにフラッシュ開始許可を返
して、ディスクバッファ１Ｄのフラッシュ処理を行わせ
ることになる。したがって、同時に２つ以上のファイル
記憶装置がフラッシュ処理を行うことがない。

【００９２】以上説明したように、第１実施例におい
て、ディスク１Ｅ上のデータの整合性が崩れるのは、デ
ィスクバッファ１Ｄのフラッシュ処理を行っている時、
すなわち、フラッシュ状態フラグ１Ｂが「更新中（実行
中）」になっている時のみであり、また、同時に２つ以
上のファイル記憶装置がフラッシュ処理を行うことがな
いため、同時に２つ以上のファイル記憶装置がディスク
上におけるデータの整合性を失ってしまうことはない。
したがって、仮に、複数のあるいは全部のファイル記憶
装置が同時に障害によってダウンした場合であっても、
２重以上に多重化されて複数のファイル記憶装置に保存
されたファイルのデータは、少なくとも１つのファイル
記憶装置に確実に保存されていることになる。

【００９３】特に、第１実施例では、逐次化手段が、更
新ごとに毎回他の更新中のドライブを検出することによ
って更新の時間的重複を避けるので、確実な逐次化を行
うことができる。また、第１実施例では、更新開始の制
御を逐次化手段に与えることによって信頼性の高いファ
イルシステムを実現でき、更新自体を行うハードウェア
や手順は従来通りのものが利用できるので従来の設備が
有効活用できる。すなわち、従来のファイルシステムに
本発明を適用する際、ハードウェアやＢＩＯＳ(Basic I
nput/Output System) などディスクにアクセスするため
の基本的な制御手順のみ変更すれば、ファイルシステム
の論理的制御手順を変える必要がない（図１０）。

【００９４】３．第２実施例 第２実施例は、請求項１６，１７に対応する分散ファイ
ルシステムである。第２実施例の構成は大部分第１実施
例と同様である。

【００９５】第２実施例では、前記バッファ手段は、操
作と、各操作が対象とする各バッファブロックを識別情
報を用いて記録するように構成され、前記更新手段は、
前記識別情報に基づいて、単一の操作に対応する全ての
バッファブロックを単位として前記更新を行うように構
成されている。また、第２実施例では、前記更新手段
は、複数の操作の対象に同一のバッファブロックが含ま
れる場合、それら複数の操作に係る全てのバッファブロ
ックを連続して更新するように構成されている。例え
ば、操作内容をバッファに記録するごとに、操作番号と
対象バッファブロック番号を対照表（図１１）に記録す
る。また、ディスクバッファの所定の領域にも、各バッ
ファブロックを操作対象とした操作番号を記録する。バ
ッファブロック毎の操作番号を記録する（図１２）。例
えば、図１１，図１２では、操作１でブロック１，２
が、操作２でブロック３，４が、操作３でブロック３，
５が操作されている。この場合、更新はバッファブロッ
ク１，２を一体に行うほか、操作２，３に係るバッファ
ブロック３，４，５を一体に行う。操作２に係るバッフ
ァブロック３，４のみを更新し、バッファブロック５を
更新しない状態は、操作３に基づいてみれば「書きか
け」だからである。

【００９６】このような第２実施例では、各操作とバッ
ファブロックについて、コード番号のような識別情報を
記録しておくことによって容易に対応関係を特定できる
ので、特殊なデータ構造を用いずに、単純な構成で操作
単位の更新が実現できる。

【００９７】また、第２実施例では、複数の操作が同一
のブロックを対象とした場合、そのうち一部の操作の内
容のみによって当該ブロックが更新されることがないの
で、他の操作の対象としてのブロック間の整合性を喪失
することがない。

【００９８】４．他の実施例 なお、本発明は、前記実施例に限定されるものではな
く、例えば、バッファフラッシュ手段およびフラッシュ
逐次化手段の具体的な構成や処理の流れは、自由に変更
可能である。また、これらの手段以外の各部の構成要素
やファイル記憶装置全体の構成についても、同様に自由
に変更可能であり、ファイル記憶装置の数も自由に選択
可能である。

【００９９】例えば、バッファフラッシュを行う場合
は、新たなデータを書き込む余地が不足した場合には限
定されず、バッファフラッシュの命令がユーザ又はプロ
グラムによって与えられたとき、媒体をドライブから取
り外すための命令が与えられたとき、システムを停止し
ようとするときなど、自由に決定できる。

【０１００】また、例えば、前記各逐次化手段は、通信
回線を経由して他のドライブの状態に関する情報を収集
することによって前記調査を行うように構成してもよい
（請求項９）。このような実施例では、通信回線さえあ
れば逐次化手段がこの通信回線を用いて調査を行うの
で、フラグやスーパーバイザは不要となる。

【０１０１】また、例えば、前記逐次化手段は、各ドラ
イブのフラグを他の全てのドライブに控えとして転送・
コピーし、他のドライブではこの控えのフラグを参照す
ることによって前記調査を行うように構成してもよい
（請求項１０）。このような実施例では、各ドライブの
逐次化手段は、調査の度に他のドライブの状態や他のド
ライブに設けられたフラグを通信回線で参照する必要が
なくなるので、更新時の処理が高速化される。上記のよ
うな通信やフラグの転送は、イーサネット及びＭＡＰの
ようなＬＡＮを用いて行うこともできる。

【０１０２】また、例えば、前記逐次化手段は、各ドラ
イブの更新を所定のクロックに基づいて所定の各クロッ
クサイクル内に制限することによって前記逐次化を行う
ように構成してもよい（請求項１１）。このような実施
例では、各ドライブでの更新の機会が所定のサイクルで
確実に与えられ、特定のドライブでの更新が他のドライ
ブでの更新の連続によって遅延する場合がなくなる。

【０１０３】

【発明の効果】以上のように、本発明では、更新中以外
の瞬間にドライブが故障してもファイル内の各ブロック
間の整合性は失われないので、信頼性の高いファイルシ
ステムを提供することができる。

【図面の簡単な説明】

【図１】本発明のファイルシステムの第１実施例の構成
要素を示す構成図

【図２】図１のシステムの具体的な構成の一例を示す概
念図

【図３】図１のバッファ管理手段がブロックの書き込み
要求（更新要求）を受け取った場合の処理手順を示すフ
ローチャート

【図４】図１のフラッシュ逐次化手段がフラッシュ開始
要求を受け取った場合の処理手順を示すフローチャート

【図５】図１のファイル記憶装置１Ｓに対する操作要求
の操作番号と更新対象ブロックアドレスを示す表

【図６】図１のディスクバッファ１Ｄの初期状態を示す
表

【図７】図１のディスクバッファ１Ｄの操作１終了後の
状態を示す表

【図８】図１のディスクバッファ１Ｄの操作２終了後の
状態を示す表

【図９】図１のディスクバッファ１Ｄの操作３終了後の
状態を示す表

【図１０】分散ファイルシステムのソフトウェア構成を
示す概念図であり

【図１１】第２実施例における操作履歴表

【図１２】第２実施例におけるディスクバッファの内容

【符号の説明】

１Ｓ，２Ｓ…ファイル記憶装置 １Ａ，２Ａ…フラッシュ逐次化手段 １Ｂ，２Ｂ…フラッシュ状態フラグ １Ｃ，２Ｃ…バッファ管理手段 １Ｄ，２Ｄ…ディスクバッファ １Ｅ，２Ｅ…ディスク １０…システムバス

Claims (30)

【特許請求の範囲】
1. 【請求項１】 不揮発性の記憶装置のドライブを１又は
   ２以上有し、 各ドライブの記録媒体上にアクセス単位であるブロック
   が複数設けられ、 揮発性メモリ上のバッファに前記各ブロックに書き込む
   べきデータであるバッファブロックを一時的に格納する
   バッファ手段と、 バッファブロックによる記録媒体の更新の必要性を判断
   する判断手段と、 前記更新が必要と判断されたときに、全てのバッファブ
   ロックによってドライブのブロックを連続して更新する
   更新手段と、 を有することを特徴とするファイルシステム。
2. 【請求項２】 前記判断手段は、単一の操作に基づく新
   たなデータをバッファに書き込もうとする場合に、新た
   なデータのための余地がバッファ上に存在するか否かを
   調査し、余地が存在しない場合に、前記更新が必要と判
   断するように構成されたことを特徴とする請求項１記載
   のファイルシステム。
3. 【請求項３】 各ドライブにおける前記更新の時間的重
   複を回避して更新を逐次化する逐次化手段を有すること
   を特徴とする請求項１記載のファイルシステム。
4. 【請求項４】 前記逐次化手段は、一のドライブにおい
   て前記更新をしようとする際に他の更新中のドライブが
   存在するか否かを調査し、他の更新中のドライブが存在
   する場合は前記一のドライブにおける更新を抑止し、他
   の更新中のドライブが存在しない場合は前記一のドライ
   ブにおける更新を行うように構成されたことを特徴とす
   る請求項３記載のファイルシステム。
5. 【請求項５】 前記逐次化手段は、更新中のドライブが
   存在した場合は所定時間待機後に再度調査を行い、更新
   中のドライブが存在しなくなった場合に更新を行うよう
   に構成されたことを特徴とする請求項４記載のファイル
   システム。
6. 【請求項６】 前記逐次化手段は、前記調査中のドライ
   ブを検出した場合にも所定時間待機し、更新中の待機の
   時間と調査中の待機の時間とは各々別個独立に設定でき
   るように構成されたことを特徴とする請求項５記載のフ
   ァイルシステ
7. 【請求項７】 前記逐次化手段は、各ドライブの状態を
   示すフラグをドライブの状態に応じて「更新中」、「調
   査中」及びそれ以外の状態にセットし、更新しようとす
   るときに他のドライブのフラグを調査するように構成さ
   れたことを特徴とする請求項４記載のファイルシステ
   ム。
8. 【請求項８】 前記逐次化手段は、各ドライブの各々に
   個別に設けられたことを特徴とする請求項３記載のファ
   イルシステム。
9. 【請求項９】 前記各逐次化手段は、通信回線を経由し
   て他のドライブの状態に関する情報を収集することによ
   って前記調査を行うように構成されたことを特徴とする
   請求項８記載のファイルシステム。
10. 【請求項１０】 前記逐次化手段は、各ドライブのフラ
    グを他の全てのドライブに控えとして転送・コピーし、
    他のドライブではこの控えのフラグを参照することによ
    って前記調査を行うように構成されたことを特徴とする
    請求項８記載のファイルシステム。
11. 【請求項１１】 前記逐次化手段は、各ドライブの更新
    を所定のクロックに基づいて所定の各時間的サイクル内
    に制限することによって前記逐次化を行うように構成さ
    れたことを特徴とする請求項３記載のファイルシステ
    ム。
12. 【請求項１２】 複数のドライブを有し、各ファイルが
    複数のドライブ上に記録されたことを特徴とする請求項
    ３記載のファイルシステム。
13. 【請求項１３】 前記各ドライブがそれぞれ別個独立の
    ディスク装置（磁気又は光学）であり、各媒体が各ディ
    スク装置の記録ディスクであることを特徴とする請求項
    １記載のファイルシステム。
14. 【請求項１４】 前記各ドライブが単一のディスク装置
    内に設けられた各パーティションであることを特徴とす
    る請求項１記載のファイルシステム。
15. 【請求項１５】 不揮発性の記憶装置のドライブを１又
    は２以上有し、 各ドライブの記録媒体上にアクセス単位であるブロック
    が複数設けられ、 揮発性メモリ上のバッファに前記各ブロックに書き込む
    べきデータであるバッファブロックをドライブへの単一
    の操作ごとに、一時的に格納するバッファ手段と、 バッファブロックによる記録媒体の更新の必要性を判断
    する判断手段と、 前記更新が必要と判断されたときに、少なくとも前記単
    一の操作ごとの１または２以上のバッファブロックによ
    ってドライブのブロックを連続して更新する更新手段
    と、 を有することを特徴とするファイルシステム。
16. 【請求項１６】 前記バッファ手段は、操作と、各操作
    が対象とする各バッファブロックを識別情報を用いて記
    録するように構成され、 前記更新手段は、前記識別情報に基づいて、単一の操作
    に対応する全てのバッファブロックを単位として前記更
    新を行うように構成されたことを特徴とする請求項１５
    記載のファイルシステム。
17. 【請求項１７】 前記更新手段は、複数の操作の対象に
    同一のバッファブロックが含まれる場合、それら複数の
    操作に係る全てのバッファブロックを連続して更新する
    ように構成されたことを特徴とする請求項１６記載のフ
    ァイルシステム。
18. 【請求項１８】 前記判断手段は、単一の操作に基づく
    新たなデータをバッファに書き込もうとする場合に、新
    たなデータのための余地がバッファ上に存在するか否か
    を調査し、余地が存在しない場合に、前記更新が必要と
    判断するように構成されたことを特徴とする請求項１５
    記載のファイルシステム。
19. 【請求項１９】 各ドライブにおける前記更新の時間的
    重複を回避して更新を逐次化する逐次化手段を有するこ
    とを特徴とする請求項１５記載のファイルシステム。
20. 【請求項２０】 前記逐次化手段は、一のドライブにお
    いて前記更新をしようとする際に他の更新中のドライブ
    が存在するか否かを調査し、他の更新中のドライブが存
    在する場合は前記一のドライブにおける更新を抑止し、
    他の更新中のドライブが存在しない場合は前記一のドラ
    イブにおける更新を行うように構成されたことを特徴と
    する請求項１９記載のファイルシステム。
21. 【請求項２１】 前記逐次化手段は、更新中のドライブ
    が存在した場合は所定時間待機後に再度調査を行い、更
    新中のドライブが存在しなくなった場合に更新を行うよ
    うに構成されたことを特徴とする請求項２０記載のファ
    イルシステム。
22. 【請求項２２】 前記逐次化手段は、前記調査中のドラ
    イブを検出した場合にも所定時間待機し、更新中の待機
    の時間と調査中の待機の時間とは各々別個独立に設定で
    きるように構成されたことを特徴とする請求項２１記載
    のファイルシステム。
23. 【請求項２３】 前記逐次化手段は、各ドライブの状態
    を示すフラグをドライブの状態に応じて「更新中」、
    「調査中」及びそれ以外の状態にセットし、更新しよう
    とするときに他のドライブのフラグを調査するように構
    成されたことを特徴とする請求項２０記載のファイルシ
    ステム。
24. 【請求項２４】 前記逐次化手段は、各ドライブの各々
    に個別に設けられたことを特徴とする請求項１９記載の
    ファイルシステム。
25. 【請求項２５】 前記各逐次化手段は、通信回線を経由
    して他のドライブの状態に関する情報を収集することに
    よって前記調査を行うように構成されたことを特徴とす
    る請求項２４記載のファイルシステム。
26. 【請求項２６】 前記逐次化手段は、各ドライブのフラ
    グを他の全てのドライブに控えとして転送・コピーし、
    他のドライブではこの控えのフラグを参照することによ
    って前記調査を行うように構成されたことを特徴とする
    請求項２４記載のファイルシステム。
27. 【請求項２７】 前記逐次化手段は、各ドライブの更新
    を所定のクロックに基づいて所定の各時間的サイクル内
    に制限することによって前記逐次化を行うように構成さ
    れたことを特徴とする請求項１９記載のファイルシステ
    ム。
28. 【請求項２８】 複数のドライブを有し、各ファイルが
    複数のドライブ上に記録されたことを特徴とする請求項
    １９記載のファイルシステム。
29. 【請求項２９】 前記各ドライブがそれぞれ別個独立の
    ディスク装置（磁気又は光学）であり、各媒体が各ディ
    スク装置の記録ディスクであることを特徴とする請求項
    １５記載のファイルシステム。
30. 【請求項３０】 前記各ドライブが単一のディスク装置
    内に設けられた各パーティションであることを特徴とす
    る請求項１５記載のファイルシステム。