JP3614886B2 - ファイルシステム - Google Patents
ファイルシステム Download PDFInfo
- Publication number
- JP3614886B2 JP3614886B2 JP17121094A JP17121094A JP3614886B2 JP 3614886 B2 JP3614886 B2 JP 3614886B2 JP 17121094 A JP17121094 A JP 17121094A JP 17121094 A JP17121094 A JP 17121094A JP 3614886 B2 JP3614886 B2 JP 3614886B2
- Authority
- JP
- Japan
- Prior art keywords
- drive
- buffer
- file system
- update
- updated
- 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.)
- Expired - Lifetime
Links
Images
Landscapes
- Techniques For Improving Reliability Of Storages (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【０００１】
【産業上の利用分野】
本発明は、ファイルなどのデータを格納するファイルシステムの改良に関するものであり、特に、信頼性に優れたファイルシステムに係る。
【０００２】
【従来の技術】
大多数のコンピュータは、内部記憶装置と外部記憶装置を持つ。内部記憶装置は、外部からの継続的電力供給によって情報を保つ。代表的な内部記憶装置はＲＡＭで構成された主メモリ(main memory) である。外部記憶装置は、原理や種類にかかわらず、何等かの記録媒体（例えば、磁気ディスクや光磁気ディスク）を持つ。記録媒体が着脱可能か否かにかかわらず、単一の外部記憶装置はドライブと呼ばれる。ドライブの媒体には、通常、多数のブロックが形成されている。このブロックはアクセスの単位である。
【０００３】
例えば、ある規格のフロッピーディスクは２つのサーフェス(surfaces)を持ち、各サーフェスはそれぞれ、同心円状に配置された８０のトラックを持ち、各トラックは１６セクタに区分される。この各セクタ又はいくつかの連続したセクタが前記ブロックに相当する。固定ディスク装置では、記録媒体は、円筒状に積層された堅い円盤である。このため、固定ディスク装置はサーフェスを多数有する。また、トラックの代りにシリンダという用語が使われる。
【０００４】
ほとんどの場合、ディスク上の情報を更新する単一の操作は、媒体上の複数のブロックを更新する。その第１の理由は、ブロックのサイズ（例えば２５６バイト）は、通常、単一の操作の情報量よりはるかに小さいからである。例えば、コンピュータ上で編集されたわずか数頁に過ぎない文書も、何十ものブロックやセクタを費やして保存される。第２の理由は、媒体上のデータが一般にファイル単位でアクセスされ、かつ、ファイルの管理情報は後述のＦＡＴやディレクトリの様に分かれて配置（記憶）されているからである。
【０００５】
ファイルシステムは、外部記憶装置とこの外部記憶装置のデータをファイル単位でアクセスするための制御手順を総称する概念である。ファイルシステムは、管理情報（例えば、ＦＡＴ(File Allocation Table) とディレクトリ）を必要とする。このため、ファイルを更新する場合、ファイルをわずか１セクタ延長するだけでも、ファイルの内容となるデータのほかに、ＦＡＴやディレクトリも更新する必要がある。この結果、しばしば単一の操作が複数のブロックの内容を更新する。
【０００６】
ファイルシステムでは、通常、バッファ(buffer)が用いられる。バッファとは、媒体へ書き込むべきデータを一時的に蓄積するメモリ上の所定の領域である。バッファは、主メモリを用いてもよいし、ドライブ駆動用のサブコンピュータ上に設けることも考えられる。例えば、ディスクとバッファを組み合わせたシステムでは、ディスク上のデータを変更する操作の際に、変更するブロックの内容を直接ディスクに書き込まず、バッファに一時的に格納する。バッファに書かれたブロックのデータ（以下、「バッファブロック」と呼ぶ）は、少なくともシステムを止める前には、媒体に書き込むべきものである。このようなバッファブロックがある程度たまってから実際のディスクアクセスを行えば、ディスクアクセスの回数を減らし、処理を効率化することができる。
【０００７】
バッファがまだディスクに書いていないデータによって一杯になり、新たなデータがバッファに書き込めない場合は、不足する分のバッファブロックによって媒体を更新し、バッファのうち更新済みの領域に新たなデータを書き込む。
【０００８】
【発明が解決しようとする課題】
上記のバッファを用いるファイルシステムは一般的であるが、このようなファイルシステムを用いる場合でも、かつては、単一のコンピュータの単一の論理的ドライブを実現するハードウェアとしては、実際に単一のドライブのみが接続された。単一のドライブしか有しないコンピュータは、しばしばドライブの故障によるデータの喪失を生じる。ドライブの故障は、電源の遮断、ヘッドクラッシュ、制御回路の故障など多様である。故障による最も不運な結果は、故障がデータ書き込み中に発生し、媒体がいわば「書きかけ」の状態になることである。
【０００９】
ここで、「書きかけ」は同時に更新されるべき複数のブロックのうち、一部のみが更新され、残りは旧い内容になっている状態を表す。例えば、一般に、ファイル内のデータと、このファイルのＦＡＴ、ディレクトリの情報は、相互に矛盾してはならない。しかし、これらのうちいずれかが更新されていない状態でドライブが故障すると、相互に整合性を失い、ファイルのデータは失われるか、復元困難になる。また、「書きかけ」の他の例として、例えばＦＡＴのみディスクに書き込み済で、ディレクトリを書き込んでいない状態では、管理情報それ自体に矛盾が生じる。さらに、連続したブロックが単一のファイルの一部を構成している場合において、あるブロックの内容は更新されており、次のブロックの内容は旧いままという状態も、「書きかけ」の例である。旧いデータと新しいデータとの間では、当然、整合性が失われている。
【００１０】
新しい内容と旧い内容が混じって整合性を失ったファイルのデータの復旧は、全体が旧い内容のままのファイルのデータの復旧よりも、はるかに困難である。この困難さの一つの原因は、旧い部分と新しい部分の特定が困難なことである。また、もう一つの原因は、（特に、ドライブが磁気ディスクの場合に生じるが）、動作不全に陥ったヘッドによる媒体上のデータの破壊である。これは、ヘッドから発生している書込用の磁界が故障の瞬間から不正常になったり、ヘッドが磁気面を損傷するからである。さらに、ファイルの管理情報を失うことによってファイル全体を失う事態も生じ得る。
【００１１】
特に、不運にもコンピュータのシステム・ファイルを喪失すると、コンピュータ・システムを起動できなくなり、故障の診断や復旧自体も不可能になる。
【００１２】
このようなデータの喪失に対する許容性は、分野によって異なる。例えば、帳票計算や実験データの整理あるいは文書作成の分野では、旧いデータからのやり直しが利く。このような分野では耐障害性をあまり要求されない。一方、大型プラントの制御や交通システムの制御あるいは銀行の口座管理などの分野では、データの消滅は許されず、やり直しが利かない。後者の分野では、データの喪失は、ただちに危険や権利義務関係の混乱を招くので、耐障害性が高度に要求される。
【００１３】
近年では、計算機システムのダウンサイジングに伴って、従来は耐障害性を要求されないような分野にしか使用されていなかった各種のシステムが、高度の耐障害性が要求される分野においても利用されるようになってきている。例えば、小型計算機に多く利用されているＵＮＩＸのファイルシステムなどは、耐障害性を考慮していないファイル記憶装置であるが、高度の耐障害性が要求される分野でも利用されるようになってきている。このため、耐障害性の向上は重要な課題である。
【００１４】
ファイルの喪失を防ぎ、耐障害性を向上させる手法の代表的なものは、ミラーリングと分散ファイルシステム(Distributed File System) である。ミラーリングは、単一のコンピュータに複数のドライブを接続し、各ドライブに全く同じデータを書き込む技術である。また、分散ファイルシステムは、コンピュータに３台以上のドライブを接続し、同一内容のファイルを常に２台以上のドライブ上に格納しておくシステムである。このように、同一内容のデータを複数のドライブに格納してファイルを多重化しておけば、一部のドライブが故障しても、残りのドライブに残ったファイルを用いて業務やファイルの復旧が可能である。
【００１５】
しかし、ファイルの多重化にも次のような問題点が残る。その問題点は、複数のドライブでデータが「書きかけ」の状態が同時に発生し得ることである。なぜならば、従来は、複数のドライブへの書き込みが同時に起こり得たからである。また、従来、ドライブのブロックを更新するバッファブロックの単位は、ドライブのファイルへの操作の単位とは無関係に行われていたからである。
【００１６】
例えば、単一の操作で、２つのドライブにおいて、それぞれ２つずつのバッファブロックを操作する場合、双方のドライブで１つのブロックのみが更新され、他方のブロックが更新されていない状態がしばしば発生した。特に不運な状態は、同じファイルがある全てのドライブにおいて「書きかけ」での故障が起きることである。この場合は、同一内容の複数のファイル全てが失われる。このため、全てのファイルの喪失の危険性をなくし、ファイルシステムの信頼性を向上させることが必要であった。
【００１７】
本発明は、上記のような従来技術の問題点を解決するために提案されたものであり、その目的は、信頼性の高いファイルシステムを提供することである。さらに具体的な目的は、「書きかけ」によるブロック間の矛盾が生じにくいファイルシステムを提供することである。また、他の具体的な目的は、ドライブの故障の場合でも、同一内容の複数のファイルのうち少なくとも１つは失われないファイルシステムを提供することである。
【００１８】
また、本発明の他の目的は、効率的にデータを処理するファイルシステムを提供することである。また、本発明の他の目的は、単純な構成のファイルシステムを提供することである。また、本発明の他の目的は、故障の影響が局限され他の部分に及びにくいファイルシステムを提供することである。また、本発明の他の目的は、信頼性が高く、かつ、従来のファイルシステムに導入が容易なファイルシステムを提供することである。
【００１９】
【課題を解決するための手段】
上記の目的を達成するため、請求項１のファイルシステムは、不揮発性の記憶装置のドライブを複数有し、各ドライブの各々には、各ドライブの記録媒体上にアクセス単位である複数のブロックと、揮発性メモリ上のバッファに前記各ブロックに書き込むべきデータであるバッファブロックを一時的に格納するバッファ手段と、バッファブロックによる記録媒体の更新の必要性を判断する判断手段と、前記更新が必要と判断されたときに、全てのバッファブロックによってドライブのブロックを連続して更新する更新手段と、各ドライブにおける前記更新の時間的重複を回避して更新を逐次化する逐次化手段を有することを特徴とする。
【００２０】
請求項２のファイルシステムは、前記逐次化手段は、一のドライブにおいて前記更新をしようとする際に他の更新中のドライブが存在するか否かを調査し、他の更新中のドライブが存在する場合は前記一のドライブにおける更新を抑止し、他の更新中のドライブが存在しない場合は前記一のドライブにおける更新を行うように構成されたことを特徴とする。
請求項３のファイルシステムは、前記逐次化手段は、更新中のドライブが存在した場合は所定時間待機後に再度調査を行い、更新中のドライブが存在しなくなった場合に更新を行うように構成されたことを特徴とする。
請求項４のファイルシステムは、前記逐次化手段は、各ドライブの状態を示すフラグをドライブの状態に応じて「更新中」、「調査中」及びそれ以外の状態にセットし、更新しようとするときに他のドライブのフラグを調査するように構成されたことを特徴とする。
請求項５のファイルシステムは、前記逐次化手段は、各ドライブの各々に個別に設けられたことを特徴とする。
【００２１】
請求項６のファイルシステムは、前記各逐次化手段は、通信回線を経由して他のドライブの状態に関する情報を収集することによって前記調査を行うように構成されたことを特徴とする。
請求項７のファイルシステムは、前記逐次化手段は、各ドライブのフラグを他の全てのドライブに控えとして転送・コピーし、他のドライブではこの控えのフラグを参照することによって前記調査を行うように構成されたことを特徴とする。
請求項８のファイルシステムは、前記逐次化手段は、各ドライブの更新を所定のクロックに基づいて所定の各時間的サイクル内に制限することによって前記逐次化を行うように構成されたことを特徴とする。
請求項９のファイルシステムは、複数のドライブを有し、各ファイルが複数のドライブ 上に記録されたことを特徴とする。
【００２２】
請求項１０のファイルシステムは、不揮発性の記憶装置のドライブを複数有し、各ドライブの各々は、各ドライブの記録媒体上にアクセス単位である複数のブロックと、揮発性メモリ上のバッファに前記各ブロックに書き込むべきデータであるバッファブロックを、前記ドライブへのブロックの更新を要求する単一のデータ書き込み操作が発生する都度、その単一のデータ書き込み操作ごとに、前記各ブロックに書き込むべきデータであるバッファブロックを揮発性メモリ上のバッファに対して一時的に格納するバッファ手段と、バッファブロックによる記録媒体の更新の必要性を判断する判断手段と、前記判断手段によって更新が必要と判断されたときに、少なくとも前記単一のデータ書き込み操作の対象となるすべてのバッファブロックによってドライブのブロックを連続して更新する更新手段と、各ドライブにおける前記更新の時間的重複を回避して更新を逐次化する逐次化手段を有することを特徴とする。
【００２３】
請求項１１のファイルシステムは、前記バッファ手段は、前記発生した単一のデータ書き込み操作とこの書き込み操作の対象であるすべてのバッファブロックの対応付けを行う識別情報と共に、前記バッファブロックをバッファに対して一時的に格納するものであり、前記更新手段は、前記判断手段によって更新が必要と判断されたときに、前記識別情報に基づいて、単一のデータ書き込み操作に対応する全てのバッファブロックを単位として前記更新を行うように構成されたことを特徴とする。
請求項１２のファイルシステムは、前記更新手段は、複数のデータ書き込み操作の対象に同一のバッファブロックが含まれる場合、それら複数のデータ書き込み操作に係る全てのバッファブロックを連続して更新するように構成されたことを特徴とする。
【００２４】
請求項１３のファイルシステムは、前記逐次化手段は、一のドライブにおいて前記更新をしようとする際に他の更新中のドライブが存在するか否かを調査し、他の更新中のドライブが存在する場合は前記一のドライブにおける更新を抑止し、他の更新中のドライブが存在しない場合は前記一のドライブにおける更新を行うように構成されたことを特徴とする。
請求項１４のファイルシステムは、前記逐次化手段は、更新中のドライブが存在した場合は所定時間待機後に再度調査を行い、更新中のドライブが存在しなくなった場合に更新を行うように構成されたことを特徴とする。
請求項１５のファイルシステムは、前記逐次化手段は、各ドライブの状態を示すフラグをドライブの状態に応じて「更新中」、「調査中」及びそれ以外の状態にセットし、更新しようとするときに他のドライブのフラグを調査するように構成されたことを特徴とする。
【００２５】
請求項１６のファイルシステムは、前記逐次化手段は、各ドライブの各々に個別に設けられたことを特徴とする。
請求項１７のファイルシステムは、前記各逐次化手段は、通信回線を経由して他のドライブの状態に関する情報を収集することによって前記調査を行うように構成されたことを特徴とする。
請求項１８のファイルシステムは、前記逐次化手段は、各ドライブのフラグを他の全てのドライブに控えとして転送・コピーし、他のドライブではこの控えのフラグを参照することによって前記調査を行うように構成されたことを特徴とする。
請求項１９のファイルシステムは、前記逐次化手段は、各ドライブの更新を所定のクロックに基づいて所定の各時間的サイクル内に制限することによって前記逐次化を行うように構成されたことを特徴とする。
請求項２０のファイルシステムは、複数のドライブを有し、各ファイルが複数のドライブ上に記録されたことを特徴とする。
【００２６】
【作用】
請求項１，１０の発明では、媒体の更新の際に、全てのバッファブロックによる更新が連続して行われるので、「書きかけ」の状態が更新最中のみに限定され、更新と更新の間にはファイルのブロック間の不整合が発生しない。このため、更新中以外の瞬間にドライブが故障してもファイル内の各ブロック間の整合性は失われない。また、請求項１の発明では、バッファ上の更新を全てのバッファブロックによって行うので、操作ごとのバッファブロックを峻別して扱う繁雑な処理が不要になる。また、全てのバッファブロックによる更新を一度に行うことから、更新をＣＰＵの負荷が低い時に行っておけば、ＣＰＵの負荷が高いときに更新が必要となる可能性を低減させることができる。さらに、逐次化手段が更新のタイミングをずらすので、複数のドライブで「書きかけ」の状態が同時に発生することがない。このため、複数のドライブのデータが同時に失われることがなく、少なくとも１つのドライブにデータが残る。
【００２７】
請求項２，１３の発明では、逐次化手段が、更新ごとに毎回調査し他の更新中のドライブを検出することによって更新の時間的重複を避けるので、確実な逐次化を行うことができる。また、請求項４の発明は更新開始の制御を逐次化手段に与えることによって実現でき、更新自体を行うハードウェアや手順は従来通りのものが利用できるので従来の設備が有効活用できる。
【００２８】
請求項３，１４の発明では、逐次化手段が所定時間待機することによって逐次化を実現するので、更新のタイミングを割り振るスーパーバイザは不必要である。
【００２９】
請求項４，１５の発明では、各ドライブのハードウェアが異なっても逐次化手段は他のドライブのフラグさえ参照すれば更新中や調査中のドライブを検出することができる。また、各ドライブに逐次化手段を備える場合は更新しようとする側がフラグを参照する。このため、各ドライブを制御する上位のスーパーバイザを備える必要がない。
【００３０】
請求項５，１６の発明では、逐次化手段が各ドライブに分散しているので、故障したドライブがあっても他のドライブは影響を受けない。また、逐次化手段がドライブを制御する上位のスーパーバイザとして構成されている場合は逐次化手段の故障によって各ドライブでの処理が停止するが、請求項８の発明によれば、このような停止を回避することができる。
【００３１】
請求項６，１７の発明では、通信回線さえあれば逐次化手段がこの通信回線を用いて調査を行うので、フラグやスーパーバイザは不要となる。
【００３２】
請求項７，１８の発明では、各ドライブの逐次化手段は、調査の度に他のドライブの状態や他のドライブに設けられたフラグを通信回線で参照する必要がなくなるので、更新時の処理が高速化される。
請求項８，１９の発明では、各ドライブでの更新の機会が所定のサイクルで確実に与えられ、特定のドライブでの更新が他のドライブでの更新の連続によって遅延する場合がなくなる。
【００３３】
請求項９，２０の発明は、いわゆる分散ファイルシステムであり、この発明では、通常、各ドライブごとにどのファイルが存在するかが異なる。このため、各ドライブのバッファが一杯になるタイミングが分散し、ドライブ更新のための待ち時間が減少する。すなわち、ミラーリングのように、全てのドライブの内容が同一の場合は、複数のドライブに対 する書き込みのタイミングが時間的に競合するので、無駄な待ち時間が発生するが、本発明ではそのような待ち時間の発生が減少する。
【００３４】
請求項１１の発明では、各操作とバッファブロックについて、コード番号のような識別情報を記録しておくことによって容易に対応関係を特定できるので、特殊なデータ構造を用いずに、単純な構成で操作単位の更新が実現できる。
【００３５】
請求項１２の発明では、複数の操作が同一のブロックを対象とした場合、そのうち一部の操作の内容のみによって当該ブロックが更新されることがないので、他の操作の対象としてのブロック間の整合性を喪失することがない。
【００３６】
【実施例】
次に、本発明の実施例について図面に従って具体的に説明する。なお、後述する実施例はコンピュータ上に実現され、実施例の各機能は所定の手順（プログラム）がこのコンピュータを制御することで実現される。
【００３７】
本明細書における各「手段」は実施例の各機能に対応する概念的なもので、必ずしも特定のハードウェアやソフトウェア・ルーチンに１対１には対応しない。同一のハードウェア要素が場合によって異なった手段を構成する。例えば、コンピュータはある命令を実行するときにある手段となり別の命令を実行するときは別の手段となりうる。また、一つの手段がわずか１命令によって実現される場合もあれば多数の命令によって実現される場合もある。
【００３８】
したがって、本明細書では、以下、実施例の各機能を有する仮想的回路ブロック（手段）を想定して実施例を説明する。但し、コンピュータの使用は一例であり、本発明の機能の全部又は一部は、可能ならば、カスタムチップ（専用の集積回路）のような電子回路上に実現してもよい。
【００３９】
実施例に用いられるコンピュータは、一般には、ＣＰＵ（中央演算処理装置）と、ＲＡＭ（随時書込読出型記憶素子）からなる主記憶装置とを有する。また、前記コンピュータの規模は自由であり、マイクロコンピュータ・パーソナルコンピュータ・スモールコンピュータ・ワークステーション・メインフレームなど、いかなる規模のものを用いてもよい。
【００４０】
また、前記コンピュータのハードウェアは、典型的には、キーボードやマウスなどの入力装置と、ハードディスク装置などの外部記憶装置と、ＣＲＴ表示装置やプリンタ印字装置などの出力装置と、必要な入出力制御回路を含む。
【００４１】
但し、前記コンピュータのハードウェア構成は自由であり、本発明が実施できる限り、上記の構成要素の一部を追加・変更・除外してもよい。例えば、実施例は、複数のコンピュータを接続したコンピュータネットワーク上に実現してもよい。また、ＣＰＵの種類は自由であり、ＣＰＵを複数同時に用いたり、単一のＣＰＵをタイムシェアリング（時分割）で使用し、複数の処理を同時平行的に行ってもよい。
【００４２】
また、他の入力装置（例えば、タッチパネル・ライトペン・トラックボールなどのポインティングデバイスや、デジタイザ・イメージ読取装置やビデオカメラなどの画像入力装置・音声識別装置・各種センサなど）を用いてもよい。また、他の外部記憶装置（例えば、フロッピーディスク装置・ＲＡＭカード装置・磁気テープ装置・光学ディスク装置・光磁気ディスク装置・バブルメモリ装置・フラッシュメモリなど）を用いてもよい。また、他の出力装置（例えば、液晶表示装置・プラズマディスプレイ装置・ビデオプロジェクター・ＬＥＤ表示装置・音響発生回路・音声合成回路など）を用いてもよい。
【００４３】
また、前記コンピュータにおいて実施例を実現するためのソフトウェアの構成としては、典型的には、実施例の各機能を実現するためのアプリケーションプログラムが、ＯＳ（オペレーティングシステム）上で実行される態様が考えられる。また、実施例を実現するためのプログラムの態様としては、典型的には、高級言語やアセンブラからコンパイル（翻訳）された機械語が考えられる。但し、前記コンピュータのソフトウェア構成も自由であり、本発明が実施できる限り、ソフトウェア構成を変更してもよい。例えば、必ずしもＯＳを用いる必要はなく、また、プログラムの表現形式も自由であり、ＢＡＳＩＣのようなインタプリタ（逐次解釈実行型）言語を用いてもよい。
【００４４】
また、プログラムの格納態様も自由であり、ＲＯＭ（読出し専用メモリ）に格納しておいてもよく、また、ハードディスク装置のような外部記憶装置に格納しておき、コンピュータの起動時や処理の開始時に主メモリ上にロード（読み込み）してもよい。また、プログラムを複数の部分に分割して外部記憶装置に格納しておき、処理内容に応じて必要なモジュールのみを随時主メモリ上にロード（読み込み）してもよい。さらに、プログラムの部分ごとに異なった態様で格納してもよい。
【００４５】
また、本実施例における各手順の各ステップは、その性質に反しない限り、実行順序を変更し、複数同時に実行し、また、実行ごとに異なった順序で実行してもよい。このような順序の変更は、例えば、ユーザが実行可能な処理を選択するなどメニュー形式のインターフェース手法によって実現することができる。
【００４６】
また、本明細書における「入力」は、本来の情報の入力のみならず、情報の入力と密接に関連する他の処理を含む。このような処理は、例えば、入力内容のエコーバックや修正・編集である。また、本明細書における「出力」は、本来の情報の出力のみならず、情報の出力と密接に関連する他の処理を含む。このような処理は、例えば、出力すべき範囲の入力や、画面スクロールの指示である。なお、対話的入出力手順によって入力と出力を一体的操作によって実現してもよく、このような一体的操作によって、選択・指定・特定などの処理を行ってもよい。
【００４７】
また、本明細書におけるデータ（情報）やデータの格納手段は前記コンピュータ上においていかなる態様で存在してもよい。例えば、データのハードウェア上の所在部分は、主記憶装置・外部記憶装置・ＣＰＵのレジスタやキャッシュメモリなどいかなる部分でもよい。また、データの保持態様も自由である。例えば、データは、ファイル形式で保持されるのみならず、メモリやディスクなどの記憶装置を物理的アドレスで直接アクセスすることによって実現してもよい。また、データの表現形式も自由で、例えば、文字列を表すコードの単位は、文字単位でも単語単位でもよい。また、データは必要とされる一定時間だけ保持されれば十分で、その後消滅してもよく、保持時間の長短は自由である。また、辞書データのように当面変更されない情報は、ＲＯＭに格納してもよい。
【００４８】
また、本明細書において、特定の情報への言及は確認的で、言及されない情報の存在を否定するものではない。すなわち、本発明の動作では、動作に必要な一般的な情報、例えば、各種ポインタ、カウンタ、フラグ、パラメータ、バッファなどが適宜用いられる。
【００４９】
実施例の各部分が処理に要する情報は、特に記載がない場合、当該情報を保持している他の部分から獲得される。このような情報の獲得は、例えば、当該情報を格納している変数やメモリをアクセスすることによって実現することができる。なお、情報の消去・抹消は、当該情報の内容自体を必ずしも記憶領域から現実に削除せず、消去を表すフラグを設定するなど、情報の意味付けの変更によって行うことができる。
【００５０】
１．第１実施例の構成
図１は第１実施例の構成要素を示す構成図である。この場合、図１に示すシステムは、複数のファイル記憶装置１Ｓ，２Ｓ，…，ｎＳ（ｎは２以上の任意の整数）と、これらの複数のファイル記憶装置１Ｓ，２Ｓ，…，ｎＳを連結する共通のシステムバス１０とによって構成されている。なお、各ファイル記憶装置１Ｓ，２Ｓ，…，ｎＳは、請求の範囲にいうドライブに相当する。
【００５１】
ファイル記憶装置１Ｓは、フラッシュ逐次化手段１Ａ（請求の範囲にいう逐次化手段に相当する）、フラッシュ状態フラグ１Ｂ（請求の範囲にいうフラグに相当する）、バッファ管理手段（バッファフラッシュ手段）１Ｃ、ディスクバッファ１Ｄ、およびディスク１Ｅを有する。なお、ディスク１Ｅは、請求の範囲にいう記録媒体に相当する。また、バッファ管理手段１Ｃ及びディスクバッファ２Ｄは、請求の範囲にいうバッファ手段を構成する。また、バッファ管理手段１Ｃは、請求の範囲にいう判断手段及び更新手段としての役割も果たす。なお、本実施例において「フラッシュ」とは、バッファ上の全てのブロックによってドライブのブロックを更新する処理である。
【００５２】
このうち、フラッシュ逐次化手段１Ａは、バッファ管理手段１Ｃからのフラッシュ開始要求に応答して、フラッシュ状態フラグ１Ｂを「調査中」にし、他のファイル記憶装置のフラッシュ状態フラグを調べる。そして、このフラッシュ逐次化手段１Ａは、他のファイル記憶装置中に「調査中」や「実行中」のフラグがない場合には、フラッシュ状態フラグ１Ｂを「更新中（実行中）」にし、要求元のバッファ管理手段１Ｃにフラッシュ開始許可を返す。また、フラッシュ状態フラグ１Ｂは、ファイル記憶装置１Ｓのフラッシュ状態を示すフラグであり、前述のように、フラッシュ逐次化手段１Ａによる調査時またはフラッシュ管理手段１Ｃによるフラッシュ処理時には、フラッシュ逐次化手段１Ａによって「調査中」または「更新中（実行中）」とされ、それ以外の場合には「通常」とされる。
【００５３】
一方、バッファ管理手段１Ｃは、ファイル記憶装置１Ｓに対する外部からの操作要求に応答して、フラッシュ逐次化手段１Ａにフラッシュ開始要求を送る。そして、このバッファ管理手段１Ｃは、前述のように、フラッシュ逐次化手段１Ａからフラッシュ開始許可を受け取ると、それに応答して、ディスクバッファ１Ｄ内の将来的に更新必要性のある全データにより、ディスク１Ｅを更新する。
【００５４】
次に、ファイル記憶装置２Ｓは、フラッシュ逐次化手段２Ａ、フラッシュ状態フラグ２Ｂ、バッファ管理手段（バッファフラッシュ手段）２Ｃ、ディスクバッファ２Ｄ、およびディスク２Ｅを有する。これらの構成要素２Ａ〜２Ｅも、ファイル記憶装置１Ｓの構成要素１Ａ〜１Ｅと全く同様に構成されている。同様に、第ｎ番目のファイル記憶装置ｎＳは、フラッシュ逐次化手段ｎＡ、フラッシュ状態フラグｎＢ、バッファ管理手段（バッファフラッシュ手段）ｎＣ、ディスクバッファｎＤ、およびディスクｎＥを有し、これらの構成要素ｎＡ〜ｎＥも、ファイル記憶装置１Ｓの構成要素１Ａ〜１Ｅと全く同様に構成されている。
【００５５】
なお、図２は図１のシステムの具体的な構成の一例を示す概念図であり、ファイル記憶装置１Ｓは、ＣＰＵ（１Ｆ）、ＲＯＭ（１Ｇ）、ＲＡＭ（１Ｈ）、ＳＣＳＩ（１Ｉ）、ディスク１Ｅ、およびローカルバス１Ｊによって構成されており、ＲＯＭ（１Ｇ）およびＲＡＭ（１Ｈ）内に、バッファ管理手段１Ｃ、フラッシュ逐次化手段１Ａ、フラッシュ状態フラグ１Ｂ、およびディスクバッファ１Ｄが構成されている。同様に、ファイル記憶装置２Ｓは、ＣＰＵ（２Ｆ）、ＲＯＭ（２Ｇ）、ＲＡＭ（２Ｈ）、ＳＣＳＩ規格インタフェース回路（２Ｉ）、ディスク２Ｅ、およびローカルバス２Ｊによって構成されており、ＲＯＭ（２Ｇ）およびＲＡＭ（２Ｈ）内に、バッファ管理手段２Ｃ、フラッシュ逐次化手段２Ａ、フラッシュ状態フラグ２Ｂ、およびディスクバッファ２Ｄが構成されている。
【００５６】
なお、第１実施例は、３つ以上のドライブを有し、各ファイルが２つ以上のドライブ上に記録された、いわゆる分散ファイルシステムであり、この発明では、通常、各ドライブごとにどのファイルが存在するかが異なる。このため、各ドライブのバッファが一杯になるタイミングが分散し、ドライブ更新のための待ち時間が減少する。ミラーリングのように、全てのドライブの内容が同一のミラーリングにおいて逐次化を行う場合は、複数のドライブに対する書き込みの必要が常に同時に発生するので、無駄な待ち時間が発生する。
【００５７】
また、第１実施例では、前記各ドライブがそれぞれ別個独立のディスク装置であり、各媒体が各ディスク装置の記録ディスクである。このため、第１実施例では、単一のディスクを論理的な複数のドライブとみなすパーティションと比べ、単一のドライブの故障によって複数のファイルが失われる可能性が除去できる。
【００５８】
逆に、前記各ドライブは、単一のディスク装置内に設けられた各パーティションでもよい。このようにすれば、複数のドライブが不要であるから優れたファイルシステムが単純なハードウェア構成で廉価に実現できる。
【００５９】
２．第１実施例の作用及び効果
以上のような構成を有する本実施例の分散ファイルシステムの作用について、図３および図４のフローチャートを参照して以下に説明する。この場合、図３は、バッファ管理手段がブロックの書き込み要求（更新要求）を受け取った場合の処理手順を示すフローチャート、図４は、フラッシュ逐次化手段がフラッシュ開始要求を受け取った場合の処理手順を示すフローチャートである。
【００６０】
なお、ここでは、一例として、図１に示すファイル記憶装置１Ｓに対して、図５に示すようなブロックの更新を要求する操作要求が与えられた場合の例を説明する。そして、説明の便宜上、初期状態において、全てのファイル記憶装置１Ｓ〜ｎＳの全てのディスク１Ｅ〜ｎＥは、データの整合性が取れており、全てのファイル記憶装置１Ｓ〜ｎＳのフラッシュ状態フラグの全てのフラッシュ状態フラグ１Ｂ〜ｎＢは、「通常」であるとする。また、ファイル記憶装置１Ｓのディスクバッファ１Ｄは、図６に示すように、その全領域が「空き」であるとする。
【００６１】
２−１．他のファイル記憶装置が全て「通常」である場合の処理
まず、バッファ管理手段１Ｃは、図５に示すブロック１，２，３の更新を必要とする操作１の要求に応答して、図３に示すように、ディスクバッファ１Ｄ内に、書き込みブロック数である３ブロック分の「空き」領域または更新必要性「無」の領域が存在するか否かを判断する（ステップ３０１）。この場合、図６に示すように、ディスクバッファ１Ｄ内には３ブロック分の「空き」領域があるため、この３ブロック分の「空き」領域の各々に、書き込みブロック１，２，３のブロックアドレスとデータ内容を格納し、更新必要性を「有」にする（ステップ３０６）。その結果、ディスクバッファ１Ｄの内容は、図７に示すようになる。この処理の途中では、ディスク１Ｅの更新は行われないので、ディスク１Ｅ内のデータの整合性は依然として保たれている。なお、ディスクバッファ内のブロックごとのデータ内容が請求の範囲にいうバッファブロックに対応する。
【００６２】
次に、バッファ管理手段１Ｃは、図５に示すブロック４，５，６の更新を必要とする操作２の要求に応答して、図３に示すように、ディスクバッファ１Ｄ内に、書き込みブロック数である３ブロック分の「空き」領域または更新必要性「無」の領域が存在するか否かを判断する（ステップ３０１）。この場合、図７に示すように、ディスクバッファ１Ｄ内には３ブロック分の「空き」領域があるため、この３ブロック分の「空き」領域の各々に、書き込みブロック４，５，６のブロックアドレスとデータ内容を格納し、更新必要性を「有」にする（ステップ３０６）。その結果、ディスクバッファ１Ｄの内容は、図８に示すようになる。この処理の途中では、ディスク１Ｅの更新は行われないので、ディスク１Ｅ内のデータの整合性は依然として保たれている。
【００６３】
続いて、バッファ管理手段１Ｃは、図５に示すブロック７，８，９の更新を必要とする操作３の要求に応答して、図３に示すように、ディスクバッファ１Ｄ内に、書き込みブロック数である３ブロック分の「空き」領域または更新必要性「無」の領域が存在するか否かを判断する（ステップ３０１）。この場合、図８に示すように、ディスクバッファ１Ｄ内には３ブロック分の「空き」領域または更新必要性「無」の領域がないため、バッファ管理手段１Ｃは、フラッシュ逐次化手段１Ａにフラッシュ開始要求を送り（ステップ３０２）、フラッシュ逐次化手段１Ａからのフラッシュ開始許可を待つ（ステップ３０３）。
【００６４】
また、フラッシュ逐次化手段１Ａは、バッファ管理手段１Ｃからのフラッシュ開始要求に応答して、図４に示すように、フラッシュ状態フラグ１Ｂを「調査中」にし（ステップ４０１）、他のファイル記憶装置２Ｓ，…，ｎＳのフラッシュ状態フラグ２Ｂ，…，ｎＢを調べ（ステップ４０２）、「調査中」または「更新中（実行中）」のファイル記憶装置が存在するか否かを判断する（ステップ４０３）。この時、他のいずれのファイル記憶装置２Ｓ，…，ｎＳも「調査中」または「更新中（実行中）」でなければ、フラッシュ逐次化手段１Ａは、フラッシュ状態フラグ１Ｂを「更新中（実行中）」にして、要求元のバッファ管理手段１Ｃにフラッシュ開始許可を返し（ステップ４０５）、バッファ管理手段１Ｃからのフラッシュ終了通知を待つ（ステップ４０６）。
【００６５】
なお、ここまでの処理で、ファイル記憶装置１Ｓのディスク１Ｅは初期状態から全く更新されていないため、このディスク１Ｅ上のデータの整合性は依然として保たれたままである。
【００６６】
さらに、バッファ管理手段１Ｃは、フラッシュ逐次化手段１Ａからのフラッシュ開始許可に応答して、ディスクバッファ１Ｄ内の更新必要性「有」の全領域の全データにより、ディスクバッファ１Ｄのフラッシュ処理を行う（ステップ３０４）。すなわち、ここでは、更新必要性「有」の領域に格納されたブロック１，２，３，４，５，６のブロックアドレスとデータ内容によって、ディスク１Ｅを更新して、これらの６ブロック分の領域をディスク更新必要性「無」に変更する。
【００６７】
このフラッシュ処理の途中において、ディスク１Ｅのブロック１，２，３の一部、またはブロック４，５，６の一部のみを更新した状態では、１つの操作で更新しなくてはならない複数のブロックの全てを更新した状態でないため、この時点ではディスク１Ｅ上のデータの整合性は取られていないが、この６ブロック分の全データによってディスク１Ｅの対象ブロック１，２，３，４，５，６を更新し終わった時点では、再びディスク１Ｅ上のデータの整合性が取られている。このフラッシュ処理の後、バッファ管理手段１Ｃは、フラッシュ逐次化手段１Ａにフラッシュ終了通知を送る（ステップ３０５）。そして、フラッシュ逐次化手段１Ａは、バッファ管理手段１Ｃからのフラッシュ終了通知を受け取ると、図４に示すように、フラッシュ状態フラグ１Ｂを「通常」に戻す（ステップ４０７）。
【００６８】
バッファ管理手段１Ｃは引き続き、ディスクバッファ１Ｄの「空き」または更新必要性が「無」の領域の３ブロック分の領域の各々に、書き込みブロック７，８，９のブロックアドレスとデータ内容を格納し、更新必要性を「有」にする（ステップ３０６）。その結果、ディスクバッファ１Ｄの内容は、図９に示すようになる。しかし、この場合にはディスク１Ｅは更新されないため、依然としてディスク１Ｅ上のデータの整合性は保たれている。
【００６９】
このように、本実施例のファイル記憶装置１Ｓにおいて、ディスク１Ｅ上のデータの整合性が崩れるのは、ディスクバッファ１Ｄのフラッシュ処理を行っている時、すなわち、フラッシュ状態フラグ１Ｂが「更新中（実行中）」になっている時のみである。
【００７０】
２−２．他のファイル記憶装置のいずれかが「調査中」または「更新中（実行中）」である場合の処理
一方、例えば、ファイル記憶装置２Ｓがフラッシュ処理を行っている最中には、このファイル記憶装置２Ｓのフラッシュ状態フラグ２Ｂは「更新中（実行中）」になる。この状態で、ファイル記憶装置１Ｓのフラッシュ逐次化手段１Ａがフラッシュ開始要求を受け取った場合には、このフラッシュ逐次化手段１Ａは、図４に示すように、フラッシュ状態フラグ１Ｂを「調査中」にし（ステップ４０１）、他のファイル記憶装置２Ｓ，…，ｎＳのフラッシュ状態フラグ２Ｂ，…，ｎＢを調べ（ステップ４０２）、「調査中」または「更新中（実行中）」のファイル記憶装置が存在すると判断する（ステップ４０３）。続いて、フラッシュ逐次化手段１Ａは、フラッシュ状態フラグ１Ｂを「通常」にして一定時間待機する（ステップ４０４）。
【００７１】
そして、一定時間後、このフラッシュ逐次化手段１Ａは、再び、図４に示すように、フラッシュ状態フラグ１Ｂを「調査中」にし（ステップ４０１）、他のファイル記憶装置２Ｓ，…，ｎＳのフラッシュ状態フラグ２Ｂ，…，ｎＢを調べ（ステップ４０２）、「調査中」または「更新中（実行中）」のファイル記憶装置があるか否かを判断する（ステップ４０３）。この場合、さらにファイル記憶装置２Ｓが「更新中（実行中）」であれば、フラッシュ逐次化手段１Ａは、フラッシュ状態フラグ１Ｂを「通常」にして、再び、一定時間待機することになる。
【００７２】
これに対して、フラッシュ逐次化手段１Ａが待機している間に、ファイル記憶装置２Ａでフラッシュ処理が終了し、フラッシュ状態フラグ２Ｂが「通常」に戻り、「調査中」または「更新中（実行中）」のファイル記憶装置がないと判断した場合には、フラッシュ逐次化手段１Ａは、フラッシュ状態フラグ１Ｂを「更新中（実行中）」にして、要求元のバッファ管理手段１Ｃにフラッシュ開始許可を返し（ステップ４０５）、バッファ管理手段１Ｃからのフラッシュ終了通知を待つ（ステップ４０６）。最終的に、このフラッシュ逐次化手段１Ａは、バッファ管理手段１Ｃからのフラッシュ終了通知を受け取った時点で、フラッシュ状態フラグ１Ｂを「通常」に戻す（ステップ４０７）。
【００７３】
このように、第１実施例において、１つのファイル記憶装置１Ｓでフラッシュ処理を行おうとする場合には、フラッシュ逐次化手段１Ａの作用により、他のファイル記憶装置が、フラッシュ処理のための「調査中」またはフラッシュ処理の「更新中（実行中）」である場合に、バッファ管理手段１Ｃによるフラッシュ処理の実行を一定時間の間制止し、「調査中」または「更新中（実行中）」のファイル記憶装置がなくなった時点で初めてバッファ管理手段１Ｃにフラッシュ開始許可を返して、ディスクバッファ１Ｄのフラッシュ処理を行わせることになる。したがって、同時に２つ以上のファイル記憶装置がフラッシュ処理を行うことがない。
【００７４】
以上説明したように、第１実施例において、ディスク１Ｅ上のデータの整合性が崩れるのは、ディスクバッファ１Ｄのフラッシュ処理を行っている時、すなわち、フラッシュ状態フラグ１Ｂが「更新中（実行中）」になっている時のみであり、また、同時に２つ以上のファイル記憶装置がフラッシュ処理を行うことがないため、同時に２つ以上のファイル記憶装置がディスク上におけるデータの整合性を失ってしまうことはない。したがって、仮に、複数のあるいは全部のファイル記憶装置が同時に障害によってダウンした場合であっても、２重以上に多重化されて複数のファイル記憶装置に保存されたファイルのデータは、少なくとも１つのファイル記憶装置に確実に保存されていることになる。
【００７５】
特に、第１実施例では、逐次化手段が、更新ごとに毎回他の更新中のドライブを検出することによって更新の時間的重複を避けるので、確実な逐次化を行うことができる。また、第１実施例では、更新開始の制御を逐次化手段に与えることによって信頼性の高いファイルシステムを実現でき、更新自体を行うハードウェアや手順は従来通りのものが利用できるので従来の設備が有効活用できる。すなわち、従来のファイルシステムに本発明を適用する際、ハードウェアやＢＩＯＳ(Basic Input/Output System) などディスクにアクセスするための基本的な制御手順のみ変更すれば、ファイルシステムの論理的制御手順を変える必要がない（図１０）。
【００７６】
３．第２実施例
第２実施例では、前記バッファ手段は、操作と、各操作が対象とする各バッファブロックを識別情報を用いて記録するように構成され、前記更新手段は、前記識別情報に基づいて、単一の操作に対応する全てのバッファブロックを単位として前記更新を行うように構成されている。また、第２実施例では、前記更新手段は、複数の操作の対象に同一のバッファブロックが含まれる場合、それら複数の操作に係る全てのバッファブロックを連続して更新するように構成されている。例えば、操作内容をバッファに記録するごとに、操作番号と対象バッファブロック番号を対照表（図１１）に記録する。また、ディスクバッファの所定の領域にも、各バッファブロックを操作対象とした操作番号を記録する。バッファブロック毎の操作番号を記録する（図１２）。例えば、図１１，図１２では、操作１でブロック１，２が、操作２でブロック３，４が、操作３でブロック３，５が操作されている。この場合、更新はバッファブロック１，２を一体に行うほか、操作２，３に係るバッファブロック３，４，５を一体に行う。操作２に係るバッファブロック３，４のみを更新し、バッファブロック５を更新しない状態は、操作３に基づいてみれば「書きかけ」だからである。
【００７７】
このような第２実施例では、各操作とバッファブロックについて、コード番号のような識別情報を記録しておくことによって容易に対応関係を特定できるので、特殊なデータ構造を用いずに、単純な構成で操作単位の更新が実現できる。
【００７８】
また、第２実施例では、複数の操作が同一のブロックを対象とした場合、そのうち一部の操作の内容のみによって当該ブロックが更新されることがないので、他の操作の対象としてのブロック間の整合性を喪失することがない。
【００７９】
４．他の実施例
なお、本発明は、前記実施例に限定されるものではなく、例えば、バッファフラッシュ手段およびフラッシュ逐次化手段の具体的な構成や処理の流れは、自由に変更可能である。また、これらの手段以外の各部の構成要素やファイル記憶装置全体の構成についても、同様に自由に変更可能であり、ファイル記憶装置の数も自由に選択可能である。
【００８０】
例えば、バッファフラッシュを行う場合は、新たなデータを書き込む余地が不足した場合には限定されず、バッファフラッシュの命令がユーザ又はプログラムによって与えられたとき、媒体をドライブから取り外すための命令が与えられたとき、システムを停止しようとするときなど、自由に決定できる。
【００８１】
また、例えば、前記各逐次化手段は、通信回線を経由して他のドライブの状態に関する情報を収集することによって前記調査を行うように構成してもよい（請求項６）。このような実施例では、通信回線さえあれば逐次化手段がこの通信回線を用いて調査を行うので、フラグやスーパーバイザは不要となる。
【００８２】
また、例えば、前記逐次化手段は、各ドライブのフラグを他の全てのドライブに控えとして転送・コピーし、他のドライブではこの控えのフラグを参照することによって前記調査を行うように構成してもよい（請求項７）。このような実施例では、各ドライブの逐次化手段は、調査の度に他のドライブの状態や他のドライブに設けられたフラグを通信回線で参照する必要がなくなるので、更新時の処理が高速化される。上記のような通信やフラグの転送は、イーサネット及びＭＡＰのようなＬＡＮを用いて行うこともできる。
【００８３】
また、例えば、前記逐次化手段は、各ドライブの更新を所定のクロックに基づいて所定の各クロックサイクル内に制限することによって前記逐次化を行うように構成してもよい（請求項８）。このような実施例では、各ドライブでの更新の機会が所定のサイクルで確実に与えられ、特定のドライブでの更新が他のドライブでの更新の連続によって遅延する場合がなくなる。
【００８４】
【発明の効果】
以上のように、本発明では、更新中以外の瞬間にドライブが故障してもファイル内の各ブロック間の整合性は失われないので、信頼性の高いファイルシステムを提供することができる。
【図面の簡単な説明】
【図１】本発明のファイルシステムの第１実施例の構成要素を示す構成図
【図２】図１のシステムの具体的な構成の一例を示す概念図
【図３】図１のバッファ管理手段がブロックの書き込み要求（更新要求）を受け取った場合の処理手順を示すフローチャート
【図４】図１のフラッシュ逐次化手段がフラッシュ開始要求を受け取った場合の処理手順を示すフローチャート
【図５】図１のファイル記憶装置１Ｓに対する操作要求の操作番号と更新対象ブロックアドレスを示す表
【図６】図１のディスクバッファ１Ｄの初期状態を示す表
【図７】図１のディスクバッファ１Ｄの操作１終了後の状態を示す表
【図８】図１のディスクバッファ１Ｄの操作２終了後の状態を示す表
【図９】図１のディスクバッファ１Ｄの操作３終了後の状態を示す表
【図１０】分散ファイルシステムのソフトウェア構成を示す概念図であり
【図１１】第２実施例における操作履歴表
【図１２】第２実施例におけるディスクバッファの内容
【符号の説明】
１Ｓ，２Ｓ…ファイル記憶装置
１Ａ，２Ａ…フラッシュ逐次化手段
１Ｂ，２Ｂ…フラッシュ状態フラグ
１Ｃ，２Ｃ…バッファ管理手段
１Ｄ，２Ｄ…ディスクバッファ
１Ｅ，２Ｅ…ディスク
１０…システムバス
【産業上の利用分野】
本発明は、ファイルなどのデータを格納するファイルシステムの改良に関するものであり、特に、信頼性に優れたファイルシステムに係る。
【０００２】
【従来の技術】
大多数のコンピュータは、内部記憶装置と外部記憶装置を持つ。内部記憶装置は、外部からの継続的電力供給によって情報を保つ。代表的な内部記憶装置はＲＡＭで構成された主メモリ(main memory) である。外部記憶装置は、原理や種類にかかわらず、何等かの記録媒体（例えば、磁気ディスクや光磁気ディスク）を持つ。記録媒体が着脱可能か否かにかかわらず、単一の外部記憶装置はドライブと呼ばれる。ドライブの媒体には、通常、多数のブロックが形成されている。このブロックはアクセスの単位である。
【０００３】
例えば、ある規格のフロッピーディスクは２つのサーフェス(surfaces)を持ち、各サーフェスはそれぞれ、同心円状に配置された８０のトラックを持ち、各トラックは１６セクタに区分される。この各セクタ又はいくつかの連続したセクタが前記ブロックに相当する。固定ディスク装置では、記録媒体は、円筒状に積層された堅い円盤である。このため、固定ディスク装置はサーフェスを多数有する。また、トラックの代りにシリンダという用語が使われる。
【０００４】
ほとんどの場合、ディスク上の情報を更新する単一の操作は、媒体上の複数のブロックを更新する。その第１の理由は、ブロックのサイズ（例えば２５６バイト）は、通常、単一の操作の情報量よりはるかに小さいからである。例えば、コンピュータ上で編集されたわずか数頁に過ぎない文書も、何十ものブロックやセクタを費やして保存される。第２の理由は、媒体上のデータが一般にファイル単位でアクセスされ、かつ、ファイルの管理情報は後述のＦＡＴやディレクトリの様に分かれて配置（記憶）されているからである。
【０００５】
ファイルシステムは、外部記憶装置とこの外部記憶装置のデータをファイル単位でアクセスするための制御手順を総称する概念である。ファイルシステムは、管理情報（例えば、ＦＡＴ(File Allocation Table) とディレクトリ）を必要とする。このため、ファイルを更新する場合、ファイルをわずか１セクタ延長するだけでも、ファイルの内容となるデータのほかに、ＦＡＴやディレクトリも更新する必要がある。この結果、しばしば単一の操作が複数のブロックの内容を更新する。
【０００６】
ファイルシステムでは、通常、バッファ(buffer)が用いられる。バッファとは、媒体へ書き込むべきデータを一時的に蓄積するメモリ上の所定の領域である。バッファは、主メモリを用いてもよいし、ドライブ駆動用のサブコンピュータ上に設けることも考えられる。例えば、ディスクとバッファを組み合わせたシステムでは、ディスク上のデータを変更する操作の際に、変更するブロックの内容を直接ディスクに書き込まず、バッファに一時的に格納する。バッファに書かれたブロックのデータ（以下、「バッファブロック」と呼ぶ）は、少なくともシステムを止める前には、媒体に書き込むべきものである。このようなバッファブロックがある程度たまってから実際のディスクアクセスを行えば、ディスクアクセスの回数を減らし、処理を効率化することができる。
【０００７】
バッファがまだディスクに書いていないデータによって一杯になり、新たなデータがバッファに書き込めない場合は、不足する分のバッファブロックによって媒体を更新し、バッファのうち更新済みの領域に新たなデータを書き込む。
【０００８】
【発明が解決しようとする課題】
上記のバッファを用いるファイルシステムは一般的であるが、このようなファイルシステムを用いる場合でも、かつては、単一のコンピュータの単一の論理的ドライブを実現するハードウェアとしては、実際に単一のドライブのみが接続された。単一のドライブしか有しないコンピュータは、しばしばドライブの故障によるデータの喪失を生じる。ドライブの故障は、電源の遮断、ヘッドクラッシュ、制御回路の故障など多様である。故障による最も不運な結果は、故障がデータ書き込み中に発生し、媒体がいわば「書きかけ」の状態になることである。
【０００９】
ここで、「書きかけ」は同時に更新されるべき複数のブロックのうち、一部のみが更新され、残りは旧い内容になっている状態を表す。例えば、一般に、ファイル内のデータと、このファイルのＦＡＴ、ディレクトリの情報は、相互に矛盾してはならない。しかし、これらのうちいずれかが更新されていない状態でドライブが故障すると、相互に整合性を失い、ファイルのデータは失われるか、復元困難になる。また、「書きかけ」の他の例として、例えばＦＡＴのみディスクに書き込み済で、ディレクトリを書き込んでいない状態では、管理情報それ自体に矛盾が生じる。さらに、連続したブロックが単一のファイルの一部を構成している場合において、あるブロックの内容は更新されており、次のブロックの内容は旧いままという状態も、「書きかけ」の例である。旧いデータと新しいデータとの間では、当然、整合性が失われている。
【００１０】
新しい内容と旧い内容が混じって整合性を失ったファイルのデータの復旧は、全体が旧い内容のままのファイルのデータの復旧よりも、はるかに困難である。この困難さの一つの原因は、旧い部分と新しい部分の特定が困難なことである。また、もう一つの原因は、（特に、ドライブが磁気ディスクの場合に生じるが）、動作不全に陥ったヘッドによる媒体上のデータの破壊である。これは、ヘッドから発生している書込用の磁界が故障の瞬間から不正常になったり、ヘッドが磁気面を損傷するからである。さらに、ファイルの管理情報を失うことによってファイル全体を失う事態も生じ得る。
【００１１】
特に、不運にもコンピュータのシステム・ファイルを喪失すると、コンピュータ・システムを起動できなくなり、故障の診断や復旧自体も不可能になる。
【００１２】
このようなデータの喪失に対する許容性は、分野によって異なる。例えば、帳票計算や実験データの整理あるいは文書作成の分野では、旧いデータからのやり直しが利く。このような分野では耐障害性をあまり要求されない。一方、大型プラントの制御や交通システムの制御あるいは銀行の口座管理などの分野では、データの消滅は許されず、やり直しが利かない。後者の分野では、データの喪失は、ただちに危険や権利義務関係の混乱を招くので、耐障害性が高度に要求される。
【００１３】
近年では、計算機システムのダウンサイジングに伴って、従来は耐障害性を要求されないような分野にしか使用されていなかった各種のシステムが、高度の耐障害性が要求される分野においても利用されるようになってきている。例えば、小型計算機に多く利用されているＵＮＩＸのファイルシステムなどは、耐障害性を考慮していないファイル記憶装置であるが、高度の耐障害性が要求される分野でも利用されるようになってきている。このため、耐障害性の向上は重要な課題である。
【００１４】
ファイルの喪失を防ぎ、耐障害性を向上させる手法の代表的なものは、ミラーリングと分散ファイルシステム(Distributed File System) である。ミラーリングは、単一のコンピュータに複数のドライブを接続し、各ドライブに全く同じデータを書き込む技術である。また、分散ファイルシステムは、コンピュータに３台以上のドライブを接続し、同一内容のファイルを常に２台以上のドライブ上に格納しておくシステムである。このように、同一内容のデータを複数のドライブに格納してファイルを多重化しておけば、一部のドライブが故障しても、残りのドライブに残ったファイルを用いて業務やファイルの復旧が可能である。
【００１５】
しかし、ファイルの多重化にも次のような問題点が残る。その問題点は、複数のドライブでデータが「書きかけ」の状態が同時に発生し得ることである。なぜならば、従来は、複数のドライブへの書き込みが同時に起こり得たからである。また、従来、ドライブのブロックを更新するバッファブロックの単位は、ドライブのファイルへの操作の単位とは無関係に行われていたからである。
【００１６】
例えば、単一の操作で、２つのドライブにおいて、それぞれ２つずつのバッファブロックを操作する場合、双方のドライブで１つのブロックのみが更新され、他方のブロックが更新されていない状態がしばしば発生した。特に不運な状態は、同じファイルがある全てのドライブにおいて「書きかけ」での故障が起きることである。この場合は、同一内容の複数のファイル全てが失われる。このため、全てのファイルの喪失の危険性をなくし、ファイルシステムの信頼性を向上させることが必要であった。
【００１７】
本発明は、上記のような従来技術の問題点を解決するために提案されたものであり、その目的は、信頼性の高いファイルシステムを提供することである。さらに具体的な目的は、「書きかけ」によるブロック間の矛盾が生じにくいファイルシステムを提供することである。また、他の具体的な目的は、ドライブの故障の場合でも、同一内容の複数のファイルのうち少なくとも１つは失われないファイルシステムを提供することである。
【００１８】
また、本発明の他の目的は、効率的にデータを処理するファイルシステムを提供することである。また、本発明の他の目的は、単純な構成のファイルシステムを提供することである。また、本発明の他の目的は、故障の影響が局限され他の部分に及びにくいファイルシステムを提供することである。また、本発明の他の目的は、信頼性が高く、かつ、従来のファイルシステムに導入が容易なファイルシステムを提供することである。
【００１９】
【課題を解決するための手段】
上記の目的を達成するため、請求項１のファイルシステムは、不揮発性の記憶装置のドライブを複数有し、各ドライブの各々には、各ドライブの記録媒体上にアクセス単位である複数のブロックと、揮発性メモリ上のバッファに前記各ブロックに書き込むべきデータであるバッファブロックを一時的に格納するバッファ手段と、バッファブロックによる記録媒体の更新の必要性を判断する判断手段と、前記更新が必要と判断されたときに、全てのバッファブロックによってドライブのブロックを連続して更新する更新手段と、各ドライブにおける前記更新の時間的重複を回避して更新を逐次化する逐次化手段を有することを特徴とする。
【００２０】
請求項２のファイルシステムは、前記逐次化手段は、一のドライブにおいて前記更新をしようとする際に他の更新中のドライブが存在するか否かを調査し、他の更新中のドライブが存在する場合は前記一のドライブにおける更新を抑止し、他の更新中のドライブが存在しない場合は前記一のドライブにおける更新を行うように構成されたことを特徴とする。
請求項３のファイルシステムは、前記逐次化手段は、更新中のドライブが存在した場合は所定時間待機後に再度調査を行い、更新中のドライブが存在しなくなった場合に更新を行うように構成されたことを特徴とする。
請求項４のファイルシステムは、前記逐次化手段は、各ドライブの状態を示すフラグをドライブの状態に応じて「更新中」、「調査中」及びそれ以外の状態にセットし、更新しようとするときに他のドライブのフラグを調査するように構成されたことを特徴とする。
請求項５のファイルシステムは、前記逐次化手段は、各ドライブの各々に個別に設けられたことを特徴とする。
【００２１】
請求項６のファイルシステムは、前記各逐次化手段は、通信回線を経由して他のドライブの状態に関する情報を収集することによって前記調査を行うように構成されたことを特徴とする。
請求項７のファイルシステムは、前記逐次化手段は、各ドライブのフラグを他の全てのドライブに控えとして転送・コピーし、他のドライブではこの控えのフラグを参照することによって前記調査を行うように構成されたことを特徴とする。
請求項８のファイルシステムは、前記逐次化手段は、各ドライブの更新を所定のクロックに基づいて所定の各時間的サイクル内に制限することによって前記逐次化を行うように構成されたことを特徴とする。
請求項９のファイルシステムは、複数のドライブを有し、各ファイルが複数のドライブ 上に記録されたことを特徴とする。
【００２２】
請求項１０のファイルシステムは、不揮発性の記憶装置のドライブを複数有し、各ドライブの各々は、各ドライブの記録媒体上にアクセス単位である複数のブロックと、揮発性メモリ上のバッファに前記各ブロックに書き込むべきデータであるバッファブロックを、前記ドライブへのブロックの更新を要求する単一のデータ書き込み操作が発生する都度、その単一のデータ書き込み操作ごとに、前記各ブロックに書き込むべきデータであるバッファブロックを揮発性メモリ上のバッファに対して一時的に格納するバッファ手段と、バッファブロックによる記録媒体の更新の必要性を判断する判断手段と、前記判断手段によって更新が必要と判断されたときに、少なくとも前記単一のデータ書き込み操作の対象となるすべてのバッファブロックによってドライブのブロックを連続して更新する更新手段と、各ドライブにおける前記更新の時間的重複を回避して更新を逐次化する逐次化手段を有することを特徴とする。
【００２３】
請求項１１のファイルシステムは、前記バッファ手段は、前記発生した単一のデータ書き込み操作とこの書き込み操作の対象であるすべてのバッファブロックの対応付けを行う識別情報と共に、前記バッファブロックをバッファに対して一時的に格納するものであり、前記更新手段は、前記判断手段によって更新が必要と判断されたときに、前記識別情報に基づいて、単一のデータ書き込み操作に対応する全てのバッファブロックを単位として前記更新を行うように構成されたことを特徴とする。
請求項１２のファイルシステムは、前記更新手段は、複数のデータ書き込み操作の対象に同一のバッファブロックが含まれる場合、それら複数のデータ書き込み操作に係る全てのバッファブロックを連続して更新するように構成されたことを特徴とする。
【００２４】
請求項１３のファイルシステムは、前記逐次化手段は、一のドライブにおいて前記更新をしようとする際に他の更新中のドライブが存在するか否かを調査し、他の更新中のドライブが存在する場合は前記一のドライブにおける更新を抑止し、他の更新中のドライブが存在しない場合は前記一のドライブにおける更新を行うように構成されたことを特徴とする。
請求項１４のファイルシステムは、前記逐次化手段は、更新中のドライブが存在した場合は所定時間待機後に再度調査を行い、更新中のドライブが存在しなくなった場合に更新を行うように構成されたことを特徴とする。
請求項１５のファイルシステムは、前記逐次化手段は、各ドライブの状態を示すフラグをドライブの状態に応じて「更新中」、「調査中」及びそれ以外の状態にセットし、更新しようとするときに他のドライブのフラグを調査するように構成されたことを特徴とする。
【００２５】
請求項１６のファイルシステムは、前記逐次化手段は、各ドライブの各々に個別に設けられたことを特徴とする。
請求項１７のファイルシステムは、前記各逐次化手段は、通信回線を経由して他のドライブの状態に関する情報を収集することによって前記調査を行うように構成されたことを特徴とする。
請求項１８のファイルシステムは、前記逐次化手段は、各ドライブのフラグを他の全てのドライブに控えとして転送・コピーし、他のドライブではこの控えのフラグを参照することによって前記調査を行うように構成されたことを特徴とする。
請求項１９のファイルシステムは、前記逐次化手段は、各ドライブの更新を所定のクロックに基づいて所定の各時間的サイクル内に制限することによって前記逐次化を行うように構成されたことを特徴とする。
請求項２０のファイルシステムは、複数のドライブを有し、各ファイルが複数のドライブ上に記録されたことを特徴とする。
【００２６】
【作用】
請求項１，１０の発明では、媒体の更新の際に、全てのバッファブロックによる更新が連続して行われるので、「書きかけ」の状態が更新最中のみに限定され、更新と更新の間にはファイルのブロック間の不整合が発生しない。このため、更新中以外の瞬間にドライブが故障してもファイル内の各ブロック間の整合性は失われない。また、請求項１の発明では、バッファ上の更新を全てのバッファブロックによって行うので、操作ごとのバッファブロックを峻別して扱う繁雑な処理が不要になる。また、全てのバッファブロックによる更新を一度に行うことから、更新をＣＰＵの負荷が低い時に行っておけば、ＣＰＵの負荷が高いときに更新が必要となる可能性を低減させることができる。さらに、逐次化手段が更新のタイミングをずらすので、複数のドライブで「書きかけ」の状態が同時に発生することがない。このため、複数のドライブのデータが同時に失われることがなく、少なくとも１つのドライブにデータが残る。
【００２７】
請求項２，１３の発明では、逐次化手段が、更新ごとに毎回調査し他の更新中のドライブを検出することによって更新の時間的重複を避けるので、確実な逐次化を行うことができる。また、請求項４の発明は更新開始の制御を逐次化手段に与えることによって実現でき、更新自体を行うハードウェアや手順は従来通りのものが利用できるので従来の設備が有効活用できる。
【００２８】
請求項３，１４の発明では、逐次化手段が所定時間待機することによって逐次化を実現するので、更新のタイミングを割り振るスーパーバイザは不必要である。
【００２９】
請求項４，１５の発明では、各ドライブのハードウェアが異なっても逐次化手段は他のドライブのフラグさえ参照すれば更新中や調査中のドライブを検出することができる。また、各ドライブに逐次化手段を備える場合は更新しようとする側がフラグを参照する。このため、各ドライブを制御する上位のスーパーバイザを備える必要がない。
【００３０】
請求項５，１６の発明では、逐次化手段が各ドライブに分散しているので、故障したドライブがあっても他のドライブは影響を受けない。また、逐次化手段がドライブを制御する上位のスーパーバイザとして構成されている場合は逐次化手段の故障によって各ドライブでの処理が停止するが、請求項８の発明によれば、このような停止を回避することができる。
【００３１】
請求項６，１７の発明では、通信回線さえあれば逐次化手段がこの通信回線を用いて調査を行うので、フラグやスーパーバイザは不要となる。
【００３２】
請求項７，１８の発明では、各ドライブの逐次化手段は、調査の度に他のドライブの状態や他のドライブに設けられたフラグを通信回線で参照する必要がなくなるので、更新時の処理が高速化される。
請求項８，１９の発明では、各ドライブでの更新の機会が所定のサイクルで確実に与えられ、特定のドライブでの更新が他のドライブでの更新の連続によって遅延する場合がなくなる。
【００３３】
請求項９，２０の発明は、いわゆる分散ファイルシステムであり、この発明では、通常、各ドライブごとにどのファイルが存在するかが異なる。このため、各ドライブのバッファが一杯になるタイミングが分散し、ドライブ更新のための待ち時間が減少する。すなわち、ミラーリングのように、全てのドライブの内容が同一の場合は、複数のドライブに対 する書き込みのタイミングが時間的に競合するので、無駄な待ち時間が発生するが、本発明ではそのような待ち時間の発生が減少する。
【００３４】
請求項１１の発明では、各操作とバッファブロックについて、コード番号のような識別情報を記録しておくことによって容易に対応関係を特定できるので、特殊なデータ構造を用いずに、単純な構成で操作単位の更新が実現できる。
【００３５】
請求項１２の発明では、複数の操作が同一のブロックを対象とした場合、そのうち一部の操作の内容のみによって当該ブロックが更新されることがないので、他の操作の対象としてのブロック間の整合性を喪失することがない。
【００３６】
【実施例】
次に、本発明の実施例について図面に従って具体的に説明する。なお、後述する実施例はコンピュータ上に実現され、実施例の各機能は所定の手順（プログラム）がこのコンピュータを制御することで実現される。
【００３７】
本明細書における各「手段」は実施例の各機能に対応する概念的なもので、必ずしも特定のハードウェアやソフトウェア・ルーチンに１対１には対応しない。同一のハードウェア要素が場合によって異なった手段を構成する。例えば、コンピュータはある命令を実行するときにある手段となり別の命令を実行するときは別の手段となりうる。また、一つの手段がわずか１命令によって実現される場合もあれば多数の命令によって実現される場合もある。
【００３８】
したがって、本明細書では、以下、実施例の各機能を有する仮想的回路ブロック（手段）を想定して実施例を説明する。但し、コンピュータの使用は一例であり、本発明の機能の全部又は一部は、可能ならば、カスタムチップ（専用の集積回路）のような電子回路上に実現してもよい。
【００３９】
実施例に用いられるコンピュータは、一般には、ＣＰＵ（中央演算処理装置）と、ＲＡＭ（随時書込読出型記憶素子）からなる主記憶装置とを有する。また、前記コンピュータの規模は自由であり、マイクロコンピュータ・パーソナルコンピュータ・スモールコンピュータ・ワークステーション・メインフレームなど、いかなる規模のものを用いてもよい。
【００４０】
また、前記コンピュータのハードウェアは、典型的には、キーボードやマウスなどの入力装置と、ハードディスク装置などの外部記憶装置と、ＣＲＴ表示装置やプリンタ印字装置などの出力装置と、必要な入出力制御回路を含む。
【００４１】
但し、前記コンピュータのハードウェア構成は自由であり、本発明が実施できる限り、上記の構成要素の一部を追加・変更・除外してもよい。例えば、実施例は、複数のコンピュータを接続したコンピュータネットワーク上に実現してもよい。また、ＣＰＵの種類は自由であり、ＣＰＵを複数同時に用いたり、単一のＣＰＵをタイムシェアリング（時分割）で使用し、複数の処理を同時平行的に行ってもよい。
【００４２】
また、他の入力装置（例えば、タッチパネル・ライトペン・トラックボールなどのポインティングデバイスや、デジタイザ・イメージ読取装置やビデオカメラなどの画像入力装置・音声識別装置・各種センサなど）を用いてもよい。また、他の外部記憶装置（例えば、フロッピーディスク装置・ＲＡＭカード装置・磁気テープ装置・光学ディスク装置・光磁気ディスク装置・バブルメモリ装置・フラッシュメモリなど）を用いてもよい。また、他の出力装置（例えば、液晶表示装置・プラズマディスプレイ装置・ビデオプロジェクター・ＬＥＤ表示装置・音響発生回路・音声合成回路など）を用いてもよい。
【００４３】
また、前記コンピュータにおいて実施例を実現するためのソフトウェアの構成としては、典型的には、実施例の各機能を実現するためのアプリケーションプログラムが、ＯＳ（オペレーティングシステム）上で実行される態様が考えられる。また、実施例を実現するためのプログラムの態様としては、典型的には、高級言語やアセンブラからコンパイル（翻訳）された機械語が考えられる。但し、前記コンピュータのソフトウェア構成も自由であり、本発明が実施できる限り、ソフトウェア構成を変更してもよい。例えば、必ずしもＯＳを用いる必要はなく、また、プログラムの表現形式も自由であり、ＢＡＳＩＣのようなインタプリタ（逐次解釈実行型）言語を用いてもよい。
【００４４】
また、プログラムの格納態様も自由であり、ＲＯＭ（読出し専用メモリ）に格納しておいてもよく、また、ハードディスク装置のような外部記憶装置に格納しておき、コンピュータの起動時や処理の開始時に主メモリ上にロード（読み込み）してもよい。また、プログラムを複数の部分に分割して外部記憶装置に格納しておき、処理内容に応じて必要なモジュールのみを随時主メモリ上にロード（読み込み）してもよい。さらに、プログラムの部分ごとに異なった態様で格納してもよい。
【００４５】
また、本実施例における各手順の各ステップは、その性質に反しない限り、実行順序を変更し、複数同時に実行し、また、実行ごとに異なった順序で実行してもよい。このような順序の変更は、例えば、ユーザが実行可能な処理を選択するなどメニュー形式のインターフェース手法によって実現することができる。
【００４６】
また、本明細書における「入力」は、本来の情報の入力のみならず、情報の入力と密接に関連する他の処理を含む。このような処理は、例えば、入力内容のエコーバックや修正・編集である。また、本明細書における「出力」は、本来の情報の出力のみならず、情報の出力と密接に関連する他の処理を含む。このような処理は、例えば、出力すべき範囲の入力や、画面スクロールの指示である。なお、対話的入出力手順によって入力と出力を一体的操作によって実現してもよく、このような一体的操作によって、選択・指定・特定などの処理を行ってもよい。
【００４７】
また、本明細書におけるデータ（情報）やデータの格納手段は前記コンピュータ上においていかなる態様で存在してもよい。例えば、データのハードウェア上の所在部分は、主記憶装置・外部記憶装置・ＣＰＵのレジスタやキャッシュメモリなどいかなる部分でもよい。また、データの保持態様も自由である。例えば、データは、ファイル形式で保持されるのみならず、メモリやディスクなどの記憶装置を物理的アドレスで直接アクセスすることによって実現してもよい。また、データの表現形式も自由で、例えば、文字列を表すコードの単位は、文字単位でも単語単位でもよい。また、データは必要とされる一定時間だけ保持されれば十分で、その後消滅してもよく、保持時間の長短は自由である。また、辞書データのように当面変更されない情報は、ＲＯＭに格納してもよい。
【００４８】
また、本明細書において、特定の情報への言及は確認的で、言及されない情報の存在を否定するものではない。すなわち、本発明の動作では、動作に必要な一般的な情報、例えば、各種ポインタ、カウンタ、フラグ、パラメータ、バッファなどが適宜用いられる。
【００４９】
実施例の各部分が処理に要する情報は、特に記載がない場合、当該情報を保持している他の部分から獲得される。このような情報の獲得は、例えば、当該情報を格納している変数やメモリをアクセスすることによって実現することができる。なお、情報の消去・抹消は、当該情報の内容自体を必ずしも記憶領域から現実に削除せず、消去を表すフラグを設定するなど、情報の意味付けの変更によって行うことができる。
【００５０】
１．第１実施例の構成
図１は第１実施例の構成要素を示す構成図である。この場合、図１に示すシステムは、複数のファイル記憶装置１Ｓ，２Ｓ，…，ｎＳ（ｎは２以上の任意の整数）と、これらの複数のファイル記憶装置１Ｓ，２Ｓ，…，ｎＳを連結する共通のシステムバス１０とによって構成されている。なお、各ファイル記憶装置１Ｓ，２Ｓ，…，ｎＳは、請求の範囲にいうドライブに相当する。
【００５１】
ファイル記憶装置１Ｓは、フラッシュ逐次化手段１Ａ（請求の範囲にいう逐次化手段に相当する）、フラッシュ状態フラグ１Ｂ（請求の範囲にいうフラグに相当する）、バッファ管理手段（バッファフラッシュ手段）１Ｃ、ディスクバッファ１Ｄ、およびディスク１Ｅを有する。なお、ディスク１Ｅは、請求の範囲にいう記録媒体に相当する。また、バッファ管理手段１Ｃ及びディスクバッファ２Ｄは、請求の範囲にいうバッファ手段を構成する。また、バッファ管理手段１Ｃは、請求の範囲にいう判断手段及び更新手段としての役割も果たす。なお、本実施例において「フラッシュ」とは、バッファ上の全てのブロックによってドライブのブロックを更新する処理である。
【００５２】
このうち、フラッシュ逐次化手段１Ａは、バッファ管理手段１Ｃからのフラッシュ開始要求に応答して、フラッシュ状態フラグ１Ｂを「調査中」にし、他のファイル記憶装置のフラッシュ状態フラグを調べる。そして、このフラッシュ逐次化手段１Ａは、他のファイル記憶装置中に「調査中」や「実行中」のフラグがない場合には、フラッシュ状態フラグ１Ｂを「更新中（実行中）」にし、要求元のバッファ管理手段１Ｃにフラッシュ開始許可を返す。また、フラッシュ状態フラグ１Ｂは、ファイル記憶装置１Ｓのフラッシュ状態を示すフラグであり、前述のように、フラッシュ逐次化手段１Ａによる調査時またはフラッシュ管理手段１Ｃによるフラッシュ処理時には、フラッシュ逐次化手段１Ａによって「調査中」または「更新中（実行中）」とされ、それ以外の場合には「通常」とされる。
【００５３】
一方、バッファ管理手段１Ｃは、ファイル記憶装置１Ｓに対する外部からの操作要求に応答して、フラッシュ逐次化手段１Ａにフラッシュ開始要求を送る。そして、このバッファ管理手段１Ｃは、前述のように、フラッシュ逐次化手段１Ａからフラッシュ開始許可を受け取ると、それに応答して、ディスクバッファ１Ｄ内の将来的に更新必要性のある全データにより、ディスク１Ｅを更新する。
【００５４】
次に、ファイル記憶装置２Ｓは、フラッシュ逐次化手段２Ａ、フラッシュ状態フラグ２Ｂ、バッファ管理手段（バッファフラッシュ手段）２Ｃ、ディスクバッファ２Ｄ、およびディスク２Ｅを有する。これらの構成要素２Ａ〜２Ｅも、ファイル記憶装置１Ｓの構成要素１Ａ〜１Ｅと全く同様に構成されている。同様に、第ｎ番目のファイル記憶装置ｎＳは、フラッシュ逐次化手段ｎＡ、フラッシュ状態フラグｎＢ、バッファ管理手段（バッファフラッシュ手段）ｎＣ、ディスクバッファｎＤ、およびディスクｎＥを有し、これらの構成要素ｎＡ〜ｎＥも、ファイル記憶装置１Ｓの構成要素１Ａ〜１Ｅと全く同様に構成されている。
【００５５】
なお、図２は図１のシステムの具体的な構成の一例を示す概念図であり、ファイル記憶装置１Ｓは、ＣＰＵ（１Ｆ）、ＲＯＭ（１Ｇ）、ＲＡＭ（１Ｈ）、ＳＣＳＩ（１Ｉ）、ディスク１Ｅ、およびローカルバス１Ｊによって構成されており、ＲＯＭ（１Ｇ）およびＲＡＭ（１Ｈ）内に、バッファ管理手段１Ｃ、フラッシュ逐次化手段１Ａ、フラッシュ状態フラグ１Ｂ、およびディスクバッファ１Ｄが構成されている。同様に、ファイル記憶装置２Ｓは、ＣＰＵ（２Ｆ）、ＲＯＭ（２Ｇ）、ＲＡＭ（２Ｈ）、ＳＣＳＩ規格インタフェース回路（２Ｉ）、ディスク２Ｅ、およびローカルバス２Ｊによって構成されており、ＲＯＭ（２Ｇ）およびＲＡＭ（２Ｈ）内に、バッファ管理手段２Ｃ、フラッシュ逐次化手段２Ａ、フラッシュ状態フラグ２Ｂ、およびディスクバッファ２Ｄが構成されている。
【００５６】
なお、第１実施例は、３つ以上のドライブを有し、各ファイルが２つ以上のドライブ上に記録された、いわゆる分散ファイルシステムであり、この発明では、通常、各ドライブごとにどのファイルが存在するかが異なる。このため、各ドライブのバッファが一杯になるタイミングが分散し、ドライブ更新のための待ち時間が減少する。ミラーリングのように、全てのドライブの内容が同一のミラーリングにおいて逐次化を行う場合は、複数のドライブに対する書き込みの必要が常に同時に発生するので、無駄な待ち時間が発生する。
【００５７】
また、第１実施例では、前記各ドライブがそれぞれ別個独立のディスク装置であり、各媒体が各ディスク装置の記録ディスクである。このため、第１実施例では、単一のディスクを論理的な複数のドライブとみなすパーティションと比べ、単一のドライブの故障によって複数のファイルが失われる可能性が除去できる。
【００５８】
逆に、前記各ドライブは、単一のディスク装置内に設けられた各パーティションでもよい。このようにすれば、複数のドライブが不要であるから優れたファイルシステムが単純なハードウェア構成で廉価に実現できる。
【００５９】
２．第１実施例の作用及び効果
以上のような構成を有する本実施例の分散ファイルシステムの作用について、図３および図４のフローチャートを参照して以下に説明する。この場合、図３は、バッファ管理手段がブロックの書き込み要求（更新要求）を受け取った場合の処理手順を示すフローチャート、図４は、フラッシュ逐次化手段がフラッシュ開始要求を受け取った場合の処理手順を示すフローチャートである。
【００６０】
なお、ここでは、一例として、図１に示すファイル記憶装置１Ｓに対して、図５に示すようなブロックの更新を要求する操作要求が与えられた場合の例を説明する。そして、説明の便宜上、初期状態において、全てのファイル記憶装置１Ｓ〜ｎＳの全てのディスク１Ｅ〜ｎＥは、データの整合性が取れており、全てのファイル記憶装置１Ｓ〜ｎＳのフラッシュ状態フラグの全てのフラッシュ状態フラグ１Ｂ〜ｎＢは、「通常」であるとする。また、ファイル記憶装置１Ｓのディスクバッファ１Ｄは、図６に示すように、その全領域が「空き」であるとする。
【００６１】
２−１．他のファイル記憶装置が全て「通常」である場合の処理
まず、バッファ管理手段１Ｃは、図５に示すブロック１，２，３の更新を必要とする操作１の要求に応答して、図３に示すように、ディスクバッファ１Ｄ内に、書き込みブロック数である３ブロック分の「空き」領域または更新必要性「無」の領域が存在するか否かを判断する（ステップ３０１）。この場合、図６に示すように、ディスクバッファ１Ｄ内には３ブロック分の「空き」領域があるため、この３ブロック分の「空き」領域の各々に、書き込みブロック１，２，３のブロックアドレスとデータ内容を格納し、更新必要性を「有」にする（ステップ３０６）。その結果、ディスクバッファ１Ｄの内容は、図７に示すようになる。この処理の途中では、ディスク１Ｅの更新は行われないので、ディスク１Ｅ内のデータの整合性は依然として保たれている。なお、ディスクバッファ内のブロックごとのデータ内容が請求の範囲にいうバッファブロックに対応する。
【００６２】
次に、バッファ管理手段１Ｃは、図５に示すブロック４，５，６の更新を必要とする操作２の要求に応答して、図３に示すように、ディスクバッファ１Ｄ内に、書き込みブロック数である３ブロック分の「空き」領域または更新必要性「無」の領域が存在するか否かを判断する（ステップ３０１）。この場合、図７に示すように、ディスクバッファ１Ｄ内には３ブロック分の「空き」領域があるため、この３ブロック分の「空き」領域の各々に、書き込みブロック４，５，６のブロックアドレスとデータ内容を格納し、更新必要性を「有」にする（ステップ３０６）。その結果、ディスクバッファ１Ｄの内容は、図８に示すようになる。この処理の途中では、ディスク１Ｅの更新は行われないので、ディスク１Ｅ内のデータの整合性は依然として保たれている。
【００６３】
続いて、バッファ管理手段１Ｃは、図５に示すブロック７，８，９の更新を必要とする操作３の要求に応答して、図３に示すように、ディスクバッファ１Ｄ内に、書き込みブロック数である３ブロック分の「空き」領域または更新必要性「無」の領域が存在するか否かを判断する（ステップ３０１）。この場合、図８に示すように、ディスクバッファ１Ｄ内には３ブロック分の「空き」領域または更新必要性「無」の領域がないため、バッファ管理手段１Ｃは、フラッシュ逐次化手段１Ａにフラッシュ開始要求を送り（ステップ３０２）、フラッシュ逐次化手段１Ａからのフラッシュ開始許可を待つ（ステップ３０３）。
【００６４】
また、フラッシュ逐次化手段１Ａは、バッファ管理手段１Ｃからのフラッシュ開始要求に応答して、図４に示すように、フラッシュ状態フラグ１Ｂを「調査中」にし（ステップ４０１）、他のファイル記憶装置２Ｓ，…，ｎＳのフラッシュ状態フラグ２Ｂ，…，ｎＢを調べ（ステップ４０２）、「調査中」または「更新中（実行中）」のファイル記憶装置が存在するか否かを判断する（ステップ４０３）。この時、他のいずれのファイル記憶装置２Ｓ，…，ｎＳも「調査中」または「更新中（実行中）」でなければ、フラッシュ逐次化手段１Ａは、フラッシュ状態フラグ１Ｂを「更新中（実行中）」にして、要求元のバッファ管理手段１Ｃにフラッシュ開始許可を返し（ステップ４０５）、バッファ管理手段１Ｃからのフラッシュ終了通知を待つ（ステップ４０６）。
【００６５】
なお、ここまでの処理で、ファイル記憶装置１Ｓのディスク１Ｅは初期状態から全く更新されていないため、このディスク１Ｅ上のデータの整合性は依然として保たれたままである。
【００６６】
さらに、バッファ管理手段１Ｃは、フラッシュ逐次化手段１Ａからのフラッシュ開始許可に応答して、ディスクバッファ１Ｄ内の更新必要性「有」の全領域の全データにより、ディスクバッファ１Ｄのフラッシュ処理を行う（ステップ３０４）。すなわち、ここでは、更新必要性「有」の領域に格納されたブロック１，２，３，４，５，６のブロックアドレスとデータ内容によって、ディスク１Ｅを更新して、これらの６ブロック分の領域をディスク更新必要性「無」に変更する。
【００６７】
このフラッシュ処理の途中において、ディスク１Ｅのブロック１，２，３の一部、またはブロック４，５，６の一部のみを更新した状態では、１つの操作で更新しなくてはならない複数のブロックの全てを更新した状態でないため、この時点ではディスク１Ｅ上のデータの整合性は取られていないが、この６ブロック分の全データによってディスク１Ｅの対象ブロック１，２，３，４，５，６を更新し終わった時点では、再びディスク１Ｅ上のデータの整合性が取られている。このフラッシュ処理の後、バッファ管理手段１Ｃは、フラッシュ逐次化手段１Ａにフラッシュ終了通知を送る（ステップ３０５）。そして、フラッシュ逐次化手段１Ａは、バッファ管理手段１Ｃからのフラッシュ終了通知を受け取ると、図４に示すように、フラッシュ状態フラグ１Ｂを「通常」に戻す（ステップ４０７）。
【００６８】
バッファ管理手段１Ｃは引き続き、ディスクバッファ１Ｄの「空き」または更新必要性が「無」の領域の３ブロック分の領域の各々に、書き込みブロック７，８，９のブロックアドレスとデータ内容を格納し、更新必要性を「有」にする（ステップ３０６）。その結果、ディスクバッファ１Ｄの内容は、図９に示すようになる。しかし、この場合にはディスク１Ｅは更新されないため、依然としてディスク１Ｅ上のデータの整合性は保たれている。
【００６９】
このように、本実施例のファイル記憶装置１Ｓにおいて、ディスク１Ｅ上のデータの整合性が崩れるのは、ディスクバッファ１Ｄのフラッシュ処理を行っている時、すなわち、フラッシュ状態フラグ１Ｂが「更新中（実行中）」になっている時のみである。
【００７０】
２−２．他のファイル記憶装置のいずれかが「調査中」または「更新中（実行中）」である場合の処理
一方、例えば、ファイル記憶装置２Ｓがフラッシュ処理を行っている最中には、このファイル記憶装置２Ｓのフラッシュ状態フラグ２Ｂは「更新中（実行中）」になる。この状態で、ファイル記憶装置１Ｓのフラッシュ逐次化手段１Ａがフラッシュ開始要求を受け取った場合には、このフラッシュ逐次化手段１Ａは、図４に示すように、フラッシュ状態フラグ１Ｂを「調査中」にし（ステップ４０１）、他のファイル記憶装置２Ｓ，…，ｎＳのフラッシュ状態フラグ２Ｂ，…，ｎＢを調べ（ステップ４０２）、「調査中」または「更新中（実行中）」のファイル記憶装置が存在すると判断する（ステップ４０３）。続いて、フラッシュ逐次化手段１Ａは、フラッシュ状態フラグ１Ｂを「通常」にして一定時間待機する（ステップ４０４）。
【００７１】
そして、一定時間後、このフラッシュ逐次化手段１Ａは、再び、図４に示すように、フラッシュ状態フラグ１Ｂを「調査中」にし（ステップ４０１）、他のファイル記憶装置２Ｓ，…，ｎＳのフラッシュ状態フラグ２Ｂ，…，ｎＢを調べ（ステップ４０２）、「調査中」または「更新中（実行中）」のファイル記憶装置があるか否かを判断する（ステップ４０３）。この場合、さらにファイル記憶装置２Ｓが「更新中（実行中）」であれば、フラッシュ逐次化手段１Ａは、フラッシュ状態フラグ１Ｂを「通常」にして、再び、一定時間待機することになる。
【００７２】
これに対して、フラッシュ逐次化手段１Ａが待機している間に、ファイル記憶装置２Ａでフラッシュ処理が終了し、フラッシュ状態フラグ２Ｂが「通常」に戻り、「調査中」または「更新中（実行中）」のファイル記憶装置がないと判断した場合には、フラッシュ逐次化手段１Ａは、フラッシュ状態フラグ１Ｂを「更新中（実行中）」にして、要求元のバッファ管理手段１Ｃにフラッシュ開始許可を返し（ステップ４０５）、バッファ管理手段１Ｃからのフラッシュ終了通知を待つ（ステップ４０６）。最終的に、このフラッシュ逐次化手段１Ａは、バッファ管理手段１Ｃからのフラッシュ終了通知を受け取った時点で、フラッシュ状態フラグ１Ｂを「通常」に戻す（ステップ４０７）。
【００７３】
このように、第１実施例において、１つのファイル記憶装置１Ｓでフラッシュ処理を行おうとする場合には、フラッシュ逐次化手段１Ａの作用により、他のファイル記憶装置が、フラッシュ処理のための「調査中」またはフラッシュ処理の「更新中（実行中）」である場合に、バッファ管理手段１Ｃによるフラッシュ処理の実行を一定時間の間制止し、「調査中」または「更新中（実行中）」のファイル記憶装置がなくなった時点で初めてバッファ管理手段１Ｃにフラッシュ開始許可を返して、ディスクバッファ１Ｄのフラッシュ処理を行わせることになる。したがって、同時に２つ以上のファイル記憶装置がフラッシュ処理を行うことがない。
【００７４】
以上説明したように、第１実施例において、ディスク１Ｅ上のデータの整合性が崩れるのは、ディスクバッファ１Ｄのフラッシュ処理を行っている時、すなわち、フラッシュ状態フラグ１Ｂが「更新中（実行中）」になっている時のみであり、また、同時に２つ以上のファイル記憶装置がフラッシュ処理を行うことがないため、同時に２つ以上のファイル記憶装置がディスク上におけるデータの整合性を失ってしまうことはない。したがって、仮に、複数のあるいは全部のファイル記憶装置が同時に障害によってダウンした場合であっても、２重以上に多重化されて複数のファイル記憶装置に保存されたファイルのデータは、少なくとも１つのファイル記憶装置に確実に保存されていることになる。
【００７５】
特に、第１実施例では、逐次化手段が、更新ごとに毎回他の更新中のドライブを検出することによって更新の時間的重複を避けるので、確実な逐次化を行うことができる。また、第１実施例では、更新開始の制御を逐次化手段に与えることによって信頼性の高いファイルシステムを実現でき、更新自体を行うハードウェアや手順は従来通りのものが利用できるので従来の設備が有効活用できる。すなわち、従来のファイルシステムに本発明を適用する際、ハードウェアやＢＩＯＳ(Basic Input/Output System) などディスクにアクセスするための基本的な制御手順のみ変更すれば、ファイルシステムの論理的制御手順を変える必要がない（図１０）。
【００７６】
３．第２実施例
第２実施例では、前記バッファ手段は、操作と、各操作が対象とする各バッファブロックを識別情報を用いて記録するように構成され、前記更新手段は、前記識別情報に基づいて、単一の操作に対応する全てのバッファブロックを単位として前記更新を行うように構成されている。また、第２実施例では、前記更新手段は、複数の操作の対象に同一のバッファブロックが含まれる場合、それら複数の操作に係る全てのバッファブロックを連続して更新するように構成されている。例えば、操作内容をバッファに記録するごとに、操作番号と対象バッファブロック番号を対照表（図１１）に記録する。また、ディスクバッファの所定の領域にも、各バッファブロックを操作対象とした操作番号を記録する。バッファブロック毎の操作番号を記録する（図１２）。例えば、図１１，図１２では、操作１でブロック１，２が、操作２でブロック３，４が、操作３でブロック３，５が操作されている。この場合、更新はバッファブロック１，２を一体に行うほか、操作２，３に係るバッファブロック３，４，５を一体に行う。操作２に係るバッファブロック３，４のみを更新し、バッファブロック５を更新しない状態は、操作３に基づいてみれば「書きかけ」だからである。
【００７７】
このような第２実施例では、各操作とバッファブロックについて、コード番号のような識別情報を記録しておくことによって容易に対応関係を特定できるので、特殊なデータ構造を用いずに、単純な構成で操作単位の更新が実現できる。
【００７８】
また、第２実施例では、複数の操作が同一のブロックを対象とした場合、そのうち一部の操作の内容のみによって当該ブロックが更新されることがないので、他の操作の対象としてのブロック間の整合性を喪失することがない。
【００７９】
４．他の実施例
なお、本発明は、前記実施例に限定されるものではなく、例えば、バッファフラッシュ手段およびフラッシュ逐次化手段の具体的な構成や処理の流れは、自由に変更可能である。また、これらの手段以外の各部の構成要素やファイル記憶装置全体の構成についても、同様に自由に変更可能であり、ファイル記憶装置の数も自由に選択可能である。
【００８０】
例えば、バッファフラッシュを行う場合は、新たなデータを書き込む余地が不足した場合には限定されず、バッファフラッシュの命令がユーザ又はプログラムによって与えられたとき、媒体をドライブから取り外すための命令が与えられたとき、システムを停止しようとするときなど、自由に決定できる。
【００８１】
また、例えば、前記各逐次化手段は、通信回線を経由して他のドライブの状態に関する情報を収集することによって前記調査を行うように構成してもよい（請求項６）。このような実施例では、通信回線さえあれば逐次化手段がこの通信回線を用いて調査を行うので、フラグやスーパーバイザは不要となる。
【００８２】
また、例えば、前記逐次化手段は、各ドライブのフラグを他の全てのドライブに控えとして転送・コピーし、他のドライブではこの控えのフラグを参照することによって前記調査を行うように構成してもよい（請求項７）。このような実施例では、各ドライブの逐次化手段は、調査の度に他のドライブの状態や他のドライブに設けられたフラグを通信回線で参照する必要がなくなるので、更新時の処理が高速化される。上記のような通信やフラグの転送は、イーサネット及びＭＡＰのようなＬＡＮを用いて行うこともできる。
【００８３】
また、例えば、前記逐次化手段は、各ドライブの更新を所定のクロックに基づいて所定の各クロックサイクル内に制限することによって前記逐次化を行うように構成してもよい（請求項８）。このような実施例では、各ドライブでの更新の機会が所定のサイクルで確実に与えられ、特定のドライブでの更新が他のドライブでの更新の連続によって遅延する場合がなくなる。
【００８４】
【発明の効果】
以上のように、本発明では、更新中以外の瞬間にドライブが故障してもファイル内の各ブロック間の整合性は失われないので、信頼性の高いファイルシステムを提供することができる。
【図面の簡単な説明】
【図１】本発明のファイルシステムの第１実施例の構成要素を示す構成図
【図２】図１のシステムの具体的な構成の一例を示す概念図
【図３】図１のバッファ管理手段がブロックの書き込み要求（更新要求）を受け取った場合の処理手順を示すフローチャート
【図４】図１のフラッシュ逐次化手段がフラッシュ開始要求を受け取った場合の処理手順を示すフローチャート
【図５】図１のファイル記憶装置１Ｓに対する操作要求の操作番号と更新対象ブロックアドレスを示す表
【図６】図１のディスクバッファ１Ｄの初期状態を示す表
【図７】図１のディスクバッファ１Ｄの操作１終了後の状態を示す表
【図８】図１のディスクバッファ１Ｄの操作２終了後の状態を示す表
【図９】図１のディスクバッファ１Ｄの操作３終了後の状態を示す表
【図１０】分散ファイルシステムのソフトウェア構成を示す概念図であり
【図１１】第２実施例における操作履歴表
【図１２】第２実施例におけるディスクバッファの内容
【符号の説明】
１Ｓ，２Ｓ…ファイル記憶装置
１Ａ，２Ａ…フラッシュ逐次化手段
１Ｂ，２Ｂ…フラッシュ状態フラグ
１Ｃ，２Ｃ…バッファ管理手段
１Ｄ，２Ｄ…ディスクバッファ
１Ｅ，２Ｅ…ディスク
１０…システムバス
Claims (20)
- 不揮発性の記憶装置のドライブを複数有し、
各ドライブの各々には、
各ドライブの記録媒体上にアクセス単位である複数のブロックと、
揮発性メモリ上のバッファに前記各ブロックに書き込むべきデータであるバッファブロックを一時的に格納するバッファ手段と、
バッファブロックによる記録媒体の更新の必要性を判断する判断手段と、
前記更新が必要と判断されたときに、全てのバッファブロックによってドライブのブロックを連続して更新する更新手段と、
各ドライブにおける前記更新の時間的重複を回避して更新を逐次化する逐次化手段を有することを特徴とするファイルシステム。 - 前記逐次化手段は、一のドライブにおいて前記更新をしようとする際に他の更新中のドライブが存在するか否かを調査し、他の更新中のドライブが存在する場合は前記一のドライブにおける更新を抑止し、他の更新中のドライブが存在しない場合は前記一のドライブにおける更新を行うように構成されたことを特徴とする請求項１記載のファイルシステム。
- 前記逐次化手段は、更新中のドライブが存在した場合は所定時間待機後に再度調査を行い、更新中のドライブが存在しなくなった場合に更新を行うように構成されたことを特徴とする請求項２記載のファイルシステム。
- 前記逐次化手段は、各ドライブの状態を示すフラグをドライブの状態に応じて「更新中」、「調査中」及びそれ以外の状態にセットし、更新しようとするときに他のドライブのフラグを調査するように構成されたことを特徴とする請求項２記載のファイルシステム。
- 前記逐次化手段は、各ドライブの各々に個別に設けられたことを特徴とする請求項１記載のファイルシステム。
- 前記各逐次化手段は、通信回線を経由して他のドライブの状態に関する情報を収集することによって前記調査を行うように構成されたことを特徴とする請求項４記載のファイルシステム。
- 前記逐次化手段は、各ドライブのフラグを他の全てのドライブに控えとして転送・コピーし、他のドライブではこの控えのフラグを参照することによって前記調査を行うように構成されたことを特徴とする請求項４記載のファイルシステム。
- 前記逐次化手段は、各ドライブの更新を所定のクロックに基づいて所定の各時間的サイクル内に制限することによって前記逐次化を行うように構成されたことを特徴とする請求項１記載のファイルシステム。
- 複数のドライブを有し、各ファイルが複数のドライブ上に記録されたことを特徴とする請求項１記載のファイルシステム。
- 不揮発性の記憶装置のドライブを複数有し、
各ドライブの各々は、
各ドライブの記録媒体上にアクセス単位である複数のブロックと、
揮発性メモリ上のバッファに前記各ブロックに書き込むべきデータであるバッファブロックを、前記ドライブへのブロックの更新を要求する単一のデータ書き込み操作が発生する都度、その単一のデータ書き込み操作ごとに、前記各ブロックに書き込むべきデータであるバッファブロックを揮発性メモリ上のバッファに対して一時的に格納するバッファ手段と、
バッファブロックによる記録媒体の更新の必要性を判断する判断手段と、
前記判断手段によって更新が必要と判断されたときに、少なくとも前記単一のデータ書き込み操作の対象となるすべてのバッファブロックによってドライブのブロックを連続して更新する更新手段と、
各ドライブにおける前記更新の時間的重複を回避して更新を逐次化する逐次化手段を有することを特徴とするファイルシステム。 - 前記バッファ手段は、前記発生した単一のデータ書き込み操作とこの書き込み操作の対象であるすべてのバッファブロックの対応付けを行う識別情報と共に、前記バッファブロックをバッファに対して一時的に格納するものであり、
前記更新手段は、前記判断手段によって更新が必要と判断されたときに、前記識別情報に基づいて、単一のデータ書き込み操作に対応する全てのバッファブロックを単位として前記更新を行うように構成されたことを特徴とする請求項１０に記載のファイルシステム。 - 前記更新手段は、複数のデータ書き込み操作の対象に同一のバッファブロックが含まれる場合、それら複数のデータ書き込み操作に係る全てのバッファブロックを連続して更新するように構成されたことを特徴とする請求項１１記載のファイルシステム。
- 前記逐次化手段は、一のドライブにおいて前記更新をしようとする際に他の更新中のドライブが存在するか否かを調査し、他の更新中のドライブが存在する場合は前記一のドライブにおける更新を抑止し、他の更新中のドライブが存在しない場合は前記一のドライブにおける更新を行うように構成されたことを特徴とする請求項１０記載のファイルシステム。
- 前記逐次化手段は、更新中のドライブが存在した場合は所定時間待機後に再度調査を行い、更新中のドライブが存在しなくなった場合に更新を行うように構成されたことを特徴とする請求項１３記載のファイルシステム。
- 前記逐次化手段は、各ドライブの状態を示すフラグをドライブの状態に応じて「更新中」、「調査中」及びそれ以外の状態にセットし、更新しようとするときに他のドライブのフラグを調査するように構成されたことを特徴とする請求項１３記載のファイルシステム。
- 前記逐次化手段は、各ドライブの各々に個別に設けられたことを特徴とする請求項１０記載のファイルシステム。
- 前記各逐次化手段は、通信回線を経由して他のドライブの状態に関する情報を収集することによって前記調査を行うように構成されたことを特徴とする請求項１５記載のファイルシステム。
- 前記逐次化手段は、各ドライブのフラグを他の全てのドライブに控えとして転送・コピーし、他のドライブではこの控えのフラグを参照することによって前記調査を行うように構成されたことを特徴とする請求項１５記載のファイルシステム。
- 前記逐次化手段は、各ドライブの更新を所定のクロックに基づいて所定の各時間的サイクル内に制限することによって前記逐次化を行うように構成されたことを特徴とする請求項１０記載のファイルシステム。
- 複数のドライブを有し、各ファイルが複数のドライブ上に記録されたことを特徴とする請求項１０記載のファイルシステム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP17121094A JP3614886B2 (ja) | 1993-07-23 | 1994-07-22 | ファイルシステム |
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP18307693 | 1993-07-23 | ||
| JP5-183076 | 1993-07-23 | ||
| JP17121094A JP3614886B2 (ja) | 1993-07-23 | 1994-07-22 | ファイルシステム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH0784727A JPH0784727A (ja) | 1995-03-31 |
| JP3614886B2 true JP3614886B2 (ja) | 2005-01-26 |
Family
ID=26494007
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP17121094A Expired - Lifetime JP3614886B2 (ja) | 1993-07-23 | 1994-07-22 | ファイルシステム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3614886B2 (ja) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2009230407A (ja) | 2008-03-21 | 2009-10-08 | Toshiba Corp | データの更新方法、メモリシステムおよびメモリデバイス |
| JP2011008570A (ja) * | 2009-06-26 | 2011-01-13 | Buffalo Inc | ストレージ装置、情報処理システム、およびコンピュータプログラム |
-
1994
- 1994-07-22 JP JP17121094A patent/JP3614886B2/ja not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| JPH0784727A (ja) | 1995-03-31 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3197382B2 (ja) | データの増分タイム・ゼロ・バックアップ・コピーの方法及びシステム | |
| US6330642B1 (en) | Three interconnected raid disk controller data processing system architecture | |
| JP2557172B2 (ja) | タイムゼロ・バックアップ・コピー・プロセスにおける副ファイル状態のポーリングのための方法およびシステム | |
| US8108597B2 (en) | Storage control method and system for performing backup and/or restoration | |
| US7958328B2 (en) | Computer system, storage system and method for saving storage area by integrating same data | |
| US7330947B2 (en) | Method and apparatus for backing up data in virtual storage medium | |
| EP0566968A2 (en) | Method and system for concurrent access during backup copying of data | |
| US6205529B1 (en) | Method and apparatus for defragmenting a storage device using a copy function in the device control logic | |
| JP4163298B2 (ja) | 記憶システムへのデータ書き込み方法 | |
| US7222135B2 (en) | Method, system, and program for managing data migration | |
| JP2005276208A (ja) | 通信リンク接続の永久メモリシステム | |
| US7664910B2 (en) | Data management method and apparatus, hierarchical storage apparatus and computer-readable storage medium | |
| KR20010007111A (ko) | 데이터 프로세서 제어형 데이터 저장 시스템, 동적재동기화 방법 및 컴퓨터 프로그램 | |
| US20060085663A1 (en) | Method for keeping snapshot image in a storage system | |
| JPH0830398A (ja) | 光ディスクシステム | |
| JP4892812B2 (ja) | キャッシュ制御およびデータ処理システム並びにその処理プログラム | |
| JP2005284816A (ja) | ディスクアレイシステム | |
| US7082445B2 (en) | Fast data copy using a data copy track table | |
| JP4394467B2 (ja) | ストレージシステム、サーバ装置及び先行コピーデータ生成方法 | |
| JP3614886B2 (ja) | ファイルシステム | |
| JPH0863394A (ja) | 記憶装置システムおよび記憶装置の制御方法 | |
| US7836247B2 (en) | Method, apparatus, and computer program product for permitting access to a storage drive while the drive is being formatted | |
| US5933839A (en) | Distributed file system for renewing data with high integrity | |
| JP2003186629A (ja) | データコピーシステム | |
| JPH11237959A (ja) | 多重書き込み記憶装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040106 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040308 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040622 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040823 |
|
| 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: 20041026 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20041028 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20071112 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20081112 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091112 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101112 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101112 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111112 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121112 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131112 Year of fee payment: 9 |
|
| EXPY | Cancellation because of completion of term |